LinuxサーバーやPCを運用していると、突然「No space left on device」というエラーメッセージが表示され、ファイルの保存やシステムの更新ができなくなることがあります。
重要なサービスが停止してしまうのではないかと、焦りを感じる瞬間です。
ディスク容量が不足する原因は、ログファイルの肥大化やキャッシュの蓄積、あるいはiノードの枯渇など多岐にわたります。
この記事では、Linuxの容量不足に直面した際の現状確認から、不要ファイルの安全な削除方法、ディスクの拡張手順、さらにはWSL特有の問題までを網羅的に解説します。
正しい対処法を知ることで、システムを安定稼働させ、将来的なトラブルを未然に防ぐことができるようになります。
Linuxで「容量不足」のエラーが出た時に最初にやるべき確認手順
容量不足のエラーが発生した際、闇雲にファイルを削除するのは危険です。
まずはシステム全体の状況を正確に把握し、どのパーティションやディレクトリが圧迫されているのかを特定する必要があります。
ここでは、現状を診断するための基本的なコマンドと手順を紹介します。
dfコマンド（df -h）でディスク全体の空き容量と使用率を調べる
最初に実行すべきコマンドは、ファイルシステムのディスク容量を表示する「df」コマンドです。
ターミナルで「df -h」と入力して実行してください。
オプションの「-h」をつけることで、サイズがKB、MB、GBといった人間が読みやすい単位で表示されます。
出力結果の中で特に注目すべき項目は「Mounted on（マウント位置）」と「Use%（使用率）」です。
「Use%」が100%に近い、あるいは100%になっている行を探してください。
その行の「Mounted on」が「/（ルート）」なのか、「/boot」なのか、あるいは個別にマウントしたデータ領域なのかを確認することで、問題の範囲を特定できます。
もしルートパーティションが満杯であれば、システム全体の動作に影響が出ている可能性が高いため、早急な対処が必要です。
duコマンド（du -sh *）で容量を圧迫しているディレクトリを特定する
dfコマンドで容量不足のパーティションが判明したら、次は具体的にどのディレクトリが容量を消費しているか調査します。
この時に使用するのが「du」コマンドです。
対象のパーティションのトップディレクトリ（例えばルート「/」など）に移動し、「du -sh *」を実行してください。
このコマンドは、現在のディレクトリ直下にあるファイルやフォルダの容量を個別に計算し、合計サイズを表示してくれます。
表示された結果の中で、異常にサイズが大きいディレクトリを見つけたら、cdコマンドでそのディレクトリの中に入り、再度「du -sh *」を実行します。
これを繰り返すことで、最終的に巨大な容量を占有している犯人のファイルやディレクトリを特定することができます。
ルートパーティション（/）とホーム（/home）のどちらが不足しているか見分ける
Linuxのパーティション構成によっては、システム領域である「/（ルート）」と、ユーザーデータ領域である「/home」が分かれている場合があります。
dfコマンドの結果を見た際に、どちらが不足しているかを見極めることが重要です。
「/home」が不足している場合は、ユーザーが保存したドキュメントやダウンロードファイル、個人の設定ファイルなどが原因であることが大半です。
この場合、個人のファイルを整理すれば解決するため、システムへの致命的な影響は少ないと言えます。
一方で「/」が不足している場合は、ログファイル、アプリケーションのキャッシュ、インストールされたプログラム、あるいはカーネルファイルなどが原因の可能性があります。
システム領域の不足はOSの動作不安定に直結するため、慎重かつ迅速な原因特定と対処が求められます。
容量不足の主な原因と削除しても安全なファイル（/var/log・キャッシュ）
原因となるファイルが特定できたら、次はそのファイルを削除して空き容量を確保します。
しかし、システムに必要なファイルを誤って削除すると、OSが起動しなくなるリスクがあります。
ここでは、一般的に削除しても安全とされるファイルや、その適切な処理方法について解説します。
/var/log配下の巨大化したログファイルは削除して大丈夫？
Linuxシステムにおいて、容量圧迫の最も一般的な原因の一つが「/var/log」ディレクトリ配下のログファイルです。
システムやアプリケーションの稼働ログが蓄積され続け、数GBから数十GBに膨れ上がることがあります。
ログファイル自体は削除しても、多くの場合はシステムによって自動的に再生成されますが、稼働中のプロセスがファイルを掴んでいる場合、単純に削除（rmコマンド）してもディスク容量が解放されないことがあります。
また、トラブルシューティングのために過去のログが必要になるケースもあります。
安全な方法としては、ファイルの中身だけを空にするコマンドを使用するのがおすすめです。
例えば、「echo “” > /var/log/logfile.log」のようにリダイレクトを使って中身を空にすれば、ファイル自体の存在とiノードを維持したまま容量を減らすことができます。
あるいは、古いログファイルをgzipなどで圧縮して保存しておくか、別のストレージへ退避させてから削除するのが賢明です。
パッケージ管理システム（yum/dnf/apt）のキャッシュを削除する方法
アプリケーションのインストールやアップデートに使用されるパッケージ管理システムも、キャッシュファイルを溜め込みやすい場所です。
Red Hat系（CentOSなど）で使用されるyumやdnf、Debian系（Ubuntuなど）で使用されるaptは、ダウンロードしたパッケージファイルをキャッシュとして保持しています。
これらは、再度同じパッケージをインストールする際の高速化には役立ちますが、容量が不足している緊急時には削除しても問題ありません。
yumやdnfの場合は「yum clean all」または「dnf clean all」、aptの場合は「apt-get clean」というコマンドを実行することで、キャッシュされているパッケージファイルを一括で削除できます。
これだけで数百MBから数GBの空き容量が確保できることも珍しくありません。
/rootや/tmpに溜まりがちな一時ファイルと古いカーネルの整理
管理者ユーザーのホームディレクトリである「/root」や、一時ファイルを保管する「/tmp」も確認すべきポイントです。
「/root」には、管理者が作業用にダウンロードしたアーカイブファイルや、バックアップファイルが放置されていることがよくあります。
これらは作業が終わっていれば不要ですので、確認の上で削除してください。
「/tmp」は、システムやアプリが一時的に使用するファイルが置かれますが、再起動すればクリアされる設定になっていることが多いです。
しかし、長期間稼働し続けているサーバーではゴミファイルが溜まっていることがあるため、中身を確認して古いものは削除を検討します。
また、カーネルのアップデートを繰り返していると、古いバージョンのカーネルが残存し、ブート領域やルートパーティションを圧迫します。
不要になった古いカーネルは、ディストリビューションごとの推奨手順に従って削除することで、容量を節約できます。
削除だけでは足りない場合にディスク容量を増やす・拡張する方法
不要なファイルを削除しても十分な空き容量が確保できない、あるいは慢性的に容量不足が続く場合は、ディスク容量そのものを増やす必要があります。
仮想環境やクラウド環境であれば、物理的なHDDを追加せずとも設定変更で対応できる場合が多いです。
ここでは、ディスク容量を拡張する一般的な手順を解説します。
LVM（論理ボリュームマネージャ）を使用してパーティションを拡張する手順
LVM（Logical Volume Manager）を使用してディスクを管理している場合、比較的柔軟に容量を拡張することができます。
手順の概要としては、まず新しい物理ディスクを追加するか、既存の仮想ディスクサイズを拡張します。
次に、その領域を「物理ボリューム（PV）」として認識させ、「ボリュームグループ（VG）」に追加してグループ全体の容量を増やします。
最後に、「論理ボリューム（LV）」を拡張し、ファイルシステムをリサイズするという流れになります。
コマンドとしては、pvcreate、vgextend、lvextendなどが使用されます。
LVMを使用することで、複数のディスクを一つの大きな論理ディスクとして扱えるため、将来的な容量増加にも柔軟に対応できます。
VMwareやVirtualBoxなど仮想環境でディスクサイズを割り当て直す
VMwareやVirtualBoxなどの仮想化ソフトウェア上でLinuxを動かしている場合、ハイパーバイザー側の設定で仮想ディスクのサイズを変更できます。
仮想マシンを一旦停止し、設定画面からハードディスクの容量を、例えば20GBから40GBといった具合に増やします。
ただし、これだけではLinux側で認識されるハードディスクの器が大きくなっただけで、ファイルシステムが使える領域は増えていません。
Linuxを起動した後、fdiskやpartedコマンドを使ってパーティションテーブルを操作し、増えた領域を既存のパーティションに結合するか、新しいパーティションとして作成する作業が必要です。
ファイルシステムの拡張コマンド（xfs_growfs / resize2fs）の使い方
パーティションや論理ボリュームのサイズを広げた後、最後にファイルシステム自体をそのサイズに合わせて拡張する必要があります。
この手順を忘れると、dfコマンドで見た時の容量は変わりません。
使用するコマンドは、フォーマットされているファイルシステムの種類によって異なります。
CentOS 7以降などで標準採用されている「XFS」の場合は、「xfs_growfs」コマンドを使用します。
一方、Ubuntuなどで多く使われる「ext4」の場合は、「resize2fs」コマンドを使用します。
自分の環境がどちらのファイルシステムを使っているかは、「df -T」コマンドを実行することで確認できます。
適切なコマンドを実行することで、OS上から拡張した全ての容量が利用可能になります。
「空き容量があるのに容量不足になる」原因とトラブルシューティング
dfコマンドで見るとディスク容量には十分な空きがあるのに、ファイルの作成や保存ができないという不思議な現象に遭遇することがあります。
これは単なる容量不足とは異なる原因で発生しているエラーです。
ここでは、そのような特殊なケースの原因と解決策について解説します。
iノード（inode）の枯渇をチェックする方法（df -i）
Linuxのファイルシステムでは、データの本体とは別に、ファイルの属性情報などを管理する「iノード（inode）」という領域があります。
iノードの数はファイルシステム作成時に決まっており、たとえデータ容量に空きがあっても、iノードを使い切ってしまうと新しいファイルを作成できなくなります。
これは、数KB程度の極めて小さなファイルを大量に生成するようなアプリケーションや、メールサーバーなどでよく発生します。
確認するには「df -i」コマンドを使用してください。
もしIUse%が100%になっている場合、不要なファイルを大量に削除してiノードを解放する必要があります。
プロセスがファイルを掴んだまま削除されていないか確認する（lsof）
ログファイルなどを削除したはずなのに、dfコマンドの表示上で空き容量が増えないというケースがあります。
これは、削除したファイルを稼働中のプロセスがまだ読み書きしており、ディスク上から完全に解放されていないために起こります。
Linuxでは、プロセスがファイルを開いている限り、見かけ上削除されていてもデータの実体は残ります。
このような「削除されたが掴まれているファイル」を確認するには、「lsof | grep deleted」コマンドを使用します。
該当するプロセスを特定し、そのサービスを再起動（systemctl restartなど）するか、プロセスを終了させることで、ファイルへのハンドルが外れ、正式に容量が解放されます。
マウントポイントの裏側にファイルが隠れていないか確認する
非常に稀なケースですが、あるディレクトリに別のディスクをマウントしている場合、そのマウントポイントとなるディレクトリ自体にファイルが存在していても、マウント中は見えなくなります。
例えば、/mnt/data というディレクトリにデータを入れていた状態で、後からそこに新しいHDDをマウントすると、元のデータは見えなくなり、容量だけを消費している状態になります。
これを疑う場合は、一度マウントを解除（umount）してから、そのディレクトリの中身を確認する必要があります。
意図せず保存されていた巨大なファイルが隠れていることがあり、それを削除することで容量不足が解消します。
WSL（Windows Subsystem for Linux）特有の容量問題と解決策
Windows上でLinux環境を利用できるWSL（Windows Subsystem for Linux）では、通常のLinuxとは異なるディスク管理の仕組みがあります。
そのため、WSL特有の容量問題が発生することがあり、解決には独自の手順が必要です。
ここでは、WSLユーザーが直面しやすい問題とその解決策を解説します。
WSLでファイルを削除してもホスト（Windows）の容量が戻らない理由
WSL2では、Linuxのファイルシステムとして「ext4.vhdx」という仮想ハードディスクファイルが使用されています。
この仮想ディスクは、Linux側でデータが増えると自動的に拡張され、Windows側のディスク容量を消費します。
しかし、Linux側（WSL内）でファイルを大量に削除しても、このvhdxファイルのサイズは自動的には縮小されません。
つまり、Linux上では「空き容量が増えた」と認識されていても、Windows側から見ると「巨大なファイル」として残ったままになり、WindowsのCドライブなどを圧迫し続けることになります。
diskpartとoptimize-vhdを使って仮想ディスク（ext4.vhdx）を圧縮する方法
肥大化したvhdxファイルを圧縮し、Windows側の空き容量を取り戻すには、Windows側での操作が必要です。
まず、WSLを完全にシャットダウンするために、PowerShellで「wsl –shutdown」を実行します。
次に、diskpartコマンドを使用し、対象のvhdxファイルを選択して「compact vdisk」を実行するか、あるいはPowerShellの「Optimize-VHD」コマンドレットを使用します。
「Optimize-VHD -Path “対象のvhdxファイルのパス” -Mode Full」といったコマンドを実行することで、仮想ディスク内の未使用領域が整理され、物理的なファイルサイズが縮小されます。
これにより、Windows側のディスク容量を解放することができます。
WSLのディスク使用量を自動で最適化するスクリプト活用法
手動での圧縮作業は手間がかかるため、頻繁にファイルの増減がある場合はスクリプトを活用して自動化するのも一つの手です。
WSLのシャットダウンからvhdxファイルの検索、そしてOptimize-VHDの実行までを一連の流れとして記述したPowerShellスクリプトを作成しておきます。
このスクリプトをタスクスケジューラなどで定期的に実行するように設定しておけば、意識せずにディスク容量を最適化された状態に保つことができます。
特に開発環境などで大量のファイル生成と削除を繰り返すユーザーにとっては、非常に有効な運用方法となります。
再び容量不足にならないための予防と運用ルール
容量不足を解消できたとしても、根本的な対策を講じなければ、いずれまた同じ問題が発生します。
継続的に安定した運用を行うためには、ログの管理や定期的な掃除の仕組みを導入することが重要です。
ここでは、再発防止のための基本的な運用設定を紹介します。
logrotate（ログローテーション）の設定を見直して肥大化を防ぐ
ログファイルの際限ない肥大化を防ぐために、Linuxには「logrotate」という仕組みが標準で備わっています。
これは、指定した期間やサイズごとにログファイルを新しいものに切り替え、古いログを圧縮したり、一定期間経過後に削除したりする機能です。
「/etc/logrotate.conf」や「/etc/logrotate.d/」配下の設定ファイルを確認し、ローテーションの設定が適切に行われているか見直しましょう。
特に独自に導入したアプリケーションのログなどは、デフォルトではローテーション設定がされていないことがあるため、手動で設定を追加する必要があります。
cronを使った定期的な不要ファイル削除とディスク監視の自動化
一時ファイルやキャッシュなど、定期的に削除しても問題ないファイルについては、「cron」を使って削除処理を自動化することをおすすめします。
例えば、特定のディレクトリ内の30日以上経過したファイルを検索して削除するコマンドを、毎日深夜に実行するように設定します。
また、dfコマンドの結果を監視し、ディスク使用率が80%や90%を超えた場合に、管理者にメールで通知を送る簡単なスクリプトを組んでおくことも有効です。
これにより、完全に容量が枯渇してシステムが停止する前に、余裕を持って対応できるようになります。
まとめ：Linux 容量不足解消の要点
- 容量不足時はまずdfコマンドで使用率を、duコマンドで詳細な場所を特定する
- システム領域の「/」とユーザー領域の「/home」のどちらが不足しているか見極める
- /var/logなどのログファイルは中身を空にするか圧縮して退避させるのが安全である
- yumやaptなどのパッケージ管理システムのキャッシュ削除は効果的な空き容量確保手段である
- 削除だけでは解決しない場合、LVMや仮想環境の設定でディスク自体の拡張を検討する
- ファイルシステム拡張時はxfs_growfsやresize2fsなど環境に合ったコマンドを使用する
- dfで空きがあるのにエラーが出る場合はiノード枯渇やプロセスによる掴みを疑う
- WSL2ではファイル削除後にWindows側で仮想ディスクの圧縮操作が必要になる
- logrotateの設定を適切に行い、ログファイルの自動整理を仕組み化する
- 定期的な監視と不要ファイル削除を自動化し、トラブルを未然に防ぐ運用を心がける