Docker コンテナ内でのファイル I/O エラーの原因と対処

はじめに

Docker コンテナ内でファイルを読み書きしようとしたときに、以下のような I/O エラーが発生することがあります。

• Permission denied
• Read-only file system
• No space left on device

これらはアプリケーションの動作停止やデータ損失に直結するため、原因を正しく切り分けて対応することが重要です。
本記事では、コンテナ内でのファイル I/O エラーの代表的な原因と対処法を整理します。

よくある原因

Docker コンテナでのファイル I/O エラーは、主に次のパターンに分類できます。

1. 権限エラー
   • コンテナ内のユーザーに書き込み権限がない
   • マウントしたホスト側ディレクトリの権限不足
2. ファイルシステムの制約
   • ボリュームや一時ディレクトリが Read-only になっている
   • OverlayFS などの制限による書き込み不可
3. ストレージ不足
   • Docker デーモンの管理領域（/var/lib/docker）が満杯
   • コンテナのマウント先ディスク容量不足
4. SELinux / AppArmor などセキュリティ制御
   • ホスト側でセキュリティコンテキストによりアクセス拒否

確認ポイント

1. 権限確認

コンテナ内で以下を実行：

ls -ld /path/to/dir
whoami

ホスト側ディレクトリの権限も確認：

ls -ld /host/path

2. ファイルシステムの状態確認

mount | grep docker

対象ディレクトリが ro (read-only) になっていないか確認。

3. ディスク容量確認

ホスト側：

df -h

Docker 管理領域：

du -sh /var/lib/docker/*

4. セキュリティ制御確認

SELinux が有効かどうか：

getenforce

AppArmor プロファイルの確認：

docker inspect --format '{{.AppArmorProfile}}' コンテナ名

復旧手順

1. 権限エラーの解消

• ホスト側で権限を修正

sudo chown -R 1000:1000 /host/path
sudo chmod -R 755 /host/path

（1000:1000 はコンテナ内のユーザー UID/GID に合わせる）

• コンテナを root 権限で起動する方法（推奨はしないが応急処置可）

docker run -u root ...

2. Read-only ファイルシステムの修復

• コンテナが異常終了して read-only になった場合 → 再起動

docker restart コンテナ名

• docker run で --read-only オプションを指定していないか確認
• 必要に応じて書き込み用の tmpfs をマウント

docker run --tmpfs /tmp ...

3. ストレージ不足の解消

• 未使用のイメージ・コンテナ・ボリュームを削除

docker system prune -a
docker volume prune

• ディスクの拡張または /var/lib/docker のマウント先を大容量ディスクに移動

4. SELinux / AppArmor の調整

• SELinux が原因の場合：

sudo setenforce 0   # 一時的に無効化（検証用）

• 本番では :z または :Z オプションを付けてボリュームをマウント

docker run -v /host/path:/container/path:Z ...

再発防止策

• コンテナ内ユーザーとホスト側ディレクトリの UID/GID を一致させる
• ストレージ監視を導入（df, docker system df の定期監視）
• SELinux / AppArmor の正しい設定をあらかじめ行う
• 書き込みが必要な領域は ボリュームを明示的に利用し、コンテナ破棄で消えないよう管理

まとめ

• Docker コンテナ内のファイル I/O エラーは 権限／ファイルシステム／容量／セキュリティ の4つに大別できる
• 切り分けは「権限 → FS 状態 → 容量 → セキュリティ」の順で確認すると効率的
• 再発防止には UID/GID 管理とストレージ監視が効果的