오류 폴더 '/tv/'는 사용자 'abc'가 쓸 수 없습니다. 즉, Sonarr는 마운트된 디렉터리를 볼 수 있지만 컨테이너 내부에서 실행 중인 프로세스에는 해당 디렉터리에 쓸 권한이 없다는 뜻입니다. Radarr에서도 영화 루트 폴더 오류로 같은 문제가 발생할 수 있습니다.
2025년 7월 IceWhale 커뮤니티 사례에서 두 애플리케이션은 ZimaOS 앱 스토어에서 제공되었으며 기본값을 사용했습니다. PUID=1000 및 PGID=1000사용자의 미디어 폴더는 RAID 저장소 풀에 있었습니다. IceWhale 팀 구성원은 두 ID를 모두 다음과 같이 설정하라고 제안했습니다. 0그리고 원 게시자는 이렇게 설정하자 폴더에 쓰기가 가능해졌다고 확인했습니다. 이는 중요한 실제 사례 결과이지만, 애플리케이션을 root와 동등한 ID로 실행하면 일반적으로 필요한 범위를 훨씬 넘어서는 파일 시스템 접근 권한이 부여됩니다. 현재 LinuxServer.io 문서에서는 대신 PUID/PGID를 호스트 디렉터리의 소유자 또는 그룹과 일치시키는 것을 권장합니다.
'폴더를 사용자 abc가 쓸 수 없음'의 의미
해당 스레드의 ZimaOS 앱 스토어 패키지는 LinuxServer 스타일의 Sonarr 및 Radarr 컨테이너를 사용했습니다. 이러한 이미지는 일반적으로 다음과 같이 표시되는 내부 사용자로 애플리케이션 프로세스를 실행합니다. abc반면 PUID 및 PGID 호스트 파일 시스템에서 해당 내부 프로세스를 숫자 사용자 ID와 그룹 ID에 매핑합니다.
호스트 디렉터리가 다른 UID/GID에 속해 있고 해당 디렉터리의 권한 비트가 매핑된 프로세스의 쓰기를 허용하지 않으면, Sonarr 또는 Radarr는 마운트를 탐색할 수는 있지만 그 안에서 미디어를 생성, 이름 변경, 이동 또는 가져올 수 없습니다.
ZimaOS 앱 스토어의 원래 매핑
게시물에는 Radarr와 Sonarr의 구성 스크린샷이 각각 포함되어 있었습니다. 애플리케이션은 구성된 호스트 볼륨을 확인할 수 있었지만, 애플리케이션 내부에서는 루트 폴더를 생성할 수 없었습니다.
Sonarr 및 Radarr 오류
Sonarr에서 반환한 내용:
루트 폴더를 추가할 수 없음
폴더 '/tv/'는 사용자 'abc'가 쓸 수 없습니다.
Radarr에서도 영화 경로에 대해 이에 상응하는 문제가 나타났습니다.
커뮤니티 해결 방법: PUID=0 및 PGID=0
IceWhale 팀원이 다음과 같이 답변했습니다.
PUID=0
PGID=0원 게시자는 두 값을 모두 0으로 변경한 후 문제가 해결된 것으로 보인다고 보고했습니다. 따라서 이는 2025년 7월의 특정 ZimaOS 앱 스토어 구성에서 확인된 해결 방법입니다.
하지만 Linux에서 UID 0과 GID 0은 root 수준의 ID입니다. Sonarr 또는 Radarr를 이러한 ID로 실행하면 해당 경로가 컨테이너에 마운트된 경우 애플리케이션이 의도한 미디어 라이브러리보다 훨씬 광범위한 위치에 쓸 수 있습니다. 이 방법은 해당 권한으로 인해 부여되는 접근 범위를 이해하는 경우에만 진단 또는 호환성 해결 방법으로 사용하세요.
권장 해결 방법: PUID 및 PGID를 호스트 스토리지 소유권에 맞추기
현재 LinuxServer.io Sonarr 및 Radarr 문서에서는 다음과 같은 의도된 설계를 설명합니다. 호스트 스토리지 소유권에 맞게 PUID와 PGID를 설정합니다. PUID 및 PGID 매핑된 볼륨을 이미 소유하고 있거나 해당 볼륨에 대한 쓰기 권한이 있는 호스트 사용자/그룹으로 설정합니다.
LinuxServer의 지침에 따르면 호스트 볼륨이 컨테이너에 제공된 ID와 일치하지 않는 ID가 소유한 경우 권한 문제가 발생합니다. 권장 패턴은 다음과 같습니다.
PUID=1000
PGID=1000UID 1000과 GID 1000이 미디어 경로에 실제로 적합한 경우에만 사용합니다. 숫자 1000 본질적으로 올바른 값이 아니라, 일반적인 첫 번째 비root Linux 사용자 ID일 뿐입니다.
최신 LinuxServer Sonarr 문서와 LinuxServer Radarr 문서를 확인하세요.
스토리지 소유자 및 권한 확인 방법
ZimaOS 파일 인터페이스에 필요한 숫자 형식의 Linux 소유자/그룹 값이 표시되지 않으면, 권한이 있는 터미널에서 실제 호스트 경로를 확인합니다.
먼저 매핑된 실제 호스트 디렉터리를 확인합니다. /tv 또는 /movies그런 다음 다음 경로를 확인합니다.
ls -ldn /REAL/HOST/PATH
stat /REAL/HOST/PATH숫자로 표시되는 출력 결과를 통해 현재 어떤 UID와 GID가 디렉터리를 소유하고 있는지 확인할 수 있습니다. 이러한 명령을 컨테이너 전용 경로에 대해 실행하지 마세요. /tv 호스트 경로가 실제 호스트 경로인 경우가 아니라면 호스트에서
의도한 미디어 관리 계정을 호스트에서 사용할 수 있다면 다음 명령으로 해당 계정의 ID를 확인할 수 있습니다:
id USERNAME그런 다음 Sonarr/Radarr의 PUID 및 PGID 의도적으로 원하는 액세스 모델에 해당하는 ID로 설정하세요.
컨테이너 내부에서 /tv에 맹목적으로 chown을 실행하지 마세요
다른 커뮤니티 답변에서는 다음과 같이 제안했습니다:
sudo chown abc:abc /tv/그 조언은 맥락 없이 복사하면 위험합니다. 바인드 마운트된 디렉터리의 소유권은 결국 호스트의 숫자 ID로 표시됩니다. 이름 abc LinuxServer 컨테이너 내부에는 존재하지만 호스트에서 의미 있는 계정으로 존재하지 않을 수 있습니다. 소유권을 재귀적으로 변경하면 전체 미디어 라이브러리에 예기치 않은 영향을 줄 수도 있습니다.
사용하기 전에 chown다음을 확인하세요:
- 변경하려는 정확한 호스트 경로;
- 원하는 호스트 UID 및 GID;
- qBittorrent, SABnzbd, Jellyfin 또는 SMB 사용자와 같은 다른 서비스가 동일한 파일에 액세스해야 하는지 여부;
- 소유권을 변경하는 것보다 공유 그룹을 사용하는 편이 더 적절한지 여부
중요한 설정을 백업하고, 영향 범위를 파악하기 전까지는 재귀적 권한 변경을 피하세요.
전체 ARR 스택에서 공유 미디어 권한을 계획하세요
Sonarr와 Radarr는 단독으로 작동하는 경우가 드뭅니다. 다운로드 클라이언트가 먼저 파일을 생성한 다음 Sonarr 또는 Radarr가 파일을 가져오고, Jellyfin이 그 결과를 읽을 수 있습니다. 모든 컨테이너가 서로 관련 없는 ID와 마운트를 사용하면 한 애플리케이션이 생성한 파일을 다른 애플리케이션이 수정하지 못할 수 있습니다.
더 깔끔한 설계는 공유 데이터 세트에 대해 애플리케이션들이 공통 그룹 또는 호환 가능한 PUID/PGID 매핑을 사용하도록 하는 것입니다. LinuxServer는 다운로드 클라이언트와 ARR 애플리케이션이 필요한 경우 하드 링크나 원자적 이동을 사용할 수 있도록 계획적으로 볼륨 경로를 구성할 것을 권장합니다.
예를 들어 다운로드와 미디어를 서로 관련 없는 별도 마운트로 취급하는 대신, 하나의 공유 호스트 데이터 트리를 사용하면 권한과 경로의 일관성을 더 쉽게 파악할 수 있습니다.
/data
├── downloads
├── media
│ ├── movies
│ └── tv정확한 ZimaOS 경로는 스토리지 풀에 따라 다르므로 그대로 복사해서는 안 됩니다.
루트 ID 우회 방법은 언제 유용한가요?
PUID/PGID를 다음으로 설정: 0 짧은 진단 방법으로 유용할 수 있습니다:
- 오류가 즉시 사라진다면 컨테이너 마운트 자체는 올바를 가능성이 높습니다.
- 그러면 남은 문제는 호스트 소유권 또는 권한 매핑일 가능성이 큽니다.
확인되면, 장기적으로는 컨테이너에 미디어 및 다운로드 경로에 필요한 권한만 부여하는 것이 더 안전한 목표입니다. 정확한 ZimaOS 스토리지 모델에서 비루트 매핑이 현실적으로 어렵다면 루트 ID가 필요한 이유를 문서화하고 마운트된 디렉터리를 신중하게 제한하세요.
PUID 또는 PGID 변경 후 앱 다시 시작
PUID와 PGID는 컨테이너가 시작될 때 적용됩니다. ZimaOS에서 변경한 후:
- 앱 설정을 저장하세요.
- ZimaOS를 통해 Sonarr/Radarr 컨테이너를 다시 시작하거나 재생성하세요.
- 루트 폴더 설정을 다시 여세요.
- 매핑된 폴더를 생성하거나 선택해 보세요.
폴더에 계속 쓸 수 없다면 호스트 디렉터리의 숫자 소유권 및 권한 모드를 현재 컨테이너에서 사용하는 ID와 비교하세요.
Sonarr/Radarr ZimaOS 권한 체크리스트
- 호스트 미디어 경로가 Sonarr 또는 Radarr에 마운트되어 있는지 확인하세요.
- 앱 내부에서 선택한 경로가 컨테이너 경로인지 확인하세요.
- 호스트 경로의 UID, GID 및 권한 비트를 확인하세요.
- 현재 값을 확인하세요
PUID및PGIDZimaOS 앱 설정에서 - 의도한 호스트 소유자/그룹과 일치하는 ID를 우선 사용하세요.
- ID를 변경한 후 컨테이너를 다시 시작하세요.
- PUID/PGID 0은 root 수준의 접근 권한을 부여한다는 점을 이해한 경우에만 사용하세요.
- 광범위한 재귀 적용은 피하세요
chmod 777또는 무작정chown수정합니다. - 다운로드 클라이언트와 미디어 서버가 호환되는 공유 권한 모델을 사용하도록 설정하세요.
Sonarr 및 Radarr 권한 FAQ
사용자 abc란 무엇인가요?
abc LinuxServer.io 컨테이너에서 일반적으로 사용하는 내부 서비스 사용자 이름입니다. PUID와 PGID는 매핑된 볼륨에 접근할 때 프로세스가 사용하는 호스트의 숫자 ID를 결정합니다.
PUID=1000 및 PGID=1000이 실패하는 이유는 무엇인가요?
이 값은 UID/GID 1000에 호스트 미디어 디렉터리에 필요한 접근 권한이 있을 때만 작동합니다. ZimaOS RAID 디렉터리가 다른 사용자나 그룹에 속해 있다면 컨테이너가 디렉터리를 볼 수는 있어도 쓸 수 없을 수 있습니다.
PUID=0 및 PGID=0으로 문제가 해결되나요?
작성자가 확인한 바에 따르면, 원래 커뮤니티 사례에서는 이 방법으로 문제가 해결되었습니다. 하지만 매핑된 파일 시스템 내부에서 root와 동등한 접근 권한도 부여하므로, 영구적인 기본 설정으로 자동 채택해서는 안 됩니다.
미디어 폴더에 chmod 777을 적용해야 하나요?
기본 해결책으로는 권장하지 않습니다. 모든 사용자에게 쓰기 권한을 허용하면 권한 범위가 불필요하게 넓어지고 실제 소유권 불일치를 가릴 수 있습니다. 대신 컨테이너 ID와 공유 그룹 권한을 의도에 맞게 설정하세요.
Sonarr, Radarr, 다운로드 클라이언트가 동일한 PUID/PGID를 사용해야 하나요?
항상 동일한 사용자 ID가 필요하지는 않지만, 공유하는 모든 파일과 폴더에 대해 호환되는 소유권/그룹 모델이 필요합니다. 일관된 공유 그룹을 사용하는 것은 가져오기 및 이름 변경 실패를 방지하는 일반적인 방법입니다.
