この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
SE時代の2003年頃の話だ。前日の夜遅く、社内の共有ファイルサーバーへのNFSマウントを /etc/fstab に追記して退社した。翌朝、出社してサーバールームに入ったら、コンソール画面が途中で止まり、Linuxが正常に起動していなかった。SSHでも入れない。Webサービスも止まっている。
あのときの「やってしまった」という感覚は、20年以上経った今でも鮮明だ。
この記事では、その失敗の一部始終と、20年以上Linuxサーバーを運用してきた経験から身につけた「fstab変更後に必ず行う確認習慣」を解説する。セミナーで3,100名以上を指導してきた中でも、fstab絡みのトラブルは受講生からよく聞かされる「やってしまった話」のひとつだ。
この記事のポイント
・nofailなしのNFSマウントをfstabに書くとサーバーが起動しなくなる
・再起動前に mount -a で事前確認する鉄則が起動事故を防ぐ
・_netdevとnofailオプションでネットワーク依存マウントを安全にする
・fstab変更前のバックアップは省略できない最低限の確認習慣
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜfstabのミスは「サーバーが起動しない」という最悪の結果を招くのか
Linuxが起動するとき、/etc/fstab に書かれたファイルシステムを順番にマウントする。この処理は起動の非常に早い段階で実行されるため、ネットワークが完全に立ち上がる前にNFSマウントを試みることがある。NFSマウントのようなネットワーク越しの共有を、起動順序の制御なしにfstabへ書いてしまうと、NFSサーバーへの接続が確立できないままLinuxは待ち続ける。あるいは長いタイムアウトの末にエラー扱いとなり、起動シーケンスそのものが止まる。
こうなると、SSHはもちろん入れない。コンソールに直接アクセスしなければ何もできない状態だ。私がSE時代に経験したのは、まさにこれだった。
SE時代に経験したfstabトラブルの実体験
1. 発端 — 社内共有サーバーのNFSディレクトリをfstabに書いた
あの日、私が行ったのは単純な作業だった。社内の別サーバーで管理している共有ディレクトリを、Webサーバーとして動くLinuxマシンから参照したい。そのためにNFSマウントの設定を /etc/fstab に追記した。書いた内容は、おおよそこういうものだった。
# /etc/fstab の末尾に追記 192.168.1.10:/shared /mnt/shared nfs defaults 0 0
# 手動マウントは問題なく動いた # mount /mnt/shared # ls /mnt/shared shared_data logs config
2. 翌朝 — 起動画面が途中で固まっていた
翌朝、サーバールームに入ると、コンソールに見慣れない光景が広がっていた。起動ログが途中で止まり、画面は固まっている。「Mounting network filesystems...」のような行が表示されたまま、カーソルが点滅するだけだ。
SSHで接続しようとしても繋がらない。pingも通らない。サーバーは半起動の状態で、ネットワークが立ち上がる前にNFSマウントを試みたまま、時間を無駄に過ごしていた。
受講生に「fstabを変えたらサーバーが起動しなくなった」と相談されるとき、私はいつもこの朝の光景を思い出す。多くの場合、原因はあの日の自分と同じだ。
3. 復旧作業 — シングルユーザーモードで格闘した
コンソールに物理アクセスできたことが、唯一の救いだった。GRUBの画面で起動を止め、カーネルパラメータに「single」を追加してシングルユーザーモードで起動した。ここで初めてrootシェルに入ることができた。
# GRUB画面でカーネル行の末尾に追加する # 例: ro quiet splash single # シングルユーザーモードで起動後、fstabを編集する # vi /etc/fstab # 追記したNFSの行をコメントアウトして無効化する # 変更前: 192.168.1.10:/shared /mnt/shared nfs defaults 0 0 # 変更後: #192.168.1.10:/shared /mnt/shared nfs defaults 0 0
fstab変更後に必ず行う3つの確認習慣
あの経験以来、20年以上ずっと守り続けている習慣がある。【注意】fstabはLinuxの起動に直結するファイルだ。1行の誤りでサーバーが起動不能になることを、常に意識して作業してほしい。
1. 変更前のバックアップを必ず取る
fstabを変更する前に、まず現在の状態を別ファイルにコピーする。「元に戻せる」という安心感があるだけで、作業ミスを防げる精神的な余裕が生まれる。# fstab変更前に必ずバックアップを取る（鉄則） # cp /etc/fstab /etc/fstab.bak.$(date +%Y%m%d) # バックアップが存在することを確認 # ls -la /etc/fstab* -rw-r--r-- 1 root root 742 Jul 26 08:00 /etc/fstab -rw-r--r-- 1 root root 742 Jul 26 08:00 /etc/fstab.bak.20260726
2. 変更後に mount -a で事前確認する
/etc/fstab を変更したら、再起動する前に必ずmount -a を実行する。これは「fstabに書かれたすべてのエントリを今すぐマウントする」コマンドだ。# fstab変更後、再起動前に必ず実行する（鉄則） # mount -a # エラーが出たら再起動前に必ず原因を特定して修正する # エラーが出なければ、現在の環境でマウントは成功している
私があの時これを実行していれば、NFSサーバーへの接続問題にその場で気づけた可能性があった。
3. NFSやネットワーク依存マウントにはnofailと_netdevを付ける
NFSなどネットワーク越しのマウントをfstabに書く場合は、_netdev と nofail の両方を必ず指定する。これを怠ると、NFSサーバーが落ちているだけで自サーバーが起動しなくなるという危険がある。# 問題のあった設定（nofailも_netdevもなし） -- 危険 192.168.1.10:/shared /mnt/shared nfs defaults 0 0 # 修正後の設定（_netdevとnofailを追加） 192.168.1.10:/shared /mnt/shared nfs defaults,_netdev,nofail 0 0
・_netdev：ネットワークが立ち上がってからマウントする（起動順序を制御する）
・nofail：マウントが失敗しても起動を止めずに続行する
_netdev があれば、ネットワーク起動前にNFSマウントを試みることがなくなる。nofail があれば、仮にNFSサーバーが停止していても自サーバーの起動が止まらなくなる。この2つを組み合わせることで、「NFSサーバーが一時的に落ちていても、自サーバーは正常に起動できる」という状態を維持できる。運用上、これは絶対に外せない設計方針だ。
fstabの詳しい書き方については、Linuxのマウントとfstabの設定方法も参照してほしい。
まとめ — fstab1行が招く「起動しない」エラーを防ぐために
「たった1行の追記」が、サーバーを起動不能にする。fstabはそういうファイルだ。20年以上のLinux運用で私が学んだのは、技術的な手順だけではなく「変更には必ず確認を挟む」という習慣の大切さだ。特にfstabのように、ミスの代償が大きいファイルを扱うときはなおさらだ。
私が現場で見てきた中で、「fstabで詰まった」という話は決して珍しくない。しかし、3つの習慣を守ればそのほとんどは防げる。
| タイミング | やること | コマンド・設定 |
|---|---|---|
| 変更前 | バックアップを取る | cp /etc/fstab /etc/fstab.bak.$(date +%Y%m%d) |
| 変更後・再起動前 | 動作確認する | mount -a |
| NFS設定時 | 起動安全オプション追加 | _netdev,nofail をオプションに追加 |
| 起動しない時 | シングルユーザーモードで復旧 | GRUBで single をカーネル行に追加 |
fstabの変更は慎重に。そして変更後は必ず
mount -a で確認を。この鉄則を、ぜひ今日から身につけてほしい。
fstabの「型」を含む、安全なLinuxサーバー構築を体系的に学びませんか？
fstabのような「1行のミスが大きな障害になる」設定は、体系的に学んでおくことが最大のリスク管理です。コマンドの丸暗記ではなく、なぜそう設定するのかという理由から理解すると、ミスは格段に減ります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxでhttpdの設定を変えたのに何も変わらなかった日の話｜現役講師が語るサービス再起動の落とし穴と3つの確認習慣
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます