ZimaOS의 Docker는 읽기 전용 바인드 마운트를 지원하지만, 이 커뮤니티 스레드에서 논의된 ZimaOS Custom App WebUI는 다음과 같은 옵션을 안정적으로 보존하지 못합니다. :ro 또는 :readonly 볼륨 매핑을 편집할 때. 이는 Docker 자체의 제한이 아니라 WebUI의 제한입니다.
커뮤니티에서 권장하는 해결 방법은 Compose YAML을 내보내거나 직접 작성한 후 Docker Compose 또는 CLI로 애플리케이션을 생성하는 것입니다. IceWhale은 2025년 12월 향후 WebGUI에 더 많은 편집 옵션을 제공하도록 설계 중이라고 인정했습니다. 2026년 8월 24일의 후속 답변에서도 읽기 전용 UI 동작이 여전히 해결되지 않은 상태로 설명되었으므로, 현재 사용자는 UI가 플래그를 보존했다고 가정하지 말고 실제 컨테이너 마운트를 확인해야 합니다.
Docker는 읽기 전용 바인드 마운트를 지원합니다
Docker의 최신 바인드 마운트 문서는 ro 및 readonly 옵션을 모두 지원합니다.
짧은 -v 구문:
docker run -v /host/path:/container/path:ro IMAGE
Docker는 다음도 지원합니다. 읽기 전용 문서화된 바인드 마운트 구문에서 옵션으로 사용할 수 있습니다. --mount:
docker run --mount type=bind,src=/host/path,dst=/container/path,readonly IMAGE
읽기 전용 마운트는 컨테이너가 해당 마운트를 통해 파일을 쓰지 못하게 하면서도 호스트 파일을 읽을 수 있게 합니다.
ZimaOS WebUI에서 수행한 작업
원래 사용자는 WebUI에서 볼륨을 편집할 때 인터페이스가 뒤에 붙은 :ro 플래그. 한 커뮤니티 답변에서는 이 동작을 더 구체적으로 설명했습니다. 애플리케이션을 저장하거나 다시 열면 UI가 마운트를 다시 작성하면서 읽기 전용 옵션을 조용히 삭제한다는 것입니다.
이 구분이 중요합니다. 기본 Docker 엔진은 올바른 읽기 전용 마운트를 생성할 수 있지만, GUI의 볼륨 필드에는 모든 Docker 마운트 옵션이 반영되지 않을 수 있습니다.
IceWhale이 이 제한에 대해 밝힌 내용
2025년 12월 26일, Zima-Jerry는 향후 WebGUI에 더 많은 편집 옵션이 제공될 예정이며 인터페이스가 아직 설계 중이라고 답변했습니다. 이후 2026년 8월 24일에는 읽기 전용 설정에 대한 피드백이 없는 것이 보안 문제라고 지적하고 예상 일정을 묻는 답변이 추가되었습니다.
원본 스레드에는 UI 제한이 해결되었다는 IceWhale의 후속 확인이 없습니다. 따라서 현재 WebUI 필드가 안전하다고 가정하지 마세요. :ro 실제 컨테이너 마운트를 확인할 때까지.
읽기 전용 마운트에는 Docker Compose 사용
커뮤니티에서 제안한 해결 방법은 ZimaOS에서 앱의 Compose YAML을 내보내고, 마운트를 편집한 다음, 표준 Docker Compose로 컨테이너를 다시 생성하는 것이었습니다.
Docker Compose는 짧은 볼륨 구문의 세 번째 필드에서 액세스 모드를 지원합니다.
services:
app:
image: your/image:latest
volumes:
- /DATA/example:/data:ro
Docker의 최신 Compose 파일 레퍼런스에서는 마운트된 볼륨 또는 바인드 경로의 읽기 전용 액세스 모드로 ro를 설명합니다.
실용적인 ZimaOS 워크플로
- 사용자 지정 애플리케이션의 설정을 엽니다.
- 현재 ZimaOS 빌드에서 해당 옵션을 제공한다면 Compose YAML을 내보내세요.
- 편집하기 전에 백업 사본을 저장하세요.
- 추가
:ro컨테이너가 수정해서는 안 되는 호스트 경로에만 - YAML을 검증합니다.
- 권한이 있는 터미널을 사용해 Docker Compose를 실행하세요.
- 결과로 생성된 마운트를 확인한 후 민감한 파일에 사용하세요.
일반적인 Compose 명령은 다음과 같습니다.
docker compose up -d
Compose 파일이 있는 디렉터리에서 실행하고, 수동으로 관리되는 Compose 프로젝트는 ZimaOS UI에서 전적으로 관리되는 앱과 정확히 동일하게 동작하지 않을 수 있다는 점을 이해하세요.
마운트가 실제로 읽기 전용인지 확인하기
YAML이나 WebUI 레이블만 믿지 마세요. 실행 중인 컨테이너를 검사하세요.
docker inspect CONTAINER_NAME
다음 명령에서 Mounts 섹션에서 Docker는 마운트가 쓰기 가능한지 보여 줍니다. 올바른 읽기 전용 바인드 마운트는 다음과 같이 표시되어야 합니다.
"RW": false
Docker 공식 문서에서도 이 검사 방법을 사용해 읽기 전용 마운트를 확인합니다.
액세스 경계를 신중하게 테스트하기
일회용 또는 중요하지 않은 컨테이너 내부에서 마운트된 경로에 파일을 만들어 보는 방식으로도 테스트할 수 있습니다. 올바르게 구성된 읽기 전용 마운트라면 쓰기가 거부되어야 합니다.
중요한 파일을 덮어써서 테스트하지 마세요. 무해한 임시 파일 이름을 사용하고, 쓰기가 예상치 않게 성공하면 호스트에서 모든 테스트 파일을 삭제하세요.
:ro와 :readonly는 모두 Docker 옵션이지만 구문이 중요합니다
원래 제목에는 다음 두 내용이 모두 언급되어 있습니다. :ro 및 :readonly. Docker의 최신 바인드 마운트 문서에서는 해당 마운트 옵션 컨텍스트에서 두 이름을 모두 허용합니다. Compose에서 가장 널리 사용되는 짧은 구문은 다음과 같습니다.
/host/path:/container/path:ro
긴 구문이나 --mount 구문, 읽기 전용 또한 문서화되어 있습니다. ZimaOS 필드에 컨테이너 경로만 입력할 수 있는데 접미사를 붙여 넣기보다, 실제로 사용하는 Docker 구문에 맞는 옵션을 선택하세요.
읽기 전용 마운트와 읽기 전용 컨테이너 파일 시스템은 다릅니다
Docker Compose에도 서비스 수준의 read_only 옵션입니다. 이렇게 하면 컨테이너의 루트 파일 시스템이 읽기 전용이 됩니다. 특정 바인드 마운트를 읽기 전용으로 표시하는 것과는 다릅니다.
예를 들면 다음과 같습니다.
services:
app:
image: your/image:latest
read_only: true
애플리케이션이 읽기 전용 루트 파일 시스템에서 실행되도록 설계되었고 필요한 쓰기 가능 경로가 별도로 마운트된 경우에만 사용하세요.
플래그를 삭제하는 UI에서 볼륨을 다시 저장하지 마세요.
커뮤니티 답변에서는 읽기 전용 마운트를 수동으로 만든 후에는 ZimaOS WebUI를 볼륨 설정에 대해 사실상 쓰기 전용으로 취급하라고 제안했습니다. 우려되는 점은 해당 옵션을 이해하지 못하는 GUI를 통해 앱을 다시 열고 저장하면 마운트가 다음 없이 다시 작성될 수 있다는 것입니다. :ro.
나중에 UI를 변경하기 전에 현재 Compose 구성을 내보내고 이후 마운트를 확인하세요.
이것이 보안에 중요한 이유
읽기 전용 마운트는 애플리케이션이 구성, 미디어, 인증서, 백업 또는 소스 데이터에 접근할 수 있게 하면서 해당 파일을 수정할 권한은 부여하지 않을 때 자주 사용됩니다.
UI가 마운트를 읽기 전용에서 읽기/쓰기로 조용히 변경하면 컨테이너는 관리자가 의도한 것보다 더 많은 호스트 파일 시스템 접근 권한을 받게 됩니다. 그렇기 때문에 다음을 사용한 확인이 필요합니다. docker inspect UI 자체가 해당 옵션을 안정적으로 표시할 때까지는 중요합니다.
ZimaOS 읽기 전용 Docker 마운트 체크리스트
- 애플리케이션에 정말 읽기 권한만 필요한지 확인하세요.
- ZimaOS WebUI가 다음을 보존한다고 가정하지 마세요.
:ro. - Compose 파일을 내보내거나 작성하세요.
- 다음을 사용하세요.
/host:/container:ro의도한 마운트에 적용합니다. - 표준 Docker Compose로 프로젝트를 시작하세요.
- 다음으로 마운트를 확인하세요.
docker inspect. - 확인
RW입니다.false. - WebUI에서 애플리케이션을 다시 열거나 저장할 때 주의하세요.
- 복구를 위해 작동하는 Compose YAML 사본을 보관하세요.
ZimaOS Docker 읽기 전용 마운트 FAQ
ZimaOS Docker는 :ro를 지원하나요?
예. Docker 엔진/Compose 수준에서는 수정되었습니다. 소스 스레드에서는 이 제한을 ZimaOS WebUI의 마운트 옵션 처리 문제로 지목합니다.
WebUI 문제가 수정된 것으로 확인되었나요?
이 소스 스레드에는 없습니다. 2026년 8월 24일의 답변에서도 읽기 전용 UI 동작이 아직 해결되지 않은 문제로 설명되었습니다.
현재 가장 좋은 해결 방법은 무엇인가요?
Compose YAML 파일을 내보내거나 생성하고, 읽기 전용 마운트를 추가한 다음 실행하세요. docker compose up -d를 사용하고 실행 중인 컨테이너를 다음으로 확인하세요. docker inspect.
서비스의 read_only가 :ro 볼륨과 같은 의미인가요?
아니요. 서비스 수준의 read_only: true 컨테이너 루트 파일 시스템에 영향을 줍니다. :ro 볼륨은 해당 마운트에만 영향을 줍니다.
:ro가 조용히 사라지는 것이 왜 보안 문제인가요?
컨테이너가 관리자가 읽기 전용으로만 노출하려던 호스트 파일에 쓰기 권한을 얻을 수 있기 때문입니다.
