Jellyfin, Emby 또는 Plex에서 실제 미디어가 저장된 HDD, NVMe 또는 RAID가 아니라 ZimaOS-HD만 보이는 경우, 대개 Docker에 “NAS에 대한 권한이 없기” 때문은 아닙니다. 컨테이너는 ZimaOS가 볼륨으로 매핑한 호스트 폴더만 탐색할 수 있습니다.
이것이 2024년 6월 원본 스레드의 핵심 해결 방법이었습니다. ETWang1991은 사용자들에게 앱 설정을 열고 새 저장소를 볼륨으로 추가하라고 안내했습니다. 원 게시자는 그러자 “매우 잘 작동했다”고 답했고, 나중에 다른 Jellyfin 사용자도 스크린샷을 본 뒤 같은 결론에 도달했습니다.
Docker 앱은 ZimaOS 호스트 파일 시스템 전체를 볼 수 없습니다
컨테이너 격리는 의도된 동작입니다. Jellyfin은 다음을 볼 수 있습니다. /Media 해당 경로가 미디어가 포함된 실제 호스트 디렉터리에 매핑된 경우에만 컨테이너 내부에서 볼 수 있습니다.
ZimaOS Files에 드라이브가 표시된다고 해서 모든 App Store 컨테이너에서 해당 드라이브를 자동으로 볼 수 있는 것은 아닙니다.
앱의 Settings를 열고 볼륨 편집
실제 호스트 미디어 폴더 선택
추측한 최상위 경로(예: )를 입력하는 대신, 라이브러리가 포함된 실제 저장 공간의 디렉터리를 선택하세요. /Main-Storage.
호스트 경로와 컨테이너 경로는 서로 다른 역할을 합니다
컨테이너 측 경로는 다음과 같이 간단하고 안정적이어야 합니다. /media 또는 /MediaJellyfin에서 컨테이너 경로를 사용해 라이브러리를 추가하세요. 호스트의 원래 경로를 사용하면 안 됩니다.
여러 사용자가 볼륨 매핑이 누락된 단계였다고 확인
원 게시자는 변경 사항이 적용되었다고 말했습니다. RAID 5 Main-Storage를 사용하는 다른 사용자는 처음에 OS 디스크만 보였지만, 나중에 스크린샷을 보고 해결 방법을 알게 되었다고 답했습니다. “Jellyfin에 볼륨을 추가해야 했습니다.”
이는 추측에 기반한 권한 우회 방법이 아니라 출처로 확인된 해결 방법입니다.
개별적으로 추가된 디스크는 2024년 UI의 문제점이었습니다
일부 사용자는 이전 선택기에서 개별적으로 활성화된 디스크나 RAID 스토리지를 선택하는 데 어려움을 겪었습니다. IceWhale 직원은 개별 드라이브를 활성화하여 사용할 수 있다고 답변했으며, 이후 인터페이스가 개선되었다고 밝혔습니다.
이러한 2024년의 제한 사항은 초기 ZimaOS에 해당합니다. 현재 ZimaOS의 스토리지 및 앱 설정에서는 관리형 스토리지를 훨씬 더 명확하게 확인할 수 있습니다.
현재 ZimaOS는 앱 스토리지 경로를 명시적으로 문서화합니다
현재 IceWhale 문서에서는 App Store 컨테이너가 실제 호스트 폴더에 영구 데이터를 저장하며, 각 앱의 볼륨 매핑을 설정에서 확인하고 변경할 수 있다고 설명합니다.
Jellyfin, Emby, Plex 또는 다른 앱을 매핑할 때는 현재 ZimaOS Docker 앱 경로 모델을 사용하세요.
AppData 위치와 미디어 위치는 서로 다릅니다
애플리케이션 구성 및 데이터베이스 파일은 구성된 앱 데이터 위치에 저장하고, 대용량 미디어 파일은 다른 RAID 또는 HDD 풀에 저장할 수 있습니다. 앱의 구성 볼륨을 영화 폴더에 지정하거나 AppData를 이동하면 모든 미디어 라이브러리도 이동한다고 생각하지 마세요.
현재 ZimaOS에서는 관리형 앱 데이터를 이동할 수 있습니다
현재 데이터 마이그레이션을 사용하면 Docker 이미지와 Docker 애플리케이션 데이터를 다른 스토리지 공간으로 이동할 수 있습니다. 이는 미디어 볼륨을 추가하는 것과는 다른 문제를 해결합니다. 전자는 앱 자체가 영구 상태를 저장하는 위치를 제어하고, 후자는 컨테이너가 사용자 미디어에 액세스할 수 있도록 합니다.
현재 관리형 앱 데이터 마이그레이션 워크플로를 확인하세요.
앱에서 파일을 수정할 필요가 없다면 읽기 전용 미디어 마운트를 선택하세요
미디어 서버는 일반적으로 영화와 음악을 읽어야 하지만, 소스 라이브러리를 삭제하거나 재구성할 권한까지 반드시 필요한 것은 아닙니다. 현재 앱 패키지에서 허용하는 경우 미디어를 읽기 전용으로 매핑하면 손상되었거나 잘못 구성된 컨테이너가 초래할 수 있는 피해를 줄일 수 있습니다.
의도적으로 파일 이름을 변경하거나 파일을 이동 또는 가져오는 애플리케이션(예: 일부 다운로드 또는 사진 관리 스택)은 다른 쓰기 권한 모델이 필요합니다.
볼륨 매핑과 파일 시스템 권한은 별도로 확인해야 합니다
올바른 호스트 폴더를 추가하는 것이 첫 번째 요구 사항입니다. 또한 컨테이너 프로세스에 해당 폴더를 읽거나 쓸 수 있는 충분한 파일 시스템 권한이 있어야 합니다. 매핑된 디렉터리가 표시되지만 비어 있거나 권한 오류가 반환되면, 광범위한 권한을 사용하기 전에 컨테이너 UID/GID와 호스트 소유권을 확인하세요. chmod 777 우회 방법.
2024년 소스의 문제는 주로 볼륨 매핑 누락이었으며, 올바른 경로가 실제로 마운트된 후에만 이후의 권한 문제를 진단해야 합니다.
재설치 후에도 컨테이너 측 경로를 동일하게 유지하세요
로 변경하는 경우 /Media컨테이너 경로를 /mnt/media2 재설치 중에 컨테이너 경로를 변경하면 호스트 파일이 실제로 이동하지 않았더라도 기존 라이브러리가 사라진 것처럼 보일 수 있습니다.
가능하면 동일한 컨테이너 측 경로를 유지하거나, 매핑 변경 후 애플리케이션 라이브러리 설정을 신중하게 업데이트하세요.
현재 UI는 2024년 선택기보다 개선되었지만 Docker 규칙은 바뀌지 않았습니다
IceWhale은 소스에서 기존 스토리지 선택기가 혼란스러웠음을 인정했으며, 이후 인터페이스를 개선했습니다. 현재 ZimaOS에서는 앱 데이터 위치, 호스트/컨테이너 경로, 스토리지 마이그레이션, 앱 캐시 사용량을 더욱 직접적으로 확인할 수 있습니다.
기본 Docker 규칙은 동일합니다. 컨테이너는 컨테이너에 마운트된 항목만 볼 수 있습니다.
앱 스토리지 액세스 FAQ
ZimaOS Files에서는 드라이브를 볼 수 있는데 Jellyfin에서는 볼 수 없는 이유는 무엇인가요?
Files는 호스트 수준에서 실행되고, Jellyfin은 컨테이너 내부에서 실행되므로 매핑된 볼륨만 볼 수 있습니다.
소스 스레드에서 볼륨 추가가 작동하는 것으로 확인되었나요?
예. 여러 사용자가 스토리지/미디어 볼륨을 추가한 후 정상적으로 작동했다고 보고했습니다.
Jellyfin이 호스트의 원본 경로를 탐색해야 하나요?
아니요. Jellyfin은 매핑된 호스트 폴더에 할당된 컨테이너 측 경로를 탐색해야 합니다.
