/etc/fstab による永続マウント
mount コマンドでの接続は再起動すると消えます。起動時に自動でマウントするには、設定ファイル /etc/fstab に1行追記します。各行は「デバイス（UUID推奨）・マウントポイント・ファイルシステム種別・オプション・dump・fsck順」の6項目で構成します。デバイス名は起動順で変わることがあるため、blkid で得た UUID で指定するのが安全です。記述ミスは起動失敗につながるので、mount -a で文法と実マウントを試験してから再起動します。
前のトピックで見た mount コマンドによる接続には、1つ大きな弱点がある。システムを再起動すると、接続がすべて失われてしまうことだ。
手作業で mount したファイルシステムは一時的なもので、再起動後にまた使いたければ、もう一度 mount し直さなければならない。サーバのデータ領域のように「起動したら常にこの場所に繋がっていてほしい」ファイルシステムを、毎回手で繋ぐのは現実的ではない。
そこで使うのが、起動時に自動でマウントするファイルシステムを定義しておく設定ファイル、/etc/fstab(file systems table)だ。ここに1行書いておけば、以後は再起動のたびにシステムが自動でそのファイルシステムをマウントしてくれる。
実際、ルートファイルシステム(/)やスワップ領域も、もとからこの /etc/fstab に書かれていて、起動時にここを読んでマウントされている。では、その1行には何を書くのか。
📋 fstab の1行は、何でできているのか
/etc/fstab は1行につき1つのファイルシステムを記述し、各行はスペースやタブで区切られた6つのフィールドからなる。左から順に意味を見ていこう。
第1フィールドはマウントするデバイスで、UUID=... の形で書くのが推奨だ。第2フィールドはマウントポイント(例：/data)で、ここで指定するディレクトリは事前に mkdir で作っておく必要がある。第3フィールドはファイルシステムの種別(ext4・xfs など)。
第4フィールドはマウントオプションで、標準的な設定をまとめた defaults をよく使う。第5フィールドは dump で、バックアップ対象かを示す古い項目で、通常は 0 を指定する。第6フィールドは fsck の順序(起動時のファイルシステム検査をどの順で行うか)で、ルート(/)なら 1、その他のデータ領域なら 2、検査不要なら 0 とする。
たとえば UUID=xxxx-xxxx /data ext4 defaults 0 2 のような1行になる。
各フィールドは1個以上の空白で区切られていればよく、見やすいように列を揃えて書く人が多いが、揃っていなくても動作には影響しない。# で始まる行はコメントとして無視されるので、何のための行かをメモしておくと後の保守が楽になる。
🎚 第4フィールドには、何を書き分けるのか
第4フィールドのマウントオプションは、前のトピックで見た mount -o に渡す値とまったく同じものだ。
defaults は rw(読み書き可)・suid・exec・auto・nouser・async といった標準的な設定をまとめた便利な指定で、ふつうのデータ領域はこれで足りる。
用途に応じて、読み取り専用にするなら ro、起動時に自動マウントしないなら noauto、一般ユーザにもマウントを許すなら user、性能を上げるなら noatime などを、defaults,noatime のようにカンマで足していく。
USBメモリのように常時は繋がっていないデバイスを書く場合、見つからなくても起動を止めないよう nofail を付けておくと安全だ。これを付けずに取り外し可能なデバイスを書くと、それが挿さっていないときに起動が止まってしまうことがある。
ところで、第1フィールドはなぜデバイス名でなく UUID なのか――ここに、地味だが大事な理由がある。
🆔 なぜ、デバイス名ではなく UUID なのか
第1フィールドのデバイス指定で、なぜ /dev/sda1 のようなデバイス名ではなく UUID を使うのか。はっきりした理由がある。
/dev/sda・/dev/sdb といった名前は、ディスクが認識される順番で割り当てられる。そのため、ディスクを増設したり、起動時の認識タイミングがずれたりすると、昨日まで /dev/sdb だったディスクが今日は /dev/sdc になる、といったことが起こり得る。
もし /etc/fstab にデバイス名で書いていると、この入れ替わりによって意図しないディスクがマウントされたり、目的のディスクが見つからず起動に失敗したりする。
一方、UUID はファイルシステムを作ったときに割り当てられる世界で一意な識別子で、ディスクの接続順が変わっても不変だ。だからこそ、UUID で名指しするのが安全なのだ。
書くべき UUID は、これまで使ってきた blkid コマンドで調べられる。blkid /dev/sda1 の出力にある UUID=... の値をそのまま転記する。
💣 たった1行のミスが、なぜ起動失敗を招くのか
/etc/fstab の編集は、ストレージ設定の中でもとくに慎重さが要る作業だ。
この設定は起動プロセスの早い段階で読み込まれる。ここに文法ミスや存在しないデバイス・誤ったオプションを書いてしまうと、最悪の場合システムが正常に起動できなくなり、復旧用のモード(緊急モード)に落ちてしまうことがある。
GUIの設定画面と違って即座のエラー表示がなく、再起動して初めて問題に気づく、という怖さがある。では、再起動という賭けに出る前に、どう安全を確かめればよいのか。
🛟 なぜ mount -a を挟むと安全になるのか
この事故を防ぐ決定的な作法が、編集後に必ず mount -a を実行して検証することだ。
mount -a は /etc/fstab に書かれた(まだマウントされていない)エントリを、いまその場でまとめてマウントしようと試みる。つまり、再起動を待たずに「この設定で本当にマウントできるか」を安全に試せる。
ここでエラーが出なければ文法とマウントは正しく、エラーが出れば再起動する前に修正できる。逆に言えば、mount -a を実行せずにいきなり再起動するのは、起動不能のリスクを抱えたまま賭けに出るようなものだ。
編集したら mount -a、これをセットで必ず行ってほしい。検証後は、lsblk や findmnt、df で、狙ったマウントポイントに正しく繋がり、想定どおりの容量が見えているかも確認しておくと万全だ。
実務では、本番サーバの /etc/fstab を編集する際、編集前に cp /etc/fstab /etc/fstab.bak のようにバックアップを取っておくと、問題が起きてもすぐ元に戻せて安心だ。