突然読み取り専用になったDockerバインドマウントを修正する方法

Docker が読み取り専用パスを受け取った場合、またはホストのファイルシステムが書き込みを受け付けなくなった場合、Docker のバインドマウントは読み取り専用になります。

バインドマウントはホストパスをコンテナ内に直接公開するため、コンテナ単独で基盤となるディスク、ファイルシステム、マウントフラグ、セキュリティポリシーを修復することはできません。安全な復旧手順は、書き込みを停止し、コンテナのマウントとホストのマウントを比較し、読み取り専用の動作が設定によるものかエラーによって発生したものかを特定し、アプリケーションを再起動する前にストレージの健全性を回復することです。

読み取り専用になっているパスを確認する

コンテナ内のバインド先で影響のない書き込みテストを実行し、ホスト上のソースパスでも別の書き込みテストを行います。すべての権限エラーが読み取り専用ファイルシステムを意味するとは限らないため、正確なエラーを記録してください。

Docker フォーラムの事例では、読み取り専用の親バインドによって、Docker が入れ子になったマウントポイントを作成できない場合が示されています。必要なディレクトリを読み取り専用の親ファイルシステム上に作成できないためです。

ホストでは書き込めるのにコンテナでは書き込めない場合は、Docker のマウントオプションとセキュリティ制御を確認します。両方で読み取り専用ファイルシステムのエラーが発生する場合は、コンテナユーザーの変更をやめ、ホストのマウントとストレージデバイスの診断に移ります。

Docker の実効マウントフラグを確認する

現在の Compose ファイルだけでなく、実行中のコンテナ設定を調べます。ソース、宛先、伝播モード、および :ro、長い構文、オーバーライドファイル、デプロイツールによってマウントが読み取り専用に設定されていないかを確認してください。

Docker クライアントの課題では、実行時の設定が意図した読み書き可能な構成と異なるため、マウントされたパスが読み取り専用に見える事例が記録されています。重要な証拠は、実行中のコンテナに適用された実効マウントモードです。

マウントが意図的に読み取り専用になっている場合は、アプリケーションが実際に書き込みを必要とするときに限り、そのフラグを削除します。宣言を変更した後はコンテナを再作成してください。Compose ファイルを編集しても、既存のマウントは遡って変更されません。

ホストがファイルシステムを読み取り専用で再マウントしたか確認する

ホストのマウントテーブル、カーネルログ、ストレージログ、ファイルシステムの状態を確認し、I/O エラー、ジャーナル障害、チェックサムエラー、デバイスのリセット、保護目的の再マウントがないか調べます。保護機能が作動した理由を理解する前に、読み書き可能な状態への強制再マウントを行わないでください。

Unraid のサポート事例では、ファイルシステムが読み取り専用になった後に Docker の appdata が機能しなくなり、Plex ディレクトリの作成時にもエラーが発生しています。このパターンは、コンテナの権限設定ではなく、ホストファイルシステムの障害を示しています。

影響を受けたコンテナを停止し、診断情報を保持します。プラットフォームでサポートされているメンテナンス手順を通じて、ディスク、プール、ケーブル、ファイルシステム、ジャーナルを修復します。その後、データベースやメディアのコンテナで再び書き込みを許可する前に、ホストパスが正常であることを確認してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

入れ子になったマウントと重複するマウントを確認する

宛先が別のマウント済みディレクトリ内にある、すべてのバインドマウントと名前付きボリュームを一覧表示します。重複するマウントはディレクトリを隠したり、予期しないアクセス動作を引き継いだり、読み取り専用の親の下にマウントポイントを Docker が作成することを要求したりします。

Server Fault の議論では、関連するコンテナパスに、読み書き可能なマウントと、より広範囲を対象とする読み取り専用マウントを重ねると、分かりにくい結果になる可能性が説明されています。この領域はこのバッチ内の別の箇所でも使用されているため、ここでの実践的なルールは、権限を変更する前に宛先ツリー全体を把握することです。

コンテナの起動時にランタイムが作成する必要のあるディレクトリは、あらかじめホスト上に作成します。読み取り専用の親の下に書き込み可能な子をマウントする必要がある構成は避け、Compose では永続パスを明示してください。マウントツリーを簡素化した後は、コンテナを再作成します。

読み取り専用状態と権限・セキュリティポリシーを切り分ける

書き込みテストのエラーを、ソースディレクトリの所有者、モード、ACL、SELinux ラベル、AppArmor プロファイル、コンテナのユーザー ID と比較します。「権限がありません」と「読み取り専用ファイルシステム」は異なる障害であり、必要な修復方法も異なります。

ストレージのトラブルシューティングガイドでは、読み取り専用ボリュームのインシデントを、マウントフラグ、ファイルシステムエラー、セキュリティコンテキスト、ストレージドライバーの問題に分類しています。この分類により、ストレージ層の読み取り専用状態に対して、考えずに chmod 777 を実行するのを防げます。

権限が正しくない場合は、想定するコンテナの UID と GID を使用して、ホスト上の所有権または ACL を修正します。ファイルシステム自体が読み取り専用の場合、権限変更は失敗するため、ファイルシステム修復の代わりに行ってはいけません。

ホストでの書き込みテストに成功してからアプリケーションを再起動する

ホストパス上で一時ファイルの書き込み、同期、読み取り、削除を行い、同じマウント宣言とユーザーを使用する短時間のテストコンテナでも繰り返します。再起動後も想定したファイルシステムがマウントされたままであることを確認してください。

ストレージが書き込み可能になった後もアプリケーションが再起動ループを続ける場合は、コンテナの再起動依存関係を特定するための ZimaSpace ガイドを次の確認項目として参照してください。

ホストファイルシステムが正常で、実効 Docker マウントが意図どおり読み書き可能であり、アプリケーションが永続ファイルを更新でき、継続的な使用中に新たな I/O エラーやファイルシステムエラーが発生しないことを確認して、初めて修復は完了です。