Linuxのディレクトリ構造を理解する
連載ナビ
この連載は「Linuxを使えるようになる」ではなく、「Linuxがどう動いているのか」を理解するための実践シリーズです。
今回は Linuxを理解する 〜 LFSで学ぶLinux内部構造 〜 の Part 2 / 第1回として、仕組みのつながりを意識しながら学びます。
- 前回: Linux学習用おすすめ環境
- 次回: /procとは何か
—
ディレクトリの配置は「FHS」という標準で決まっている
cd で移動するたびに現れる /bin、/etc、/usr、/var。これらは各ディストリビューションが気まぐれに作ったものではありません。
結論から言うと、Linuxの主要なディレクトリ構成はFHS（Filesystem Hierarchy Standard）という標準で「どこに・何を・置くべきか」が定義されており、UbuntuでもAlpineでもRed Hat系でもほぼ共通です。つまり、この見取り図を一度覚えれば、初めて触るサーバーでもDockerコンテナの中でも、「設定はここ、ログはここ、実行ファイルはここ」と予測できるようになります。
/
├── /bin, /sbin 実行ファイル（基本コマンド / 管理コマンド）
├── /etc システム全体の設定ファイル
├── /usr ユーザー空間のプログラム本体の大半
├── /home 一般ユーザーの個人ファイル
├── /var ログ・キャッシュなど変動するデータ
├── /tmp 一時ファイル
├── /proc, /sys カーネル情報を見せる仮想ファイルシステム
└── /boot カーネル本体とブートローダ関連
「場所の約束」がないと、ソフトウェアが動けないから
なぜここまで厳密に場所を決める必要があるのでしょうか。理由は、Linuxのソフトウェアは「ファイルが標準の場所にある」という前提で作られているからです。
- シェルはコマンドを
PATH環境変数（通常/usr/local/bin:/usr/bin:/binなど）の順に探します。実行ファイルが規定の場所になければcommand not foundになります。 - プログラムは起動時に共有ライブラリを
/libや/usr/libから、設定を/etcから読みます。パスはソースコードやビルド設定に埋め込まれています。 aptやdnfのようなパッケージマネージャは、FHSに従ってファイルを配置します。dpkg -L nginxを実行すると、1つのパッケージが/usr/sbin、/etc、/var/logに分散して配置される様子がそのまま見えます。
もう1つの理由は歴史的な運用要件です。かつて /usr は別ディスクにマウントされることがあったため、マウント前でも起動・修復に使える最小限のコマンドを /bin と /sbin に置くという区別が生まれました。現代のUbuntuなどでは「usrマージ」により /bin は /usr/bin へのシンボリックリンクになっていますが（ls -l /bin で bin -> usr/bin と確認できます）、この歴史を知っていると /bin と /usr/bin に同じコマンドが見える理由が分かります。
主要ディレクトリを、実在のファイルで押さえる
抽象的な説明よりも、実際に入っているファイルで覚えるのが確実です。
/etc— システム全体の設定
/etc/passwd（ユーザー一覧）、/etc/fstab（起動時にマウントするディスク）、/etc/hosts（名前解決の静的定義）、/etc/ssh/sshd_config（SSHサーバー設定）。原則としてテキストファイルなので、cat と grep だけで調査できます。
/usr— プログラム本体の大半
/usr/bin（python3 や git などほとんどのコマンド）、/usr/sbin（sshd などサービス・管理系）、/usr/lib（共有ライブラリ。libc.so.6 など）、/usr/share（マニュアルやロケールなどアーキテクチャ非依存のデータ）。ちなみに自分でビルドしたソフトは /usr/local 配下に置くのが慣例で、パッケージ管理下のファイルと衝突しないようになっています。
/var— 運用中に増減するデータ
/var/log（syslog や auth.log などのログ。障害時に最初に見る場所）、/var/cache（apt のダウンロードキャッシュなど）、/var/spool（メールやcronジョブの待ち行列）、/var/lib（データベースの実データなど、アプリが持つ状態）。
/homeと/root
一般ユーザーの領域は /home/ユーザー名、管理者rootだけは /root です。rootのホームが /home の外にあるのは、/home が別ディスクでマウントに失敗しても管理者が作業できるようにするためです。
/procと/sys— ディスク上に実体のない仮想ファイルシステム
カーネルが自身の状態（メモリ使用量、CPU情報、プロセス一覧）をファイルの形で見せてくれる特別な場所です。次回の主役なので、ここでは「実体がない」ことだけ覚えてください。
nginxを例に、「どこを見るか」を動線にする
この構造が頭に入ると、トラブル調査の動線が定型化できます。たとえばUbuntuに apt install nginx でインストールした場合、関連ファイルはFHSに従って次のように配置されます。
/usr/sbin/nginx 実行ファイル本体
/etc/nginx/nginx.conf メイン設定ファイル
/etc/nginx/sites-enabled/ サイトごとの設定
/var/log/nginx/access.log アクセスログ
/var/log/nginx/error.log エラーログ
/var/www/html/ 既定の公開ディレクトリ
「nginxの挙動がおかしい」と思ったら、設定は /etc/nginx、原因の手がかりは /var/log/nginx/error.log、本体の場所を知りたければ which nginx または command -v nginx。この動線は、対象がPostgreSQLでもsshdでも基本的に同じです。FHSを知っているとは、未知のソフトウェアでもファイルの置き場所を予測できるということです。
見取り図があれば、調べる「場所」から迷わなくなる
Linuxのディレクトリ構造はFHSという標準で決まっており、「実行ファイルは /usr/bin、設定は /etc、ログは /var/log」という役割分担はどのディストリビューションでもほぼ共通——これが今回の結論です。LFSでは、この構造を自分の手で mkdir して作ることになるため、「なぜこのディレクトリが必要か」を説明できることが後で効いてきます。
次回は、今回「実体がない」とだけ紹介した /proc を掘り下げます。カーネルの内部状態が、なぜ「ファイル」として見えるのかを確かめましょう。
この回で実行するコマンド
# ルート直下の構成を確認する（/bin -> usr/bin のリンクにも注目）
ls -la /
# /etc にある設定ファイルの例を確認する
ls -la /etc | head
# ログの置き場所を確認する
ls -la /var/log | head
# コマンドの実体がどこにあるか確認する
command -v ls
チェックポイント
- コマンドが最後まで実行できた
ls -la /の出力から、/etcや/homeなどの主要なディレクトリを見つけられる- 「実行ファイル・設定・ログ」がそれぞれどのディレクトリに置かれるかを言える
- 次の回に進む前に、FHS (Filesystem Hierarchy Standard) という単語を調べてみた
今回理解できたこと
- Linuxのディレクトリ構造には、FHSという標準化された設計があること
- 各ディレクトリが「実行ファイル」「設定」「可変データ」といった明確な役割を持っていること
- ソフトウェアやパッケージマネージャは、この「場所の約束」を前提に動いていること
- この構造を理解することで、未知のシステムでもどこに何があるか予測できるようになること