원본 문제는 경로가 사라지는 것보다 더 위험했습니다. 재부팅 후 Synology SMB 공유가 실제로 마운트되기 전에 SABnzbd가 시작될 수 있었습니다. 컨테이너는 예상된 호스트 경로에 디렉터리가 있는 것으로 인식했기 때문에 다운로드가 완료되고 정상적으로 이동된 것처럼 보일 수 있었지만, 실제로는 원격 NAS가 아닌 로컬 ZimaOS 저장 공간에 저장되고 있었습니다.
커뮤니티에서는 결국 CIFS/fstab을 수동으로 구성하는 방법을 마련했고, 원글 작성자는 마운트가 재부팅 후에도 유지된다고 확인했습니다. 하지만 위험성도 입증되었습니다. 잘못된 fstab 항목은 정상적인 부팅을 막을 수 있었고, 이스케이프되지 않은 공백이 포함된 마운트 지점은 구성을 깨뜨렸습니다. 이러한 명령은 현재 공식 ZimaOS 네트워크 저장소 절차가 아니라, 원본에서 확인된 커뮤니티 관리 방법으로 취급하세요.
핵심 장애 원인은 마운트 시점이었습니다
원본의 경로는 다음과 같았습니다.
/media/192.168.2.125/Movies재부팅 후 SABnzbd가 시작될 때 SMB 마운트가 아직 준비되지 않았습니다. 시스템이 안정된 뒤 같은 볼륨을 다시 추가하면 다시 작동했으며, 이는 마운트 ID가 변경된 문제가 아니라 시점 또는 순서 문제였음을 강하게 뒷받침합니다.
원격 마운트가 없으면 로컬 디렉터리 함정이 생길 수 있습니다
Docker에 원격 파일 시스템이 연결되지 않은 상태에서 로컬에 존재하는 호스트 디렉터리 경로를 전달하면 애플리케이션이 해당 로컬 디렉터리에 파일을 쓸 수 있습니다. 로그에는 여전히 파일이 /movies로 이동했다고 표시될 수 있지만, Synology에는 아무것도 나타나지 않습니다.
대용량 다운로드를 시작하기 전에 마운트 지점 디렉터리가 존재하는지만 확인하지 말고, 예상한 원격 파일 시스템이 실제로 마운트되어 있는지 확인하세요.
커뮤니티에서는 마운트를 안정적인 /DATA 경로로 옮겼습니다
제안된 설계는 SMB 공유를 다음과 같이 안정적인 로컬 경로에 마운트하는 것이었습니다.
/DATA/Media/Movies그런 다음 이 안정적인 호스트 경로를 SABnzbd에 매핑합니다. 이렇게 하면 원격 파일 시스템은 호스트 계층에서 관리하면서 컨테이너 경로를 일관되게 유지할 수 있습니다.
원본 사용자는 /etc/fstab이 재부팅 후에도 유지된다고 확인했습니다
커뮤니티 예시에서는 _netdev, 특정 SMB 프로토콜 버전, UID/GID 및 모드 값을 포함한 CIFS 옵션을 사용했습니다. 사용자는 fstab 항목이 유지되며 재부팅 후에도 정상 작동한다고 말했습니다.
보호된 자격 증명 파일 사용을 고려하지 않은 채 자격 증명을 누구나 읽을 수 있는 구성 파일에 직접 입력하지 마세요.
잘못된 항목으로 부팅이 차단된 후 nofail이 중요해졌습니다
원본 사용자는 잘못되었거나 사용할 수 없는 마운트가 부팅을 방해할 수 있다는 사실을 발견했습니다. 답변에서는 원격 NAS를 사용할 수 없을 때도 ZimaOS가 계속 부팅할 수 있도록 nofail을 권장했습니다.
_netdev는 해당 마운트가 네트워크에 의존한다는 사실도 마운트 시스템에 알립니다.
마운트 지점의 공백은 올바르게 처리해야 합니다
두 번째 fstab 항목은 마운트 지점에 TV Shows가 포함되어 있어 실패했습니다. fstab에서는 공백이 필드를 구분하므로 공백을 적절히 이스케이프하거나 TV_Shows처럼 더 단순한 디렉터리 이름을 사용해야 합니다.
이후 원글 작성자는 공백이 없는 별도 폴더를 사용해 정상적으로 해결했습니다.
재부팅하기 전에 항상 mount -a로 테스트하세요
원본에서 제시한 가장 안전한 단계는 다음과 같습니다.
sudo mount -a오류가 반환되면 재부팅하기 전에 fstab 구문과 경로를 수정하세요. 또한 마운트된 파일 시스템에 예상한 원격 파일이 포함되어 있는지 확인하세요.
사용 사례에 적합하다면 현재 ZimaOS 네트워크 저장소를 우선 사용하세요
현재 ZimaOS에서는 Files/Network Storage 워크플로를 통해 SMB/LAN 저장소에 연결할 수 있습니다. 애플리케이션에 필요한 영속성 및 순서 동작을 제공한다면 먼저 관리형 인터페이스를 사용하세요.
현재 Synology SMB 연결 워크플로를 참조하세요.
정말 안정적인 컨테이너라면 원격 마운트가 확인될 때까지 쓰기를 수행하지 않아야 합니다
fstab을 사용하더라도 네트워크 NAS는 나중에 오프라인 상태가 될 수 있습니다. 중요한 다운로드 및 가져오기 파이프라인에는 SABnzbd가 작업을 처리하기 전에 원격 대상이 마운트되어 있는지 확인하는 상태 점검, 시작 점검 또는 운영 절차를 추가하세요.
SABnzbd SMB 마운트 FAQ
원본에서는 재부팅 후 SMB 마운트 ID가 변경되었다는 사실을 입증했나요?
아니요. 증거는 마운트 시점 문제를 뒷받침했습니다.
원본 사용자에게 fstab이 유지되었나요?
예. 하지만 잘못 작성되었거나 사용할 수 없는 항목으로 인해 수정 전까지 부팅 문제가 발생하기도 했습니다.
왜 다운로드가 성공한 것처럼 보이는데 Synology에는 파일이 없을 수 있나요?
원격 SMB 파일 시스템이 실제로 마운트되지 않은 경우 애플리케이션이 로컬 마운트 지점 디렉터리에 파일을 쓸 수 있기 때문입니다.
