/etc/fstab の設定ミスで起動できない『サーバOSの話④』
Linuxサーバ運用で“最も危険な設定ファイル”の一つが /etc/fstab。
ここにたった1行ミスがあるだけで、
OSが起動途中で止まる（emergency mode / rescue mode） という
非常に重大なトラブルになる。
fstab は自動マウントの要。
誤記・タイプミス・権限不足など、どんな小さなミスも起動不可につながる。
ひと言まとめ
fstab は“起動時に絶対に失敗できない”領域。
1行のミスが、本番サーバの停止へ直結する。
症状（あるある）
OS起動が emergency mode で止まる
/dev/xxx not found、mount: wrong fs type の表示
rootパスワード入力を求められ復旧モードに落ちる
仮想環境だと起動ログが高速に流れ原因が見えにくい
/home や /var がマウントされずアプリが起動不能
NFSマウント失敗で起動がフリーズ
原因と仕組み（なぜ起きる？）
デバイス名（/dev/sdX）の タイポ
UUID コピーミス
ファイルシステムタイプ（xfs/ext4/nfs）の不一致
NFS の mount オプション記述が間違い
存在しないディレクトリをマウントポイントに指定
fstab編集後に一度も mount -a でテストしていない
AWS/EBS のように“起動時にまだデバイスが揃わない”パターン
図：fstab ミスで起動シーケンスが止まる
[OS起動]
↓
[fstab の自動マウント]
↓（失敗）
[emergency mode] → 手動で修正しないと進めない
切り分け（最短コース）
起動ログの確認
emergency mode でログを見る：journalctl -xb
fstabの対象行をコメントアウト
emergency mode で：mount -o remount,rw / vi /etc/fstab
再起動テスト
reboot
正常起動後、対象デバイスの存在確認
lsblk blkid
ファイルシステム整合性チェック
fsck /dev/xxx
今すぐ効く対処（テンプレ）
emergencyモードで /etc/fstab を直し、
まず起動を優先して最小の構成に戻すUUID確認
blkid
編集後は 必ず以下で検証してから reboot
mount -a
NFSの場合、noauto や _netdev オプションを追加し
“ネットワーク起動後にマウント” へ変更
恒久対策／再発防止チェックリスト
fstab編集後は 必ず mount -a で事前検証
UUID をコピペする際は改行や空白混入に注意
NFSは _netdev を付与しネットワーク依存を明確化
存在しないディレクトリをマウントポイントにしない
fstabのバックアップを常に保存
docker/k8s環境ではホスト側fstabを慎重に扱う
AWS/EBSなど“遅延認識”が起きる環境は systemd-mount を利用
ファイルシステム変更時は fstab も忘れずに更新
落とし穴（やりがちミス）
/dev/sdb1 と /dev/sdc1 を間違える
UUID の前後に見えない空白が混入
ext4 のつもりで xfs のまま書き換え忘れ
mountポイントを作成していない
noauto を付け忘れ、NFSが起動時に固まる
編集後に mount -a をせず、そのまま再起動（危険）
変更後の確認ポイント
OSが emergency mode にならず正常起動
fstab の対象行が正しくマウントされている
df -h
NFS/外部ストレージが安定稼働
systemd 起動ログにエラーなし
バックアップされた fstab が保存済
まとめ（行動指針）
fstabは“サーバの生命線”。
一文字のミスが、OS を起動不能にしてしまう。
編集 → mount -a で検証 → 再起動実施。
この3ステップを習慣化するだけで、
fstab 起因のトラブルはほぼ消える。
