dfでどのパーティションが満杯かを確認する
最初に、どのファイルシステムが満杯なのかを特定します。df はマウントされているファイルシステムごとの使用量を表示するコマンドです。
df -hUse% が100%に近い行を探し、Mounted on 列を確認します。対処はこの列の値で分かれます。/ または /home なら次の節に進みます。/boot だけが満杯なら「/bootが満杯のとき」の節に進みます。
dfでは空きがあるのにエラーが出る場合は、容量以外が原因です。この場合は「inodeの枯渇」と「Btrfsのスナップショット」の節を確認します。
ext4では、容量の約5%がroot用に予約されています。このため一般ユーザーの操作は、Use%が100%になる少し前から失敗することがあります。
du・ncduで容量を使っている場所を特定する
du は、ディレクトリごとのディスク使用量を集計するコマンドです。-x を付けると、ほかのファイルシステムの中までは数えません。
sudo du -xh --max-depth=1 / 2>/dev/null | sort -h大きいディレクトリが一番下に並びます。そのディレクトリを引数にして、同じコマンドを繰り返します。これで容量を使っている場所まで絞り込めます。
ncdu を使うと、同じ作業を対話的に進められます。ほとんどのディストリビューションでは ncdu というパッケージ名でインストールできます。sudo ncdu -x / を実行し、矢印キーでディレクトリを移動します。d キーでその場で削除もできますが、何のファイルかを確かめてから使ってください。
見つかった場所は、たいてい以下の節のどれかに当てはまります。/var/cache ならパッケージキャッシュ、/var/log/journal ならjournalログを見ます。/var/lib/flatpak や /var/lib/snapd ならFlatpakやSnapの節に進みます。~/.local/share/Trash ならゴミ箱です。duの合計がdfの使用量よりも大幅に少ない場合は、「削除済みでも開かれたままのファイル」の節に進みます。
パッケージキャッシュを削除する
パッケージマネージャーは、ダウンロードしたパッケージをキャッシュとして残します。これは削除しても、システムの動作には影響しません。コマンドはディストリビューションによって異なります。
# Debian / Ubuntu系
sudo apt clean
sudo apt autoremove --purge
# Fedora / RHEL系
sudo dnf clean all
# Arch系(paccacheはpacman-contribパッケージに含まれる)
sudo paccache -rk2apt autoremove は、依存関係として入っていて、今は不要になったパッケージを削除します。削除対象の一覧が表示されるので、必要なものが含まれていないか確認してから進めます。
journalログのサイズを制限する
systemdを使うディストリビューションでは、ログはjournalという仕組みで保存されます。現在の使用量は次のコマンドで確認できます。
journalctl --disk-usage
sudo journalctl --vacuum-size=200M2行目は、古いログを削除して合計を200MB以下にします。上限を恒久的に設定するには、/etc/systemd/journald.conf に SystemMaxUse=200M と書き、sudo systemctl restart systemd-journald を実行します。
ログが短期間で数GBに増えた場合は、何かのサービスがエラーを出し続けている可能性があります。journalctl -b -p err で、今回の起動以降のエラーを確認してください。原因を直さない限り、ログは再び増えます。
FlatpakとSnapの古いランタイムを整理する
Flatpakでは、アプリを削除したあともランタイム(アプリの実行に必要な共通部品)が残ることがあります。flatpak uninstall --unused を実行すると、どのアプリにも使われていないランタイムを削除できます。
Snapは、更新前の古いリビジョン(版)を標準で保持します。snap list --all を実行し、「disabled」と表示されている行が古いリビジョンです。sudo snap remove パッケージ名 --revision=番号 で個別に削除できます。保持する数は sudo snap set system refresh.retain=2 で減らせます。2が最小値です。
ゴミ箱を空にする
デスクトップ環境のファイルマネージャーで削除したファイルは、ゴミ箱に移動しているだけです。実体は ~/.local/share/Trash に残っています。ファイルマネージャーからゴミ箱を空にするか、gio trash --empty を実行します。外付けドライブ上で削除したファイルは、そのドライブ内の .Trash-1000 のようなディレクトリに入ります。
Timeshift・Btrfsスナップショットを確認する
Timeshiftやsnapperでスナップショットを取っていると、古いファイルを削除しても容量は空きません。スナップショットがそのファイルを参照し続けるためです。
sudo timeshift --list
sudo timeshift --delete --snapshot 'スナップショット名'
# snapperの場合(openSUSEなど)
sudo snapper list
sudo snapper delete 番号ファイルシステムがBtrfsの場合、dfの数値は実態とずれることがあります。正確な使用量は sudo btrfs filesystem usage / で確認します。スナップショットを削除しても、空き容量への反映には少し時間がかかることがあります。
削除済みでも開かれたままのファイルを探す
プロセスがファイルを開いたままだと、そのファイルを削除しても容量は解放されません。巨大なログファイルを rm で消した直後によく起こります。duの合計とdfの使用量が大きく食い違う場合は、これが原因である可能性が高いです。
sudo lsof +L1表示された COMMAND 列のプロセスを再起動すると、容量が解放されます。サービスであれば sudo systemctl restart サービス名 を使います。どのサービスか分からない場合は、再起動(リブート)でも解放されます。今後ログを空にするときは、削除ではなく sudo truncate -s 0 ファイル名 で中身だけを消すと、この問題は起きません。
inodeの枯渇を確認する
inodeは、ファイル1つごとに使われる管理領域です。小さなファイルが大量にあると、容量に空きがあってもinodeが尽きます。この場合も「No space left on device」と表示されます。
df -i
sudo du --inodes -x / 2>/dev/null | sort -n | tail -20IUse% が100%なら、2行目でファイル数の多いディレクトリを探します。キャッシュ、セッションファイル、メールキューなどが典型例です。ext4ではinodeの総数が作成時に決まり、あとから増やせません。そのため、不要なファイルを減らすことが対処になります。
/bootが満杯のとき
/bootを独立したパーティションにしている環境では、古いカーネルがたまって満杯になることがあります。満杯のままだと、カーネルの更新が途中で失敗します。まず uname -r で使用中のカーネルを確認します。
Debian・Ubuntu系では、sudo apt autoremove --purge で古いカーネルが削除されます。依存関係のエラーで止まる場合は、dpkg --list 'linux-image*' で一覧を出します。そのうえで、使用中以外の古いカーネルを1つ sudo apt purge で削除してから再実行します。Fedora系では、/etc/dnf/dnf.conf の installonly_limit で保持するカーネル数を設定できます。どのディストリビューションでも、/boot内のファイルを手で削除するのはやめてください。起動できなくなる原因になります。
ここまでで解決しなかった場合
次はduの結果をもう一度見直し、上の節に当てはまらない大きなディレクトリを調べます。よくあるのは次の3つです。
- Dockerのイメージやコンテナ。
docker system dfで使用量を確認し、docker system pruneで整理する。 - 仮想マシンのディスクイメージ。
/var/log内の、journal以外のテキストログ。
削除できるものがない場合は、データを別ディスクへ移すか、パーティションを拡張します。パーティションの拡張は失敗するとデータを失うおそれがあるので、先にバックアップを取ってください。