2026년 3월의 원본 사용자는 128GB NVMe 시스템 디스크와 USB로 연결된 하드 드라이브 3개를 갖춘 HP T640 씬 클라이언트로 첫 NAS를 구축하고 있었습니다. 한 외장 디스크에 사진을 저장하고 두 번째 디스크에 백업하며, 별도의 4TB 드라이브에 Plex 미디어를 저장하려는 계획은 합리적이었습니다. 주요 문제는 USB 스토리지가 불가능했던 것이 아니라, 앱의 볼륨 매핑을 잘못 편집해서 Immich가 중단된 것이었습니다.
이 대화의 스토리지 기능 관련 내용에도 현재 버전의 기준 시점을 반영해야 합니다. 2026년 3월 당시 사용자와 응답자는 USB 드라이브가 내부 스토리지보다 제한적이라고 보았습니다. 하지만 현재 ZimaOS 문서에는 USB 드라이브가 내부 HDD/SSD와 동일한 스토리지 로직을 따르며, 스토리지로 사용하거나 어레이에 추가하거나 기존 공간을 확장하는 데 사용할 수 있다고 명시되어 있습니다.
원본 NAS는 전적으로 USB 스토리지에 의존했습니다
이 구성은 다음과 같았습니다.
- AMD R1505G, 8GB RAM, 128GB NVMe를 탑재한 HP T640 씬 클라이언트
- 각각 별도의 USB 인클로저에 장착된 2.5인치 Seagate HDD 2개
- Plex 미디어용 4TB WD 외장 HDD 1개
씬 클라이언트에는 편리한 내부 드라이브 베이가 없었기 때문에 사용자는 USB 스토리지가 임시 이동식 미디어가 아니라 기본 NAS 스토리지처럼 작동하기를 원했습니다.
드라이브가 USB 스토리지로 표시되었습니다
사용자는 외장 드라이브를 내부 스토리지처럼 취급하거나 RAID에 사용할 수 없다고 생각했습니다. 이는 현재 ZimaOS 스토리지 모델이 아니라 2026년 3월 당시 설정의 동작과 기대를 반영한 것입니다.
현재 ZimaOS는 USB 드라이브를 일반 스토리지로 취급합니다
현재 IceWhale 문서에 따르면 USB 드라이브는 내부 HDD 및 SSD와 동일한 방식으로 작동합니다. 단일 스토리지로 사용하거나, 어레이에 추가하거나, 기존 공간을 확장하는 데 사용할 수 있습니다.
USB 드라이브를 설정을 통해 관리형 스토리지 또는 어레이 구성원으로 구성하는 현재 ZimaOS 스토리지 워크플로를 사용하세요. USB RAID가 원칙적으로 지원되지 않는다는 이전 가정을 바탕으로 새 시스템을 구축하지 마세요.
Immich 오류는 파일과 디렉터리를 잘못 매핑해서 발생했습니다
사용자가 Immich의 볼륨 설정을 변경하자 Docker에서 다음 항목을 마운트할 수 없다는 오류가 반환되었습니다.
/media/Photos/Immich
→ /etc/localtime/etc/localtime 컨테이너 내부의 /etc/localtime은 사진 라이브러리 디렉터리가 아니라 파일입니다. 따라서 Docker는 해당 파일 위에 폴더를 마운트하려는 시도를 거부했습니다.
/etc/localtime 파일 매핑.사진 스토리지와 /etc/localtime을 별도의 마운트로 유지하세요
커뮤니티 응답자는 두 역할을 올바르게 구분했습니다.
- 호스트 사진 폴더 → Immich의 업로드/데이터 디렉터리;
- 호스트
/etc/localtime파일 → 컨테이너/etc/localtime파일.
현재 Docker 바인드 마운트 규칙에서는 소스와 대상의 유형이 서로 일치해야 합니다. 디렉터리를 파일 위에 마운트하면서 두 유형을 서로 바꿔 사용할 수는 없습니다.
/DATA 바인드 마운트 우회 방법은 과거 커뮤니티의 제안이었습니다
응답자는 또한 다음 위치에 안정적인 디렉터리를 만들 것을 제안했습니다 /DATA 그리고 외부 디스크가 재부팅 후 애플리케이션이 시작될 때 아직 준비되지 않았을 수 있으므로 해당 경로를 바인드 마운트하는 것
이는 원래 버전에 대한 커뮤니티 안내였습니다. 현재 ZimaOS는 관리형 USB 스토리지를 더 강력하게 지원하므로, 새로 설치할 때는 사용자 지정 부팅 시 바인드 마운트를 만드는 대신 먼저 스토리지 UI와 앱의 관리형 볼륨 선택기를 사용해야 합니다.
Immich는 원시 장치 경로가 아닌 관리형 스토리지를 사용하세요
현재 ZimaOS에서는 시스템 드라이브를 가득 채우는 대신 애플리케이션 데이터와 대용량 미디어 라이브러리를 해당 데이터를 저장하도록 지정된 스토리지 공간에 두는 것을 권장합니다. ZimaOS에서 선택한 호스트 경로를 사용한 다음, Immich가 요구하는 컨테이너 측 경로를 유지하세요.
현재 애플리케이션 매핑의 경우, ZimaOS 앱 스토리지 경로 모델에서 호스트 경로와 컨테이너 경로가 어떻게 연결되는지 설명합니다.
RAID와 백업은 여전히 서로 다른 문제를 해결합니다
현재 ZimaOS에서는 USB 드라이브를 어레이에서 사용할 수 있지만, RAID 1은 독립적인 두 번째 백업을 대신하지 않습니다. 하나의 어레이에 있는 USB 디스크 두 개는 구성원 디스크 장애에는 대비할 수 있지만, 실수로 인한 삭제, 멀웨어, 인클로저 또는 컨트롤러 문제, NAS 전체의 손실에는 대비하지 못합니다.
스토리지 기능이 변경되었더라도, 추가 사본을 보관하자는 원래 사용자의 생각은 여전히 유용합니다.
Plex 미디어는 Immich 애플리케이션 상태보다 단순합니다
사용자는 4TB Plex 드라이브의 동영상 콘텐츠를 다시 구할 수 있으므로 해당 드라이브를 폐기 가능한 것으로 간주했습니다. 이는 합리적인 위험 구분입니다. 미디어 파일, Immich 사진, Immich 데이터베이스 상태, 애플리케이션 구성은 반드시 동일한 수준의 중복성이나 백업 정책을 적용할 필요가 없습니다.
외부 USB 스토리지 FAQ
현재 ZimaOS에서 USB 드라이브를 관리형 스토리지로 사용할 수 있나요?
예. 현재 스토리지 문서에서는 USB 드라이브를 스토리지 및 어레이 구성원으로 명시적으로 지원합니다.
디렉터리를 변경한 후 Immich가 작동하지 않은 이유는 무엇인가요?
사진 폴더가 실수로 컨테이너의 /etc/localtime 파일 경로.
현재 사용자는 모든 USB 드라이브에 수동으로 /DATA 바인드 마운트를 만들어야 하나요?
아니요. 그것은 과거 커뮤니티의 우회 방법이었습니다. 현재 관리형 스토리지와 앱 볼륨 제어부터 사용하세요.
