ZimaOS Docker：:roボリュームに関するWebUIの制限と修正

ZimaOS上のDockerは読み取り専用バインドマウントに対応していますが、このコミュニティスレッドで取り上げられたZimaOS Custom App WebUIは、次のようなオプションを確実に保持しません。 :ro または :readonly ボリュームマッピングを編集する際に。そのWebUIの制限は、Docker自体の制限ではありません。

コミュニティでの回避策は、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はさらに、 readonly を、ドキュメントに記載されたバインドマウント構文のオプションとして指定できます。 --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 では、短縮ボリューム構文の 3 番目のフィールドとしてアクセスモードを指定できます。

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 構文、 readonly についても記載されています。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 volume は、その特定のマウントにのみ影響します。

:ro がひそかに失われると、なぜセキュリティ上の問題になるのですか？

コンテナが、管理者が読み取り専用で公開するつもりだったホストファイルへの書き込みアクセスを得る可能性があるためです。