/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 に書かれていて、起動時にここを読んでマウントされています。
fstab の6つのフィールド
/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フィールドのマウントオプションは、前のトピックで見た mount -o に渡す値とまったく同じものです。defaults は rw(読み書き可)・suid・exec・auto・nouser・async といった標準的な設定をまとめた便利な指定で、ふつうのデータ領域はこれで足ります。用途に応じて、読み取り専用にするなら ro、起動時に自動マウントしないなら noauto、一般ユーザにもマウントを許すなら user、性能を上げるなら noatime などを、defaults,noatime のようにカンマで足していきます。USBメモリのように常時は繋がっていないデバイスを書く場合、見つからなくても起動を止めないよう nofail を付けておくと安全です。これを付けずに取り外し可能なデバイスを書くと、それが挿さっていないときに起動が止まってしまうことがあります。
なぜ UUID で書くのか
第1フィールドのデバイス指定で、なぜ /dev/sda1 のようなデバイス名ではなく UUID を使うのかには、はっきりした理由があります。/dev/sda・/dev/sdb といった名前は、ディスクが認識される順番で割り当てられるため、ディスクを増設したり、起動時の認識タイミングがずれたりすると、昨日まで /dev/sdb だったディスクが今日は /dev/sdc になる、といったことが起こり得ます。もし /etc/fstab にデバイス名で書いていると、この入れ替わりによって意図しないディスクがマウントされたり、目的のディスクが見つからず起動に失敗したりします。一方、UUID はファイルシステムを作ったときに割り当てられる世界で一意な識別子で、ディスクの接続順が変わっても不変です。だからこそ、UUID で名指しするのが安全なのです。書くべき UUID は、これまで使ってきた blkid コマンドで調べられます。blkid /dev/sda1 の出力にある UUID="..." の値をそのまま転記します。
記述ミスは起動失敗につながる
/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 のようにバックアップを取っておくと、問題が起きてもすぐ元に戻せて安心です。