커뮤니티 솔루션

ZimaOS 앱이 주 저장소에 쓸 수 없음: 폴더 소유권과 앱별 권한 분리

A January 2026 thread where a first community reply blamed general ZimaOS storage ownership and suggested recreating folders in Files. The original poster disproved that as a universal fix with SFTPGo and Navidrome, leading the responder to revise the diagnosis to application-specific permission and feature behavior.

이 소스 스레드는 “앱이 RAID에 쓸 수 없다”는 문제를 곧바로 ZimaOS의 단일 권한 버그로 간주해서는 안 되는 이유를 보여 줍니다. 첫 번째 커뮤니티 답변에서는 App Store 컨테이너가 일반적으로 자체 AppData 외부에는 읽기 전용으로만 접근할 수 있으며, Files를 통해 폴더를 만들거나 “접근”해야 한다고 주장했습니다. 원 게시자는 정확히 그렇게 했지만 여전히 SFTPGo 폴더를 만들거나 Navidrome에서 음악을 삭제할 수 없었습니다.

이러한 반례가 나온 뒤 답변자는 설명을 수정했습니다. 파일 시스템 소유권은 여러 계층 중 하나일 뿐입니다. 각 애플리케이션에는 자체 컨테이너 사용자, 예상되는 내부 경로, 기능상의 제한도 있습니다. 이후의 수정된 설명이 더 신뢰할 수 있는 교훈입니다.

서로 다른 세 가지 권한 계층

  • ZimaOS 호스트 스토리지: 실제 RAID 또는 디스크 폴더와 해당 폴더의 소유권 및 모드입니다.
  • Docker 볼륨 매핑: 호스트 폴더가 컨테이너에 마운트되어 있는지, 그리고 마운트가 읽기 전용인지 여부입니다.
  • 애플리케이션 동작: 앱이 어떤 사용자로 실행되는지, 소프트웨어 자체가 파일 생성, 삭제 또는 이름 변경을 지원하는지 여부입니다.

어느 한 계층에서든 문제가 발생하면 “권한이 거부됨”으로 보일 수 있습니다.

Files에서 폴더를 만든다고 해서 항상 해결되는 것은 아닙니다

처음에는 ZimaOS Files를 통해 대상 폴더를 만들거나 이동하면 소유권이 올바르게 적용될 것이라는 제안이 있었습니다. 원 게시자는 RAID에 srv/data를 만들고 SFTPGo에서 해당 폴더를 지정했지만 여전히 권한 거부 오류가 발생했습니다.

따라서 Files를 사용하는 방법을 모든 앱에 적용되는 보장된 해결책으로 설명해서는 안 됩니다.

SFTPGo에는 실행 사용자 및 설정과 일치하는 쓰기 가능한 경로가 필요합니다

SFTPGo는 자체 권한과 가상 폴더 및 홈 디렉터리 규칙에 따라 실행됩니다. 호스트 디렉터리가 존재하고 표시되더라도 SFTPGo 프로세스에는 쓰기 권한이 없을 수 있습니다.

현재 배포 환경에서는 호스트 폴더, Docker 마운트 모드, 컨테이너 UID/GID, SFTPGo 사용자에게 설정된 홈 디렉터리 또는 가상 폴더를 함께 확인하세요.

소스의 답변자는 Navidrome을 라이브러리 관리 측면에서 읽기 전용으로 취급해야 하며, 해당 환경에서는 Navidrome 내부에서 트랙을 삭제하는 기능이 지원되지 않는다고 설명했습니다. 따라서 사용자가 노래를 삭제할 수 없었던 사실만으로 RAID 권한이 전반적으로 잘못되었다고 판단할 수는 없습니다.

특정 현재 버전의 Navidrome이 지원되는 파일 수정 기능을 문서화하고 있지 않다면 Files나 다른 파일 관리 도구를 사용해 원본 음악 파일을 관리하세요.

Docker 볼륨이 읽기 전용으로 마운트되어 있는지 확인하세요

볼륨 매핑은 읽기 전용 모드를 명시적으로 사용할 수 있습니다. 앱이 파일을 수정하도록 설계된 경우 호스트 폴더는 읽기/쓰기로 매핑되어야 하며, 프로세스의 실행 ID에는 호스트 파일 시스템의 해당 폴더에 대한 쓰기 권한이 있어야 합니다.

현재 ZimaOS에서는 애플리케이션 설정에서 앱 볼륨 매핑을 확인하고 수정할 수 있습니다.

현재 ZimaOS에서는 호스트 경로와 컨테이너 경로를 더 쉽게 확인할 수 있습니다

IceWhale은 이제 /config 또는 /media와 같은 앱 내부 경로와 이를 뒷받침하는 실제 스토리지 폴더의 관계를 문서화하고 있습니다.

파일 시스템 권한을 변경하기 전에 현재 ZimaOS 앱 경로 모델을 사용하세요.

진단을 위한 지름길로 chmod 777을 사용하지 마세요

광범위한 쓰기 권한은 실제 문제를 가리고 관련 없는 프로세스에 공유 데이터를 노출할 수 있습니다. 또한 앱이 의도적으로 볼륨을 읽기 전용으로 열거나 자체 설정을 통해 특정 경로를 거부하는 경우에는 문제를 해결하지 못합니다.

앱에 필요한 최소한의 소유권 또는 그룹 권한만 변경하세요.

더 나은 진단 순서

  1. ZimaOS에서 정확한 호스트 폴더를 확인합니다.
  2. 앱 볼륨이 해당 폴더를 예상되는 컨테이너 경로에 매핑하는지 확인합니다.
  3. 매핑이 읽기 전용인지 확인합니다.
  4. 컨테이너가 어떤 UID/GID 또는 사용자로 실행되는지 확인합니다.
  5. 해당 실행 ID가 호스트 폴더에 쓸 수 있는지 확인합니다.
  6. 애플리케이션 자체가 시도한 작업을 지원하는지 확인합니다.

앱 스토리지 권한 FAQ

ZimaOS Files에서 폴더를 다시 만든 것이 원래 SFTPGo 문제를 해결했나요?

아니요. 원 게시자는 그렇게 했지만 여전히 권한 거부 오류가 발생했습니다.

읽을 수 있는 RAID 폴더는 모든 앱에서 자동으로 쓰기 가능해지나요?

아니요. Docker 마운트 모드, 컨테이너 UID/GID, 애플리케이션 동작도 여전히 중요합니다.

Navidrome을 범용 파일 관리자로 사용해야 하나요?

아니요. 현재 애플리케이션이 파일 수정을 명시적으로 지원하지 않는다면 음악 원본은 Navidrome 외부에서 관리하세요.