テクノロジー · 実用ガイド
df に空きがあるのに Docker が「no space left」と表示？まず保存先を特定
Docker は別のマウントに書き込んでいるか、inode や選択中の Buildx キャッシュを使い切っている可能性があります。削除前に実パスを確認します。
ホスト全体の df が正常に見えても、Docker の書き込み先ファイルシステムには空きがない場合があります。失敗した pull、build、コンテナ書き込みは別マウントを使うか、バイトではなく inode が枯渇しているか、未確認の Buildx ビルダーの保存領域に属することがあります。
失敗したコマンドとエラーを保存し、対象デーモン、保存パス、選択中ビルダーを確認します。各パスを一つのファイルシステムへ対応させ、原因と所有者が一致してから削除します。
失敗した操作とコンテキストを保存
ENOSPC が pull、BuildKit、起動、アプリ書き込み、ログのどこで出たかを記録し、表示された完全なパスを保存します。所有者の異なる領域を同じ掃除で直せるとは限りません。 pull キャッシュの整理は bind mount のアプリ領域を直すとは限りません。コンテナの書き込み層と、アクセス可能なすべてのホストパスは同じ所有領域ではありません。
docker context show、docker info、docker buildx ls で対象デーモン、Docker Root Dir、ドライバー、ビルダーを確認します。リモートや Docker Desktop ではローカルの /var/lib/docker を仮定しません。 その場合はこのローカル手順を止め、実デーモンの文書に従った保存領域の表示を使います。
実パスをファイルシステムへ対応
各パスに findmnt --target PATH --output SOURCE,FSTYPE,SIZE,USED,AVAIL,USE%,TARGET を使います。Engine 29 では /var/lib/containerd も確認します。 この追加確認は containerd イメージストアを使う新規導入が対象です。Docker の現行文書は data-root がそのイメージとスナップショットを移さないと明記しています。
パス名からマウントを推測しません。サブディレクトリが別ボリュームやネットワーク FS の場合があります。bind mount やアプリのパスも個別に対応させます。 マウント先とソースを記録し、後の整理前後の測定を同じファイルシステムに揃えます。
ブロック不足と inode 不足を分離
df -h PATH と df -i PATH を実行します。バイトが残っていても inode がなければ小さなファイルを作れません。クォータ、読み取り専用、I/O エラーは別の分岐です。 inode が十分でもブロック不足は補えません。予約領域も別に確認し、ENOSPC だけで Docker オブジェクトが原因だとは決めません。
バイト不足なら大きい所有者、inode 不足ならファイル数を調べます。Docker、containerd、ビルダー、bind mount、ログとの関係を確認せず未知のツリーを消さないでください。 大きい領域を探すときは無関係なマウントへ意図せず入らず、状態を持つデータを保護します。
Prune の前に所有者を確認
docker system df -v でデーモン管理物を、docker buildx du --builder NAME で失敗したビルダーの記録を確認します。回収可能、共有、可変、使用中を区別します。 Docker は使用中の記録を --all でも削除しないと説明します。共有・可変の印は無条件に消せるという意味ではありません。
確認済みの停止コンテナ、未使用イメージ、限定キャッシュから処理します。system prune は広範囲で、ボリュームは明示指定が必要です。Compose、バックアップ、復旧要件を先に確認します。 名前付きボリュームも個別に確認し、永続データとロールバックの要件を点検してから破壊的操作を判断します。
満杯と証明したストアだけを移動
保持要件が保存先ファイルシステムの容量を超える場合は保守時間を設けます。書き込みを止め、設定とバックアップを保護し、所有者と権限を確認して、実デーモンまたは containerd の現行文書に従います。data-root だけでは Engine 29 の containerd イメージストアは移りません。
作業後、同じパスで findmnt と両方の df を再実行し、元の pull、build、write を繰り返します。イメージ、コンテナ、ボリューム、アプリデータも確認します。 デーモンの再起動やエラーが消えただけでは不十分です。元の操作と対象ファイルシステムの双方で意図した結果を確認します。
