LinuxでNo space left on deviceになる原因と確認手順｜df・inode・削除済みファイル
Linuxでファイル作成や書き込み時にNo space left on deviceが出たとき、いきなり削除せず、対象ファイルシステムの容量・inode・削除済みオープンファイルを順番に確認して原因を特定するページです。
このページの目的
「容量不足」「inode不足」「削除したファイルをプロセスが保持」のどこで詰まっているかを分けます。ゴールは、削除やサービス再起動の前に原因と影響範囲を確認することです。
最初にやること
エラーが出たパスのファイルシステムを対象に、まずdf -hとdf -iを記録します。対象ファイルがまだ存在しない場合は、作成先の親ディレクトリを指定します。
No space left on deviceが出るケースです。NFS、コンテナのoverlay/tmpfs、ストレージ製品固有の制限では確認方法が異なる場合があります。表示がPermission deniedならPermission deniedのトラブルガイドを確認してください。最初に対象ファイルシステムを確認する
No space left on deviceが出たら、サーバー全体の空き容量だけを見るのではなく、失敗したパスが載っているファイルシステムを確認します。たとえば/var/log/myapp/app.logへの書き込みで失敗した場合は、次のように対象パスを指定します。
dfにパスを渡すと、そのパスを含むファイルシステムの使用状況を確認できます。対象ファイルが未作成なら、作成先ディレクトリを指定します。
表示・確認結果から原因を絞る
| 確認結果・症状 | 主な確認先 | 次の確認 |
|---|---|---|
df -hでAvailがほぼ0 | データブロックの空き不足 | duで同じファイルシステム内の使用箇所を絞る |
df -iでIFreeが0またはIUse%が100%近い | inode不足 | 小さいファイルが大量にあるディレクトリを確認 |
dfでは大きく使用しているのにduでは見つからない | 削除済みファイルをプロセスが開いたまま、別マウントの数え方など | lsof +L1でリンク数0のオープンファイルを確認 |
df -hとdf -iの両方に余裕がある | 確認対象のファイルシステム違い、overlay/tmpfs、製品・FS固有の制限、ディスク以外のリソース上限など | エラー発生パスと実際のマウント先・実行環境、エラーを返した処理を再確認 |
Disk quota exceeded | ユーザー・グループ等のquota | No space left on deviceとは分けてquota設定を確認 |
df -hで容量不足を確認する
dfはファイルシステム全体の使用量と空き容量を確認するコマンドです。まずAvailとUse%を見ます。
Use%が高く、特にAvailがほぼ0なら、同じファイルシステムで容量を使っている場所を調べます。別ファイルシステムの空きが多くても、対象パス側が満杯なら書き込みは失敗します。
df -iでinode不足を確認する
ファイルシステムによっては、データ容量に余裕があってもファイル管理に使うinodeが不足すると、新しいファイルを作れなくなります。GNU df -iはブロック使用量の代わりにinode使用量を表示します。
IFreeが0、またはIUse%が100%近い場合は、小さいファイルが大量生成されていないかを確認します。GNU coreutils環境では、次のようにディレクトリ単位のinode使用数を絞れます。
df -iの結果だけで削除対象を決めず、どのアプリケーションが大量のファイルを生成したかまで確認してください。duで容量を使っている場所を探す
df -hで対象ファイルシステムの空きが少ないことを確認したら、duでディレクトリごとの使用量を絞ります。-xを付けると別ファイルシステムへまたがらずに調査できます。
大きいディレクトリが見つかったら、対象を一段ずつ絞ります。たとえば/var/logが大きい場合は次のように確認します。
duは多数のファイルを走査するため、大規模ファイルシステムではI/O負荷が上がることがあります。本番環境では対象範囲を絞り、実行タイミングも考慮してください。dfとduが合わないときは削除済みファイルを確認する
ファイルを削除してディレクトリエントリが消えても、そのファイルをプロセスが開いたままなら、最後のファイルディスクリプタが閉じられるまで領域が解放されないことがあります。この場合、duでは見えにくい一方でdfの使用量が減らないことがあります。
+L1はリンク数が1未満、つまりリンク数0のオープンファイルを絞るために使えます。SIZE/OFF、プロセス名、PIDを確認し、対象が大きな削除済みファイルか判断します。
kill -9するのは危険です。アプリケーションがサポートするログ再オープン、reload、計画的なrestartなど、サービスに合った方法を選びます。なお、lsof公式ドキュメントでは、NFSクライアント上のリンク数はローカルディスクと同じ前提では扱えないことが案内されています。NFSではこの確認だけで断定しないでください。
No space left on deviceは、必ずしもディスク容量だけを意味しません。たとえばLinuxのinotify_add_watch()は、ユーザー単位のinotify watch上限に達した場合などにもENOSPCを返します。ファイル監視アプリで発生している場合は、エラーを返した処理をログ等で確認し、必要に応じてsysctl fs.inotify.max_user_watchesも確認します。原因を特定せず上限値だけを引き上げないでください。確認結果から次の対応を決める
| 原因 | 修正前に確認すること | 対応の考え方 |
|---|---|---|
| データ容量不足 | 大きいファイルの用途、保存期間、バックアップ・監査要件 | 不要と確認できたデータの整理、正式なローテーション・アーカイブ、容量拡張を検討 |
| inode不足 | 大量ファイルの生成元、保持要件、再生成可否 | 生成元を止めずに削除だけ繰り返さず、保持・生成設計を見直す |
| 削除済みオープンファイル | 保持プロセス、サービス影響、再オープン手段 | サポートされたreload/reopen/restartでファイルを閉じ、解放を確認 |
| 容量・inodeとも正常 | 対象パスの実環境、コンテナ層、tmpfs/NFS、FS固有の制限 | ディスク不足と決めつけず、実際にエラーを返している層を再特定 |
修正後の確認と再発防止
対応後は、最初に記録したのと同じパスで再確認します。
- 対象ファイルシステムの
Availが回復したか - inode不足なら
IFreeが回復したか - 問題だった削除済みオープンファイルが消えたか
- 元のアプリケーションが正常に書き込みを再開したか
- 容量監視・inode監視・ログ保持設定など、同じ原因を早期検知できるか
df -h → df -i → du → 必要ならlsof +L1の順で確認すると、「何となくファイルを消す」対応を避けやすくなります。