이 스레드는 ZimaOS에서 읽기 전용 파일 시스템을 비활성화하는 방법에 관한 질문으로 시작했지만, 실제 문제는 그게 아니었습니다. 스택을 확인한 결과, 작성자는 Compose 파일에서 상대 볼륨 경로를 사용하고 있었습니다.
이 구분은 중요합니다. 이 경우 호스트 파일 시스템 권한을 변경하거나 시스템 경로를 다시 마운트하는 것은 잘못된 해결 방법이었기 때문입니다.
ZimaOS를 변경하기 전에 Compose 파일 확인하기
컨테이너 스택이 경로를 생성하거나 해당 경로에 쓸 수 없는 경우, 먼저 Compose 파일이 컨테이너에 어떤 경로를 마운트하는지 확인하세요. 바인드 마운트는 호스트 경로를 참조할 수 있으며, 이름이 지정된 볼륨은 Docker가 관리합니다. 최신 Docker Compose 볼륨 규칙에 따르면 상대 호스트 경로는 Compose 프로젝트 위치를 기준으로 확인됩니다.
셀프 호스팅 NAS에서는 모호한 상대 경로보다 명시적인 영구 경로가 이해하고 관리하기 쉬운 경우가 많습니다. 실제 소스 디렉터리가 존재하고 쓰기 가능한지 확인할 수 있기 때문입니다.
읽기 전용이라는 추정이 잘못된 이유
실제 읽기 전용 파일 시스템 문제라면 일반적으로 여러 Compose 경로에 영향을 주며, 실제 마운트 상태와 시스템 로그를 바탕으로 진단해야 합니다. 이 스레드에서 사용자는 ZimaOS 보호 기능을 해제할 필요가 없었습니다. 대신 상대 볼륨 설정을 수정했습니다.
커뮤니티에서 제안한 방법
근본 원인이 확인되기 전, 한 커뮤니티 답변에서는 ZimaOS 개발자 모드를 열고 웹 터미널에서 root 권한으로 필요한 디렉터리를 수동 생성하라고 제안했습니다. 의도한 호스트 경로가 실제로 존재하지 않을 때는 유용할 수 있지만, Compose 경로 확인을 대신하기보다는 그 이후에 시도해야 합니다.
더 안전한 문제 해결 순서
- Compose 파일의 모든
volumes:항목을 확인합니다. - 각 소스가 이름이 지정된 볼륨인지, 절대 호스트 경로인지, 상대 경로인지 확인합니다.
- 예상 호스트 디렉터리가 존재하는지 확인합니다.
- 컨테이너가
:ro또는read_only: true로 명시적으로 마운트되지 않았는지 확인합니다. - 컨테이너 설정 외부에서도 동일한 쓰기 오류가 계속 발생하는 경우에만 호스트 파일 시스템의 마운트 상태를 조사합니다.
현재 Docker 및 Portainer 관련 내용
현재 ZimaOS 배포 환경에서 Portainer 하드웨어 요구 사항은 Portainer의 영구 데이터와 런타임에 대한 전반적인 맥락을 제공하며, 첫 번째 Docker 앱은 ZimaOS 애플리케이션이 영구 데이터를 컨테이너에 매핑하는 방식을 설명합니다. 마운트가 단순히 잘못된 경로를 가리키는 것이 아니라 실제로 읽기 전용인 경우에는 Docker 바인드 마운트 해결 방법에서 :ro로 설정된 마운트와 호스트 파일 시스템이 쓰기를 거부하기 시작한 경우를 구분해 설명합니다.
Docker의 Docker 바인드 마운트 규칙에 따르면 바인드 마운트는 호스트 소스 경로를 사용할 수 있으며, 읽기 전용 동작은 readonly 또는 ro로 명시적으로 제어됩니다. 공식 Portainer 스택 동작에서는 Portainer 스택을 서로 연관된 서비스 집합으로 정의합니다. 따라서 ZimaOS 호스트 자체를 변경하기 전에 Compose 파일을 확인해야 합니다.
결론
보고된 Portainer 스택 오류는 읽기 전용 파일 시스템을 비활성화해서 해결된 것이 아닙니다. 사용자는 docker-compose.yml의 상대 볼륨 경로를 수정했습니다. 유사한 ZimaOS 컨테이너 오류가 발생하면 호스트 수준의 파일 시스템을 변경하기 전에 Compose 마운트 정의부터 확인하세요.
