Web開発
2025.06.15

No space left on deviceの原因究明方法と安全な解決法


ディスク容量がいっぱいになり、ファイルが作成できなくなるNo space left on deviceエラーは、サーバ運用で頻出するトラブルです。

もしこれが本番サーバーであるなら早急に解決することが必要です。なぜなら、このエラーが出ている状態ではほとんどの処理を実行することができない状況に陥っており、サービス停止を意味するからです。

本記事では、原因の調査方法から不要ファイルの安全な削除、再発防止までのヒントを一気通貫で解説します。

石川瑞起
執筆者
秋霜堂株式会社 代表 石川瑞起
中学生でプログラミングを独学で習得し、HP制作やアプリ開発の事業を開始。 大学入学後に事業を売却し、トヨクモ株式会社へ入社。 3年間にわたり1製品の開発責任者を務めたのち秋霜堂株式会社を設立し、多数の企業をサポートしている。
毎日の
作業時間削減
人数
日数
=
たなる挑戦
あなたの会社にシステム開発部門をご提供。
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
月額10万円から
システム開発が可能に
\ 無料トライアル受付中! /

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/apt

APT キャッシュのクリア

$ sudo apt-get clean

snap 古いリビジョンの削除

$ sudo snap list --all | awk '/disabled/{print $1, $3}' | \ while read snap revision; do sudo snap remove "$snap" --revision="$revision" done

Docker イメージ/コンテナ

Docker を使っていると未使用イメージやボリュームが残ることがあります。

$ docker system df TYPE TOTAL ACTIVE SIZE Images 15 3 2.3GB

クリーンアップ

$ docker system prune -a --volumes Deleted volumes... reclaimed 1.5GB

MySQL のバイナリログ

バイナリログはデフォルトで無期限に保存されます。

$ sudo find /var/lib/mysql -maxdepth 1 -type f -size +100M -exec ls -lh {} \; | awk '{print $5, $9}' 1.8G /var/lib/mysql/binlog.000490

7 日より古いログを削除

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 = 7

InnoDB 共通テーブルスペース

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

縮小手順

  1. MySQL を停止
  2. innodb_file_per_table = 1 を設定
  3. 各テーブルを再構築
  4. 古い ibdata1 / ib_logfile* を削除

実運用環境では必ずバックアップを取得してから実行してください

No space left on device対策の自動化と運用上の注意点

一度手動で削除しても、定期的に自動化しなければ再び容量不足になります。ここでは cron と systemd timer の例を示します。

cron で毎週実行(ジャーナル削減)

0 3 0 root journalctl --vacuum-time=2weeks

systemd 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.timer

No space left on deviceの解消と対策のまとめ

本記事では、まずdf -hdf -iを用いてディスク容量と inode の使用状況を把握し、次に du コマンドと find コマンドを組み合わせて、どのディレクトリやファイルが容量を圧迫しているかを段階的に特定する手順を紹介しました。その上で、ログファイルのジャーナル削減、パッケージキャッシュのクリア、Docker リソースのクリーンアップ、MySQL のバイナリログ管理、InnoDB のテーブルスペース縮小といった典型的な原因ごとの具体的な対策方法を実行例とともに解説。また、cron や systemd timer、MySQL 設定の自動化を通じて、同様のトラブルが再発しないようにするポイントにも触れました。

これらの手順を継続的に運用することで、単発のトラブルシューティングにとどまらず、日々のサーバ運用におけるディスク管理の習慣を確立でき、No space left on deviceエラーを未然に防ぐことが可能です。継続的なモニタリングと自動化が安定したシステム運用の鍵となります。

毎日の
作業時間削減
人数
日数
=
たなる挑戦
あなたの会社にシステム開発部門をご提供。
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
月額10万円から
システム開発が可能に
\ 無料トライアル受付中! /
Ebook
お役立ち資料集

秋霜堂のサービス紹介資料や、
お役立ち資料を無料でダウンロードいただけます。


Contact
お問い合わせ

ご質問・ご相談など、まずはお気軽に
お問い合わせフォームより無料お問い合わせください。

お役立ち資料
お問い合わせ