No space left on deviceの原因と直し方｜Linuxの容量・inode確認
No space left on deviceは、書き込みなどに必要な領域を確保できないときに出るエラーです。原因はディスク容量不足とは限りません。Linuxのdf -h・df -iで容量とinodeを確認し、削除済みファイルやファイルシステム固有の制限まで順番に切り分けます。
エラーの意味と主な原因
保存先の空き領域・inode・削除済みファイルの保持などを確認します。削除や再起動を始める前に、実際の書き込み先と原因を特定するのが目的です。
最初にやること
エラーが出たパスのファイルシステムを対象に、まずdf -hとdf -iを記録します。対象ファイルがまだ存在しない場合は、作成先の親ディレクトリを指定します。
df -h 書き込み先ディレクトリで容量を、df -i 書き込み先ディレクトリでinodeを確認します。両方に余裕があれば、マウント先・コンテナ層・エラーを返した処理を再確認します。結果別の分岐表へ進む。No space left on deviceが出るケースです。NFS、コンテナのoverlay/tmpfs、ストレージ製品固有の制限では確認方法が異なる場合があります。表示がPermission deniedならPermission deniedのトラブルガイドを確認してください。journalctlでエラーを確認する
現在・前回起動、特定サービス、期間、priorityを分けてjournalを確認します。
journalを確認 → 容量調査df・du・inodeでディスク使用量を確認
対象ファイルシステムを特定し、容量・inode・使用箇所を安全に絞ります。
容量を確認 → journal容量journalctlの容量確認と削減
systemd journalが容量を使っている場合に、保存量・vacuum・保持上限を確認します。
journalの容量管理 →関連するLinux障害調査ガイド
最初に対象ファイルシステムを確認する
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 -hでエラーが出たパスのAvailとUse%を確認します。空きがほぼない場合は「容量不足」の分岐へ進みます。
df -iでinode不足を確認する
df -hに余裕があるのにENOSPCなら、df -iでinode側も確認します。IFreeが0、またはIUse%が100%近ければ、小さいファイルの大量生成元を特定します。
duで容量を使っている場所を探す
容量不足と判断できた場合だけ、同じファイルシステム内でduを使って大きい場所を絞ります。ここではENOSPC原因判定の次工程として扱い、一般的な容量調査の説明は専用ページへ分離します。
duは多数のファイルを走査します。大規模環境では対象範囲を絞ってください。具体的な絞り込み手順は ディスク使用量確認ガイド を確認してください。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も確認します。原因を特定せず上限値だけを引き上げないでください。確認結果から次の対応を決める
| 原因 | 修正前に確認すること | 対応の考え方 |
|---|---|---|
| データ容量不足 | 大きいファイルの用途、保存期間、バックアップ・監査要件 | 不要と確認できたデータの整理、正式なローテーション・アーカイブ、容量拡張を検討。journalが肥大化している場合はjournal専用の容量確認へ |
| inode不足 | 大量ファイルの生成元、保持要件、再生成可否 | 生成元を止めずに削除だけ繰り返さず、保持・生成設計を見直す |
| 削除済みオープンファイル | 保持プロセス、サービス影響、再オープン手段 | サポートされたreload/reopen/restartでファイルを閉じ、解放を確認 |
| 容量・inodeとも正常 | 対象パスの実環境、コンテナ層、tmpfs/NFS、FS固有の制限 | ディスク不足と決めつけず、実際にエラーを返している層を再特定 |
修正後の確認と再発防止
対応後は、最初に記録したのと同じパスで再確認します。
- 対象ファイルシステムの
Availが回復したか - inode不足なら
IFreeが回復したか - 問題だった削除済みオープンファイルが消えたか
- 元のアプリケーションが正常に書き込みを再開したか
- 容量監視・inode監視・ログ保持設定など、同じ原因を早期検知できるか
df -h → df -i → du → 必要ならlsof +L1の順で確認すると、「何となくファイルを消す」対応を避けやすくなります。