カスタム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が実用的な回避策だった
元の投稿者は、ZimaOSのグラフィカルフォームでは指定できなくても、標準的なDocker Compose定義なら必要なマウントオプションを表現できることを確認しました。そのため、スレッドでの回避策は、ボリューム入力欄に頼るのではなく、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を推奨しています。
