사용자 지정 Docker 앱에는 단순한 호스트-컨테이너 경로 매핑 이상의 설정이 필요할 수 있습니다. 2026년 1월 ZimaOS 토론에서는 SSHFS 기반 컨테이너에 :shared 옵션을 사용한 마운트 전파가 필요했습니다. ZimaOS 사용자 지정 앱의 볼륨 입력란에 해당 옵션을 입력하면 컨테이너가 실행되지 않았지만, 옵션 없이 동일한 마운트를 사용하면 애플리케이션에 필요한 호스트 측 동작이 제공되지 않았습니다.
해당 스레드에서 중요한 구분은 ZimaOS WebUI 편집기와 기반 Docker 스택 사이에 있습니다. 커뮤니티 테스트 결과 Docker Compose 또는 CLI 작업에서는 Docker 볼륨 및 바인드 마운트 옵션이 작동할 수 있었지만, WebUI는 :shared, :ro, :readonly와 같은 옵션을 올바르게 구문 분석하거나 보존하지 못했습니다.
제한은 표준 Docker가 아니라 WebUI에 있었습니다
질문자는 처음에 ZimaOS 자체에 고급 볼륨 플래그 지원이 없는지 물었습니다. 테스트 후 논의는 더 좁은 결론으로 정리되었습니다. Docker 엔진은 해당 옵션을 사용할 수 있었지만, ZimaOS 사용자 지정 앱 양식에서는 옵션이 올바르게 표시되거나 보존되지 않았습니다.
2025년 12월의 관련 스레드에서도 읽기 전용 마운트에 대해 같은 결론에 도달했습니다. ZimaOS 팀 구성원인 Zima-Jerry는 향후 WebGUI 버전에 더 많은 편집기 옵션이 포함될 예정이며 설계 작업이 진행 중이라고 답변했습니다.
이러한 당시의 상태를 약속이나 출시 일정으로 해석해서는 안 됩니다. 2026년 8월 24일, 다른 커뮤니티 구성원은 읽기 전용 UI 문제가 여전히 해결되지 않았다고 알리며 예상 일정을 물었지만, 해당 스레드에는 이후 팀의 답변이 없었습니다.
일부 컨테이너에서 :shared가 중요한 이유
원래 사례는 SSHFS와 관련이 있었습니다. 컨테이너는 원격 파일 시스템을 마운트하는 데 사용되었으며, 사용자는 그 결과로 생성된 마운트가 컨테이너 네임스페이스 외부로 전파되기를 원했습니다. 이러한 작업 흐름에서는 호스트 경로를 컨테이너에 단순히 매핑하는 것만으로는 필요한 마운트 전파 옵션을 사용하는 것과 같은 효과를 낼 수 없습니다.
따라서 일반적인 영구 앱 데이터 볼륨만을 기준으로 한 조언으로는 보고된 SSHFS 사용 사례를 해결할 수 없었습니다. 컨테이너마다 서로 다른 마운트 의미 체계가 필요할 수 있습니다.
현재 Docker의 동작 및 구문은 Docker 바인드 마운트 및 전파 문서를 참조하세요.
같은 UI 문제가 :ro 및 :readonly에도 영향을 미쳤습니다
연결된 2025년 12월 논의에는 읽기 전용 마운트와 관련된 유사한 문제가 기록되어 있습니다. 한 커뮤니티 응답자는 볼륨 구성을 편집하거나 다시 열 때 ZimaOS UI가 마운트를 다시 작성하면서 :ro 접미사를 제거할 수 있다고 보고했습니다.
이는 단순한 편의성 이상의 문제입니다. 읽기 전용으로 지정된 마운트가 조용히 쓰기 가능 상태로 바뀌어서는 안 됩니다. 읽기 전용 액세스가 보안 또는 데이터 보호 모델의 일부라면, 과거 WebUI에 입력한 내용만 믿지 말고 실제 컨테이너 마운트 구성을 확인하세요.
Docker Compose가 실용적인 우회 방법이었습니다
질문자는 표준 Docker Compose 정의를 사용하면 ZimaOS 그래픽 양식에서 표현할 수 없는 필수 마운트 옵션도 지정할 수 있다고 확인했습니다. 따라서 해당 스레드의 우회 방법은 볼륨 입력란에 의존하지 않고 Compose를 통해 고급 마운트를 관리하는 것이었습니다.
2026년 8월에 업데이트된 현재 ZimaOS 문서에서도 Docker Compose를 고급 사용자를 위한 경로로 설명하며, 표준 컨테이너 런타임 구성은 Docker Compose에서 관리한다고 명시합니다. 현재 ZimaOS 기능 문서와 현재 ZimaOS Docker Compose 참고 문서를 참조하세요.
이러한 최신 문서는 Compose 지원을 확인해 주지만, 모든 Docker 마운트 옵션을 위한 전용 WebUI 컨트롤이 있다고 설명하지는 않습니다. 마운트 플래그가 필수라면 GUI가 해당 플래그를 보존했다고 가정하지 말고, 결과로 생성된 Compose 및 런타임 구성을 확인하세요.
이 스레드만으로 알 수 없는 사항
- 일반적인 ZimaOS 앱 데이터 볼륨에
:shared가 필요하다는 뜻은 아닙니다. - ZimaOS의 Docker가 고급 마운트 지원을 제공하지 않는다는 뜻은 아닙니다.
- 현재의 모든 WebUI 버전이 2026년 1월 빌드와 정확히 동일하게 동작한다는 뜻은 아닙니다.
- 추가적인 볼륨 옵션 컨트롤의 공식 제공 날짜를 확정하는 내용도 아닙니다.
ZimaOS 볼륨 옵션 FAQ
ZimaOS 사용자 지정 앱 WebUI에서 :shared를 사용할 수 있나요?
2026년 1월 원본 스레드에서는 WebUI가 해당 옵션을 올바르게 처리하지 못했습니다. 필요한 동작은 Docker Compose를 통해 작동했습니다.
ZimaOS의 Docker는 :ro 및 :readonly를 지원하나요?
해당 논의에서는 Docker 지원과 과거 UI의 제한을 구분합니다. Docker는 읽기 전용 마운트 옵션을 지원하지만, 해당 스레드에서 다룬 ZimaOS WebUI는 이를 안정적으로 보존하지 못했습니다.
WebUI의 제한이 공식적으로 인정되었나요?
예. 관련된 2025년 12월 스레드에서 Zima-Jerry는 향후 WebGUI에 더 많은 편집기 옵션을 추가하기 위한 설계가 진행 중이라고 밝혔습니다. 출시 날짜는 제시되지 않았습니다.
현재는 문제가 해결되었나요?
원본 자료만으로는 해결 여부를 확인할 수 없습니다. 2026년 8월 24일의 커뮤니티 후속 글에서도 읽기 전용 UI 문제가 해결되지 않은 상태로 설명되었으며, 현재 ZimaOS 문서는 고급 구성을 위해 Docker Compose를 계속 권장하고 있습니다.
