No space left on deviceの原因究明方法と安全な解決法
ディスク容量がいっぱいになり、ファイルが作成できなくなるNo space left on deviceエラーは、サーバ運用で頻出するトラブルです。
もしこれが本番サーバーであるなら早急に解決することが必要です。なぜなら、このエラーが出ている状態ではほとんどの処理を実行することができない状況に陥っており、サービス停止を意味するからです。
本記事では、原因の調査方法から不要ファイルの安全な削除、再発防止までのヒントを一気通貫で解説します。
目次
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
No space left on deviceとは？
運用中の Web サーバやデータベースで急にファイル書き込みが失敗すると、サービスの停止やデータ消失のリスクが高まります。本セクションでは、発生するエラー例を確認し、記事全体の流れを把握します。
$ touch /tmp/testfile
touch: cannot touch '/tmp/testfile': No space left on device上記のように、ディスク容量が枯渇すると基本的なファイル操作が全て失敗します。この記事では以下の手順で解決策を解説します。
- ディスク使用率の全体把握
- 大容量ディレクトリ・ファイルの特定
- 主要原因ごとの対策
- 自動化と運用上の注意点
No space left on deviceが出たときのディスク使用率把握と原因究明
ディスクトラブル対応の第一歩は「何がどれだけ容量を使っているか」を把握することです。ここでは基本的なコマンドと実行例を示します。
空き容量の確認
df -hで人間に読みやすい単位で全体の容量を確認し、df -iで inode の使用状況をチェックします。
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev-root 20G 19G 1.1G 95% /$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev-root 1310720 110234 1200486 9% /Use%が高い場合はディスク容量不足の可能性があり、IUse% が高い場合はinode 枯渇の可能性があります。
この例だと、/dev-rootに原因がありそうということが分かります。
inode 枯渇とは
ファイルシステムでは、各ファイルやディレクトリに対して“inode”と呼ばれる管理情報領域が割り当てられます。inode には以下のような情報が含まれます。
- ファイルの所有者・グループ
- パーミッション（アクセス権）
- タイムスタンプ（作成日時、更新日時など）
- データブロックの配置情報（データへのポインタ）
inode が枯渇する状況では、ディスク上の空き容量が十分に残っていても、新しいファイルやディレクトリを作成できなくなります。特に、小さなファイルが多数生成されるログファイルやキャッシュ、一時ファイルなどが大量に溜まる環境で起こりやすい問題です。主な対策方法は以下の3つです。
- 古い小ファイルの削除やログローテーション設定の見直し
/tmpやアプリケーションの一時ディレクトリを定期的にクリア- 必要に応じてファイルシステムを再フォーマットし、inode 数を増やす
以上を踏まえ、ディスク容量（df -h）と合わせて inode 使用率（df -i）を確認し、トラブルの切り分けを行います。
ルート直下のディレクトリ別使用量
du --max-depth=1でルート直下の各ディレクトリ容量を集計し、sort -hrでサイズ順にソートします。
$ sudo du -h --max-depth=1 / | sort -hr
21G /
12G /var
2.4G /snap上記例では/var が 12 GB と最大の消費先で、なにかありそうです。
深掘り調査
大きなディレクトリが分かったらさらに内部を掘り下げます。
$ sudo du -h --max-depth=1 /var | sort -hr
12G /var
9.0G /var/lib
2.0G /var/www/var/libが 9 GB を占めていますね。更に深堀りし、ファイル単位でディスク使用量を見てみることにします。
ファイル単位での絞り込み
特定ディレクトリに関わらず、システム全体から大きなファイルを直接探したい場合に有効です。
$ sudo find / -type f -size +100M -exec ls -lh {} \; | sort -k5 -hr | head -n5
-rw-r--r-- 1 root root 2.4G Jul 10 12:34 /var/log/syslog.1
-rw-r--r-- 1 root root 1.8G Jul 9 08:21 /var/lib/mysql/binlog.000490ここで大きなログやバイナリログをピンポイントで発見できます。
No space left on deviceの典型的な原因と対策例
ここでは、よくある原因ごとに具体的な対策手順と実行例をまとめます。
ログファイル (/var/log)
ログファイルは定期的にローテーションされますが、古いログが溜まると数 GB になることがあります。
$ sudo du -h --max-depth=1 /var/log | sort -hr
2.4G /var/log
1.2G /var/log/journalジャーナルログの削減
$ sudo journalctl --vacuum-time=2weeks
Vacuuming done, freed 1.1G古いログファイルの削除
$ sudo find /var/log -type f -mtime +30 -deleteパッケージキャッシュ
APT や snap のキャッシュも無制限に溜まると容量を圧迫します。
$ sudo du -h --max-depth=1 /var/cache/apt
200M /var/cache/aptAPT キャッシュのクリア
$ sudo apt-get cleansnap 古いリビジョンの削除
$ sudo snap list --all | awk '/disabled/{print $1, $3}' | \
while read snap revision; do
sudo snap remove "$snap" --revision="$revision"
doneDocker イメージ／コンテナ
Docker を使っていると未使用イメージやボリュームが残ることがあります。
$ docker system df
TYPE TOTAL ACTIVE SIZE
Images 15 3 2.3GBクリーンアップ
$ docker system prune -a --volumes
Deleted volumes... reclaimed 1.5GBMySQL のバイナリログ
バイナリログはデフォルトで無期限に保存されます。
$ sudo find /var/lib/mysql -maxdepth 1 -type f -size +100M -exec ls -lh {} \; | awk '{print $5, $9}'
1.8G /var/lib/mysql/binlog.0004907 日より古いログを削除
mysql> PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);
Query OK, 20 rows affected全ログ削除（リセット）
mysql> RESET MASTER;
Query OK, 0 rows affected自動削除設定 (/etc/mysql/my.cnf に追記)
[mysqld]
expire_logs_days = 7InnoDB 共通テーブルスペース
ibdata1 はテーブル削除後も縮小されないため、肥大化しやすい点に注意します。
$ ls -lh /var/lib/mysql/ibdata1
-rw-rw---- 1 mysql mysql 3.5G Jul 1 10:00 ibdata1テーブル再構築例
mysql> ALTER TABLE users ENGINE=InnoDB;
Query OK, 10 rows affected縮小手順
- MySQL を停止
- innodb_file_per_table = 1 を設定
- 各テーブルを再構築
- 古い ibdata1 / ib_logfile* を削除
実運用環境では必ずバックアップを取得してから実行してください
No space left on device対策の自動化と運用上の注意点
一度手動で削除しても、定期的に自動化しなければ再び容量不足になります。ここでは cron と systemd timer の例を示します。
cron で毎週実行（ジャーナル削減）
0 3 0 root journalctl --vacuum-time=2weekssystemd timer で Snap 自動削除
/etc/systemd/system/snap-cleanup.service
[Unit]
Description=Snap cleanup
[Service]
Type=oneshot
ExecStart=/usr/bin/bash -lc "\
snap list --all | awk '/disabled/{print $1, $3}' | \
while read snap revision; do \
snap remove $snap --revision=$revision; \
done"
/etc/systemd/system/snap-cleanup.timer
[Unit]
Description=Run snap cleanup weekly
[Timer]
OnCalendar=weekly
Persistent=true
$ sudo systemctl enable --now snap-cleanup.timerNo space left on deviceの解消と対策のまとめ
本記事では、まずdf -h やdf -iを用いてディスク容量と inode の使用状況を把握し、次に du コマンドと find コマンドを組み合わせて、どのディレクトリやファイルが容量を圧迫しているかを段階的に特定する手順を紹介しました。その上で、ログファイルのジャーナル削減、パッケージキャッシュのクリア、Docker リソースのクリーンアップ、MySQL のバイナリログ管理、InnoDB のテーブルスペース縮小といった典型的な原因ごとの具体的な対策方法を実行例とともに解説。また、cron や systemd timer、MySQL 設定の自動化を通じて、同様のトラブルが再発しないようにするポイントにも触れました。
これらの手順を継続的に運用することで、単発のトラブルシューティングにとどまらず、日々のサーバ運用におけるディスク管理の習慣を確立でき、No space left on deviceエラーを未然に防ぐことが可能です。継続的なモニタリングと自動化が安定したシステム運用の鍵となります。
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に