2025년 11월에 작성된 이 글의 원래 목표는 단순했습니다. 미니 PC의 내부 512GB SSD에는 ZimaOS와 애플리케이션을 유지하고, 5TB 외장 Seagate USB HDD는 미디어와 다운로드에 사용하는 것이었습니다. 문제는 ZimaOS가 이미 스토리지를 관리하는 방식을 이해하기 전에 외장 디스크를 일반적인 Linux 서버 마운트처럼 취급하면서 발생했습니다.
사용자는 다음 경로 아래에 수동으로 마운트하는 방법을 시험했습니다. /var이후 서버가 충돌하여 ZimaOS를 재설치했습니다. 그 후 디스크를 ZimaOS 데이터 경로 아래에 마운트하고 SABnzbd에 매핑했지만, 애플리케이션은 여전히 권한 오류를 반환했습니다. 따라서 이 글에는 두 가지 별도의 교훈이 있습니다. 먼저 안전하게 관리되는 호스트 경로를 선택한 다음, 컨테이너 권한 문제를 별도로 해결해야 합니다.
/var를 임의의 USB 마운트 지점으로 사용하지 마세요
ZimaOS는 시스템 경로를 관리하는 어플라이언스형 운영 체제입니다. 원문 작성자는 외장 드라이브를 다음 경로 아래에 마운트했다고 말했습니다. /var 처음에는 작동하는 것처럼 보였지만 이후 서버가 완전히 충돌하고 재설치하게 됨
이 글만으로 마운트 자체가 충돌을 직접 일으켰다고 입증할 수는 없지만, 미디어 디스크의 일반 스토리지 위치로 시스템 디렉터리를 사용하지 말아야 할 충분한 이유가 됩니다.
외장 드라이브는 현재 ZimaOS에서 관리하도록 하세요
현재 ZimaOS는 이 글의 2025년 환경보다 USB 스토리지를 훨씬 폭넓게 지원합니다. USB 디스크는 설정 > 스토리지에서 추가한 다음, 임의로 만든 Linux 마운트 지점에 수동으로 연결하는 대신 일반 스토리지처럼 사용할 수 있습니다.
새로 배포하는 경우 현재 ZimaOS의 USB 스토리지 추가 워크플로를 사용하세요. 디스크가 관리되면 애플리케이션의 볼륨 매핑에 실제 스토리지 폴더를 사용하세요.
소스 디스크가 결국 ZimaOS 관리 경로 아래에 나타남
2025년 설치에서 표시된 정확한 경로를 다른 서버에 그대로 복사해서는 안 됩니다. 다음과 같은 장치 이름은 sda, sdb, 그리고 sdc 부팅 순서와 연결된 하드웨어에 따라 변경될 수 있습니다.
원시 블록 장치가 아닌 폴더를 매핑하세요
Docker 애플리케이션에는 일반적으로 원시 장치가 아니라 downloads 또는 media와 같은 디렉터리를 전달해야 합니다. /dev/sda1. ZimaOS가 파일 시스템을 마운트하면 컨테이너는 마운트된 파일 시스템에서 호스트 폴더를 전달받습니다.
호스트 스토리지가 컨테이너 볼륨이 되는 방식에 대한 현재 설명은 디스크 장치, 마운트 지점, 컨테이너 경로를 혼동하지 않도록 도와줍니다.
올바르게 마운트해도 권한 오류가 발생할 수 있습니다
소스 사용자는 다음 위치에 도달했습니다 /DATA/HDD1 이를 SABnzbd에 매핑했지만 애플리케이션이 선택한 다운로드 디렉터리를 사용할 수 없었습니다. 즉, 스토리지 가시성만이 유일한 문제는 아니었습니다.
Docker 프로세스는 컨테이너 내부의 사용자 또는 그룹으로 실행됩니다. 호스트 폴더가 다른 사용자의 소유이고 권한이 제한되어 있다면, 컨테이너가 경로를 볼 수는 있어도 파일을 생성하지 못할 수 있습니다.
PUID 999를 무작정 복사하지 마세요
한 커뮤니티 답변에서는 사용자에게 PUID를 1000에서 999로 변경하라고 안내했습니다. 이는 답변자의 ZimaOS 계정 모델에는 맞았을 수 있지만, 보편적인 고정값은 아닙니다.
PUID 또는 PGID를 변경하기 전에 실제 호스트 폴더의 소유자와 애플리케이션이 어떤 사용자로 실행되도록 설정되어 있는지 확인하세요. 한 설치에서 작동하는 숫자 값이 다른 설치에서는 다른 계정을 가리킬 수 있습니다.
재귀적 chmod와 chown은 강력하지만 파괴적입니다.
이후 커뮤니티 답변에서 재귀적 사용을 제안했습니다. chmod 775 및 chown 다운로드 경로에 적용합니다. 이러한 명령은 유용한 Linux 관리 도구일 수 있지만 대상 아래의 모든 파일과 디렉터리를 변경합니다. 이 스레드에서 IceWhale 직원이 게시한 명령은 아닙니다.
소유권을 재귀적으로 변경하기 전에:
- 정확한 대상 경로를 확인하세요.
- 파일 시스템이 일반적인 Linux 소유권을 지원하는지 확인하세요.
- 어떤 사용자나 서비스가 이미 해당 폴더를 사용하고 있는지 파악하세요.
- 폴더를 여러 애플리케이션이 공유하는 경우 중요한 메타데이터나 권한을 백업하세요.
파일 시스템 유형에 따라 권한 모델이 달라질 수 있습니다.
ext4 디스크는 Linux UID, GID 및 모드 비트를 직접 저장합니다. exFAT와 일부 NTFS 구성에서는 대신 마운트 수준 옵션을 통해 소유권을 표시할 수 있습니다. PUID를 변경해도 효과가 없다면 애플리케이션 설정을 반복해서 변경하기 전에 파일 시스템을 확인하세요.
미디어 앱을 위한 더 깔끔한 레이아웃
실용적인 구성은 다음과 같습니다.
- 내장 SSD: ZimaOS 시스템과 소규모 애플리케이션 런타임을 저장합니다.
- 대용량 외장 HDD: 미디어, 다운로드, 백업 및 기타 대용량 데이터를 저장합니다.
- 영구 AppData: 충분한 용량과 백업이 지원되는 스토리지 위치에 배치합니다.
- 각 앱에는 필요한 폴더만 명시적으로 볼륨 매핑합니다.
이렇게 하면 미디어 다운로드로 시스템 드라이브가 가득 차는 것을 방지하고, 대용량 미디어 파일과 애플리케이션 구성을 별도로 백업하기도 쉬워집니다.
ZimaOS 외장 HDD FAQ
외장 HDD를 /var 아래에 수동으로 마운트해야 하나요?
일반적인 최신 ZimaOS 사용에서는 아닙니다. Storage 인터페이스와 관리형 스토리지 경로를 사용하세요.
SABnzbd에서 /dev/sda1을 직접 매핑해야 하나요?
아니요. 마운트된 파일 시스템에서 일반 호스트 디렉터리를 컨테이너가 예상하는 다운로드 경로에 매핑하세요.
앱에서 폴더는 보이는데 쓰기에 실패하는 이유는 무엇인가요?
호스트 파일 시스템 권한이나 소유권 또는 컨테이너의 PUID/PGID 때문에 쓰기가 허용되지 않을 수 있습니다.
PUID 999는 표준 ZimaOS 값인가요?
아니요. 커뮤니티에 특화된 제안이므로 실제 시스템에서 확인해야 합니다.
