LinuxサーバーやWSL2環境でコマンドを実行したり、パッケージをインストールしたり、Dockerコンテナを起動したりした瞬間に「No space left on device」というエラーが表示されて作業が完全に停止してしまった経験はないでしょうか。
このエラーは直訳すると「デバイス上に空き容量がありません」という意味です。ディスクが100%満杯になってしまっている場合はもちろん、多くのエンジニアを悩ませるのは「df -h コマンドで確認してもディスクにまだ数GB〜数十GBの空き容量が残っているのにエラーが消えない」という謎の現象です。
実は、Linuxにおける「No space left on device」の原因は単なるディスク容量（バイト数）の不足だけではありません。ファイル管理領域である「inode（アイノード）」の枯渇や、プロセスが削除済みファイルを掴んだまま離さない「オープンファイル問題」、さらにはWSL2やDocker、共有メモリ（/dev/shm）特有の制約など、複数の要因が絡み合っています。
この記事では、ディスク100%でエディタも保存できない極限状態からの緊急サバイバル手順から、「容量があるのにエラーが出る」真因の1分切り分けフロー、そして二度とパンクさせないための恒久対策まで、二次被害を防ぐ安全な手順を徹底解説します。
この記事で行うこと
前提条件・対象環境
【初動救急】ディスク100%で何も動かない時の緊急サバイバル手順
ディスク使用率が完全に100%に達している場合、以下のような二次被害が多発します。
この極限状態から脱出するために、まずは外部ツールに頼らず、既存の標準コマンドだけで即座に数MB〜数GBのレスキュー領域を確保します。 安全第一で、リスクの最も低い手順から順番に実施してください。
手順1：systemdジャーナルログを即時削減する（最も安全）
Ubuntu 22.04 / 24.04 / 26.04 や RHEL系などのモダンなLinux環境では、systemdのジャーナルログがディスクを数十GB圧迫しているケースが多いため、まずは専用コマンドで古いログを消去します。システムを壊すリスクが最も低く安全です。
現在のジャーナルログ使用量を確認するコマンド：
journalctl --disk-usage
ログ全体のサイズを直近100MBまでに制限して即座に古いログを消去するコマンド：
sudo journalctl --vacuum-size=100M
手順2：パッケージマネージャのキャッシュを一掃する（安全）
過去のアップデートでダウンロードされたパッケージアーカイブ（.deb や .rpm）を削除します。インストール済みのソフトウェアは消えないため安全です。
Ubuntu / Debian系の場合：
sudo apt clean
RHEL / AlmaLinux / Rocky Linux / Fedora系の場合：
sudo dnf clean all
手順3：肥大化したログを「リダイレクト」で安全に空にする
特定の大容量ログファイル（例：/var/log/syslog や /var/log/nginx/access.log）がディスクを食いつぶしている場合、rm で削除してはいけません。rm を使うと後述する「プロセスがファイルを掴んだまま容量が解放されない問題」が発生します。
最も確実な方法は、シェルリダイレクトを使ってファイルの中身だけを瞬時に空（0バイト）にすることです。
# Nginxのアクセスログを空にする例
sudo sh -c '> /var/log/nginx/access.log'
あるいは従来のsyslogが存在する環境の場合：
sudo sh -c '> /var/log/syslog'
安全上の重要注意点： この操作は必ず「中身を消しても問題のないログファイル」に限定してください。設定ファイルやデータベースのデータファイル（/var/lib/mysql/ や /var/lib/postgresql/ 配下のファイル）に対してリダイレクトを実行すると、データが全消失して復旧不能になる重大な二次災害を引き起こします。対象パスがログファイルであることを必ず指差し確認してください。
以上の3ステップを実行すれば、通常は即座に数百MB〜数GBの空き容量が確保され、エディタの保存やコマンドの実行が再び正常に行えるようになります。
【1分で判定】エラー原因の切り分け診断フロー
緊急領域が確保できたら、あるいは「そもそも空き容量はあるのにエラーが出る」という場合は、以下の表に従って真の原因を1分で特定します。
| 診断項目 | 実行コマンド | エラーの原因判定 |
|---|---|---|
| 1. バイト容量の枯渇 | df -h | Use% が100%のマウントポイントがある |
| 2. inode（ファイル数）の枯渇 | df -i | 容量はあるが IUse% が100%になっている |
| 3. 削除済みオープンファイル | sudo lsof +L1 | (deleted) なのにプロセスが掴んで離さない |
| 4. マウントポイントの被せ | 一時バインドマウント等で確認 | マウント前のディレクトリに巨大ファイルが隠れている |
| 5. 共有メモリ（shm）の枯渇 | df -h /dev/shm | /dev/shm の Use% が100%（DockerやAI学習時） |
順番に各原因の詳細と対処法を見ていきましょう。
原因1：通常のディスク容量（バイト数）不足
df -h を実行した際、マウントポイント（特にルート / や /var）の Use% が100%に達している状態です。
肥大化しているディレクトリの特定
標準コマンドの du を使って、どのディレクトリが容量を消費しているかを上から順番に探します。
sudo du -sh /* 2>/dev/null | sort -rh | head -n 10
例えば /var が異常に大きいことが判明した場合、次は /var の中身を調べます。
sudo du -sh /var/* 2>/dev/null | sort -rh | head -n 10
定番の肥大化ポイントと安全な掃除法
/var/log：古いログファイル（.gzや.1など）が溜まっている場合は削除します。/var/lib/docker：Dockerのイメージやビルドキャッシュが肥大化しています（後述）。/tmp：過去の一時ファイルが放置されている場合は不要なものを削除します。- 孤立パッケージ：過去のカーネル更新などで不要になったパッケージを削除します。
sudo apt autoremove --purge
安全上の重要注意点： ディスク使用率が100%の極限状態で apt autoremove を実行するのは絶対に避けてください。パッケージのアンインストール処理の途中でディスク書き込みエラーが発生すると、dpkgデータベースが不整合を起こしてパッケージ管理全体が破損する重大な二次障害に発展します。必ず前述の apt clean やジャーナルログ削減で十分な空き領域（最低1GB以上）を確保し、システムが復旧・安定した後に、削除対象のパッケージ一覧を目視確認した上で実行してください。
原因2：空き容量があるのに出る「inode枯渇」
「df -h で見ると使用率はまだ40%なのに、ファイルを作成しようとすると No space left on device と怒られる」という場合、原因のほぼ100%は inode（アイノード）の枯渇 です。
inode枯渇とは何か？
Linuxのファイルシステム（ext4など）では、ファイル1つごとに「inode」と呼ばれる管理データ（ファイル所有者、作成日時、実データブロックへのポインタなど）が1つ割り当てられます。 ファイルシステムのフォーマット時に作成可能な最大inode数が固定で決められているため、「1バイトの極小ファイル」であっても1つのinodeを消費します。
その結果、全体のデータ容量はガラ空きでも、メールスプール（/var/spool/postfix）やPHPのセッションファイル（/var/lib/php/sessions）、キャッシュファイルなどが数百万個作成されると、inodeの上限に達してしまい新規ファイルが一切作れなくなります。
inode使用率の確認
以下のコマンドを実行します。
df -i
表示結果の IUse%（inode使用率）を確認してください。これが100%に達しているパーティションが存在する場合、inode枯渇が原因です。
どのディレクトリにファイルが大量発生しているかの特定
特定のディレクトリ配下に存在するファイル数をカウントし、犯人のディレクトリを突き止めます。
ルート直下の各ディレクトリのファイル数を概算調査するコマンド：
sudo find / -xdev -maxdepth 2 -type d -exec sh -c 'echo -n "{}: "; find "{}" -xdev -type f 2>/dev/null | wc -l' \; | sort -k2 -n -r | head -n 15
怪しいディレクトリ（例：/var 配下）に絞って詳しく調査する場合：
sudo find /var -xdev -type f 2>/dev/null | cut -d "/" -f 1-4 | sort | uniq -c | sort -n -r | head -n 15
【実務の罠】大量ファイル削除で「Argument list too long」が出る問題
犯人のディレクトリ（例：/var/spool/clientmqueue）に数百万個のファイルが存在する場合、通常の感覚で rm * を実行すると以下のエラーが発生して削除できません。
bash: /bin/rm: Argument list too long
これは、シェル（Bash）が * を展開した結果、OSが許可するコマンドライン引数の最大長（ARG_MAX）を超えてしまうために起こります。
安全・高速な大量ファイル削除テクニック
この問題を回避して数百万件のファイルを確実に削除するには、以下の2つの手法を使います。
手法1：find -delete を使用する（確実で手軽）
シェル展開を経由せず、findコマンド自身がOSの unlink システムコールを順次呼び出すため、引数制限に引っかからずに安全に削除できます。
sudo find /path/to/target_dir -type f -delete
手法2：空ディレクトリを使った rsync 同期（数百万ファイル時の最速手段）
ファイル数が多すぎて find -delete でも何十分もかかる場合、空のダミーディレクトリを作成し、rsync の同期削除機能を使って一瞬で消し去る裏技が実務で非常に有効です。
# 空ディレクトリを作成
mkdir /tmp/empty_dir
# 空ディレクトリと同期させて中身を一括完全消去
sudo rsync -a --delete /tmp/empty_dir/ /path/to/target_dir/
# ダミーディレクトリを削除
rmdir /tmp/empty_dir
このrsync手法は、ファイルシステム内部のディレクトリエントリ操作を最適化して実行するため、大量ファイル削除において最も高速です。
安全上の重要注意点： find -delete や rsync --delete は、指定したディレクトリ内のファイルを一切確認なしで不可逆的に消去する極めて強力なコマンドです。もしパス指定を誤って /var や /home、あるいはルート / 直下などを指定してしまうと、OSや業務データが一瞬で全消去されシステムが完全に崩壊します。必ず削除対象のディレクトリ（例：/var/lib/php/sessions/ など）のフルパスを一文字ずつ指差し確認し、末尾のスラッシュの指定ミスがないことを確かめた上で慎重に実行してください。
原因3：ファイルを削除したのに空き容量が増えない「オープンファイル問題」
rm で巨大なログファイルを削除したのに、df -h の空き容量が全く増えず、エラーも消えない場合があります。
なぜ容量が空かないのか？
Linuxでは、ファイルを rm しても「ディレクトリエントリ（ファイル名とinodeの紐付け）」が削除されるだけで、そのファイルを起動中のプロセス（NginxやSyslog、Pythonなど）が開いたまま（Open状態）にしている限り、ディスク上の実データブロックは解放されません。
プロセスが掴んでいる削除済みファイルの特定
以下のコマンドを実行して、削除されたにもかかわらずプロセスに掴まれたままのファイル一覧を特定します。
sudo lsof +L1
または以下のパイプラインでも確認できます。
sudo lsof | grep deleted
出力結果の例：
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
nginx 12345 root 7w REG 8,1 4294967296 0 123456789 /var/log/nginx/access.log (deleted)
この例では、PID 12345 の nginx プロセスが、削除済みの約4GBの access.log を掴んだまま稼働していることがわかります。
解放手順：該当サービスの再起動
該当するプロセスのサービスを再起動すると、ファイルディスクリプタがクローズされ、その瞬間にディスク容量が100%解放されます。
sudo systemctl restart nginx
再起動後に df -h を実行すると、空き容量が正常に戻っていることが確認できます。
原因4：マウントポイントの被せ（隠れファイル消費）
Linuxならではの珍しい落とし穴として、「マウントポイントの被せ」があります。
例えば、/mnt/data というローカルディレクトリに以前大容量ファイル（バックアップなど）を置いたまま、後からその /mnt/data に対して新しい外付けSSDや別パーティションをマウントした場合です。 新しいストレージがマウントされると、マウントされる前に存在していた元々のファイルは見えなくなりますが、ルートパーティションのディスク容量は消費し続けます。
確認と対処法
バインドマウントを使って、マウントされる前のルートファイルシステムの実体を別の場所に露出させて確認します。
# ルートファイルシステム自体を別の一時ディレクトリにバインドマウント
sudo mkdir -p /mnt/root_inspect
sudo mount --bind / /mnt/root_inspect
# マウント下の元のディレクトリを調査
sudo du -sh /mnt/root_inspect/mnt/data
# 不要なファイルがあれば削除
sudo rm -rf /mnt/root_inspect/mnt/data/*
# 調査用バインドマウントを解除
sudo umount /mnt/root_inspect
sudo rmdir /mnt/root_inspect
原因5：モダン環境特有の落とし穴（WSL2 / Docker / AI開発）
現代のエンジニアリング環境で頻発する特有のケースについて解説します。
1. WSL2環境：Linux側で削除してもWindowsのCドライブが空かない
WSL2（Windows Subsystem for Linux）を使っている場合、Linux内でファイルをいくら削除しても、Windows側の仮想ハードディスクファイル（ext4.vhdx）は自動的には縮小されません。 そのため、Windows側でディスク逼迫が起きている場合は、仮想ディスクの圧縮（Shrink）を行う必要があります。 詳しい手順については、以下の当サイト個別記事をご覧ください。
2. Docker環境：Docker仮想ディスクの容量上限
Dockerコンテナ内でビルドやデータ処理を行っている最中に「No space left on device」が出る場合、ホストOSの容量不足だけでなく、Docker自体の仮想ストレージの上限に達しているケースがあります。 不要なビルドキャッシュ、停止中コンテナ、未使用イメージを一括整理する手順は、以下の記事で詳しく解説しています。
3. AI / 機械学習：PyTorch DataLoaderで発生する共有メモリ枯渇
PyTorchなどの深層学習フレームワークで num_workers > 0 を指定してマルチプロセスでデータを読み込む際、以下のようなエラーが出ることがあります。
RuntimeError: DataLoader worker (pid 1234) is killed by signal: Bus error.
または
OSError: [Errno 28] No space left on device
これは物理ディスクではなく、プロセス間通信に使われる POSIX共有メモリ（/dev/shm）の容量不足が原因です。
確認コマンド：
df -h /dev/shm
対処法：
- Dockerコンテナを起動する際に
--shm-size=8gや--ipc=hostを指定して共有メモリサイズを拡張する - ホストLinuxの場合は
/etc/fstabを編集して/dev/shmのマウントサイズ制限を引き上げる
二度と発生させないための恒久対策と日常管理
エラーを解消した後は、再発を防ぐための仕組みを導入しておきます。
1. logrotate の設定確認
/etc/logrotate.d/ 配下の設定を確認し、ログのローテーション周期（daily/weekly）や世代数（rotate 7など）、圧縮（compress）が正しく有効になっているか点検します。
2. systemd のジャーナルログ上限を固定する
/etc/systemd/journald.conf を編集し、ジャーナルログの最大サイズをあらかじめ固定しておくことで、ログによるディスクパンクを永久に防止できます。
[Journal]
SystemMaxUse=500M
設定を反映するには、以下のコマンドを実行します。
sudo systemctl restart systemd-journald
3. 日頃のディスク容量調査・監視ツールの活用
ディスクが100%に達する前に、日頃から「どのディレクトリがじわじわと肥大化しているか」を定期的にチェックしておくことが重要です。
標準の df や du コマンドよりも圧倒的に見やすく、TUI上で大容量ファイルを素早く探索できるモダンツール「duf」と「ncdu」の活用法については、以下の記事で導入から実践テクニックまで詳しく解説しています。
よくある質問
Q. 一時的に空きを作るため、/tmp 配下のファイルを全削除しても大丈夫ですか？
A. 稼働中のプロセスが使用している一時ソケットやロックファイルが含まれている場合があるため、sudo rm -rf /tmp/* のように一括で全削除するのは避けるのが無難です。作成日時が古いファイルに限定して削除するか（find /tmp -mtime +7 -delete 等）、可能な限りパッケージキャッシュ（apt clean）やログのサイズ制限（journalctl --vacuum-size）を優先してください。
Q. ルートユーザー用に確保された予約領域（Reserved Blocks）を解放して延命できますか？
A. はい、ext4ファイルシステムであれば、rootユーザー用の5%の予約領域を一時的に1%などに引き下げて緊急回避することができます。
# 予約領域を1%に変更するコマンド
sudo tune2fs -m 1 /dev/sda1
注意：tune2fs はext4/ext3/ext2専用コマンドです。XFSやBtrfsなど他のファイルシステムでは使用できません。また、/dev/sda1 の部分は df -h / コマンドの一番左列（Filesystem）で確認した実デバイス名に置き換えて実行してください。
これにより、即座に数GB〜数十GBの書き込み可能領域が一般ユーザーに開放されます。ただし、これはあくまで緊急延命措置であり、速やかに根本原因の特定とファイル整理を行ってください。
Q. inodeの上限数を後から増やすことはできますか？
A. 残念ながら、ext4ファイルシステムではフォーマット時にinode総数が決定されるため、後から変更することはできません。inode不足を根本的に解消するには、不要なファイルを削除するか、より大きなinode比率（または動的inodeをサポートするXFSやBtrfsなど）でファイルシステムを再構築する必要があります。
まとめ
Linuxで「No space left on device」が発生した際の対処手順をまとめます。
- 初動救急：ディスク100%で操作できない場合は、ログのリダイレクトゼロ化（
> logfile）やjournalctl --vacuum-size=100M、apt cleanで即座に空きを作る - 原因切り分け：バイト容量枯渇（
df -h）、inode枯渇（df -i）、削除済みオープンファイル（lsof +L1）の3大観点で診断する - inode枯渇時：数百万個のファイルには
rm *ではなくfind -deleteやrsync --deleteを活用してArgument list too longを回避する - オープンファイル時：ファイルを消しても容量が戻らない場合は
lsof +L1でプロセスを特定し、サービスを再起動する - 恒久対策：ジャーナルログの上限設定（
SystemMaxUse）を行い、日頃からdufやncduで容量をチェックする習慣をつける
ディスク容量の問題は、正しい切り分け手順さえ知っていれば慌てずに数分で解決できます。ぜひ本記事の手順を手元に控え、緊急時のトラブルシューティングに役立ててください。
次に読むおすすめ記事
日頃からディスク容量の肥大化をストレスなく監視・調査したい方は、見やすいカラー表示の duf と対話的探索ができる ncdu の解説記事もあわせて参考にしてください。
UbuntuやLinux環境全体の初期設定、日常コマンド、サーバー構築手順を体系的に学びたい方は、以下の完全ガイドもおすすめです。
