Plex, Radarr, Sonarr 또는 다른 Docker 앱이 ZimaOS를 재부팅할 때마다 원격 SMB NAS에 대한 액세스 권한을 잃는다면, 애플리케이션을 변경하기 전에 호스트 마운트를 확인하세요. ZimaOS가 네트워크 공유를 성공적으로 마운트하고 Docker 바인드 경로가 여전히 해당 마운트 위치를 가리킬 때만 컨테이너에서 네트워크 공유를 볼 수 있습니다.
Synology 공유 폴더와 관련된 한 커뮤니티 사례에서는 사용자가 Docker Compose 경로 선택기에서 같은 폴더를 다시 선택할 때마다 문제가 복구되었습니다. 이는 마운트 또는 경로 지속성 문제를 강하게 시사하지만, ZimaOS가 항상 새로운 내부 마운트 ID를 생성한다는 포럼의 설명은 IceWhale이 확인한 근본 원인이 아니라 커뮤니티의 추론이었습니다. 따라서 좋은 가이드에서는 마운트, 경로, 시작 순서를 각각 따로 문제 해결해야 합니다.
먼저 재부팅 후 SMB 공유가 마운트되어 있는지 확인
Plex 또는 Radarr를 열기 전에 ZimaOS Files를 열고 원격 NAS 공유 폴더를 탐색합니다. 공유 폴더 자체에 액세스할 수 없다면 Docker 앱이 첫 번째 문제는 아닙니다.
공유 폴더가 표시되지 않는 경우
원격 NAS가 온라인 상태인지, 해당 IP/호스트 이름이 여전히 확인되는지, SMB가 활성화되어 있는지, 저장된 자격 증명이 여전히 유효한지 확인합니다. 필요한 경우 ZimaOS 네트워크 스토리지 워크플로를 통해 공유 폴더를 다시 연결합니다.
공유 폴더가 Files에 표시되는 경우
그런 다음 Docker 매핑으로 이동합니다. 호스트 마운트는 존재하지만 애플리케이션이 여전히 오래되었거나 사용할 수 없는 경로를 참조하고 있을 수 있습니다.
직접 작성한 fstab 항목 대신 ZimaOS 네트워크 스토리지 사용
사용자는 다음 파일을 편집하려고 했습니다. /etc/fstab. 이미 UI에서 네트워크 스토리지를 관리하는 어플라이언스형 OS에서는 이것이 가장 먼저 시도할 해결책이 아닙니다.
현재 ZimaOS 문서에서는 마이그레이션 및 네트워크 스토리지 워크플로의 일부로 SMB를 통한 다른 NAS 액세스를 안내합니다. 먼저 이 관리되는 경로를 사용하면 ZimaOS가 자격 증명과 마운트 상태를 일관되게 처리할 수 있습니다.
현재 참고 자료는 ZimaOS NAS 마이그레이션 가이드입니다.
컨테이너 경로뿐 아니라 Docker 호스트 경로를 확인하세요.
Docker 볼륨 매핑에는 두 측면이 있습니다.
- 호스트 경로: ZimaOS에서 마운트된 Synology 폴더를 인식하는 위치입니다.
- 컨테이너 경로: Plex, Radarr 또는 Sonarr가 컨테이너 내부에서 인식하는 안정적인 경로입니다.
재부팅 후 호스트 측이 유효하지 않더라도 애플리케이션 UI에서는 컨테이너 경로가 여전히 올바르게 보이면서 실제로는 아무것도 가리키지 않을 수 있습니다.
현재 ZimaOS Docker 경로 가이드에서 이 차이점을 설명합니다.
진단을 위해 폴더를 한 번 다시 선택
Files에서 원격 공유 폴더가 보이지만 앱에서 액세스할 수 없다면 앱 또는 Compose 설정을 열고 ZimaOS 경로 선택기를 사용해 호스트 폴더를 다시 선택하세요.
자격 증명이나 컨테이너 경로를 변경하지 않고 액세스가 즉시 복구된다면, 문제의 원인이 관리되는 마운트와 Docker 바인드 매핑 사이에 있다는 강력한 증거입니다.
재부팅할 때마다 시작 순서 확인
원격 SMB 저장소는 네트워킹, DNS/IP 연결 가능 여부, 인증, 그리고 NAS가 준비되었는지에 따라 달라집니다. Docker 컨테이너가 원격 마운트를 사용할 수 있게 되기 전에 더 빠르게 시작될 수 있습니다.
간단한 테스트
- ZimaOS를 재부팅하세요.
- Files에서 원격 공유 폴더를 탐색할 수 있을 때까지 기다리세요.
- 영향을 받는 Docker 앱만 다시 시작하세요.
- 미디어 또는 다운로드 항목이 다시 표시되는지 확인하세요.
이 방법이 안정적으로 작동한다면 경로는 안정적이고, 실제 문제는 마운트 식별자 변경이 아니라 시작 타이밍일 수 있습니다.
두 시스템의 권한 확인
SMB 마운트에 사용되는 Synology 계정에는 미디어 폴더에 대한 액세스 권한이 있어야 합니다. 그런 다음 ZimaOS 마운트에 Docker 프로세스가 액세스할 수 있어야 합니다. 마지막으로 애플리케이션은 올바른 컨테이너 경로를 사용해야 합니다.
권한 문제는 마운트 누락과 비슷하게 보일 수 있으므로 “권한이 거부되었습니다”를 “경로를 찾을 수 없음” 또는 “해당 파일이나 디렉터리가 없음”과 별도로 확인하세요.
수동으로 fstab을 변경하면 복구가 더 어려워질 수 있는 이유
사용자 지정 마운트에는 자격 증명 파일, 부팅 종속성, 타이밍 플래그 및 ZimaOS가 UI에서 관리하지 않는 오류 동작이 포함될 수 있습니다. 사용자 지정 마운트가 부팅 중 실패하면 앱이 빈 디렉터리를 대상으로 계속 시작될 수 있습니다.
사용 fstab 관리형 네트워크 저장소 워크플로로 요구 사항을 충족할 수 없고, 업데이트가 진행되어도 마운트를 직접 유지 관리할 준비가 된 경우에만
미디어 앱의 복원력 높이기
- 안정적인 NAS IP 또는 신뢰할 수 있는 로컬 DNS 이름을 사용하세요.
- 원격 공유는 네트워크 저장소를 통해 구성된 상태로 유지하세요.
- 안정적인 호스트 폴더 하나를 컨테이너에 매핑하세요.
- Radarr, Sonarr, 다운로드 클라이언트 및 미디어 서버에서 동일한 컨테이너 경로를 일관되게 사용하세요.
- 업데이트 또는 저장소 변경 후에는 애플리케이션 라이브러리를 변경하기 전에 마운트를 확인하세요.
LAN 문제 해결 가이드는 장애가 네트워크 계층에서 시작되는지 파악하는 데 도움이 되며, Docker 경로 기본 사항에서는 Docker의 맥락을 설명합니다.
FAQ
ZimaOS가 다시 시작된 후 Docker 앱에서 Synology 공유가 사라지는 이유는 무엇인가요?
가장 가능성이 높은 문제 계층은 SMB 공유가 다시 마운트되지 않는 경우, 앱이 오래된 호스트 경로를 사용하는 경우, 또는 원격 공유가 준비되기 전에 컨테이너가 시작되는 경우입니다. 각각을 따로 테스트하세요.
/etc/fstab을 편집해야 하나요?
첫 번째 해결 방법으로는 권장하지 않습니다. 시스템이 공유를 관리하도록 ZimaOS 네트워크 저장소를 우선 사용하세요. 수동 마운트는 유지 관리 부담과 부팅 순서의 복잡성을 높입니다.
같은 폴더를 다시 선택하면 앱이 정상 작동하는 이유는 무엇인가요?
호스트 측 바인드 매핑을 새로 고칩니다. 폴더 이름이 눈에 띄게 바뀌지 않았더라도 이는 마운트 또는 경로 문제의 증거입니다.
Plex와 Arr 앱에 원격 SMB 공유를 사용할 수 있나요?
예. ZimaOS가 안정적으로 마운트하고, 권한이 올바르며, 모든 컨테이너에서 호스트 경로와 컨테이너 경로를 일관되게 사용한다면 가능합니다.
