背景：fstabが常に最善の選択とは限らない理由
sysadminを始めたばかりの頃、ネットワークドライブ（NFSやSamba）はすべて/etc/fstabに書き込むのが習慣でした。「起動時にマウントしておけば確実だ」という考えで。でも、現実はそう甘くなかった。ある日の午後、バックアップ用のNASが突然電源断。その結果、そのNASからマウントしていたサーバーが軒並み「フリーズ」し始めました。df -hコマンドは反応せず止まったまま。SSHログインも通らない——システムが死んだドライブからのレスポンスをひたすら待ち続けているのです。
/etc/fstabの問題は「静的」マウントを行う点です。ネットワーク接続が不安定だったり、リモートサーバーが再起動されたりすると、クライアントが長時間ハングします。そのとき初めてAutoFSの必要性を実感しました。
AutoFSは実際にそのディレクトリにアクセスしたときだけマウントします。使わなければ60秒後（設定変更可能）に自動でアンマウントします。実際の効果として、深夜3時にネットワークドライブの電源が落ちても、システム全体を道連れにすることがなくなりました。
AutoFSのインストール
本番環境でAutoFSを約6ヶ月運用してみて、非常に軽量だと感じています。デーモン一つ、設定ファイル数個——特別なカーネルモジュールもソースビルドも不要です。
Ubuntu/Debianの場合：
sudo apt update
sudo apt install autofs nfs-common cifs-utils -yRHEL/CentOS/AlmaLinuxの場合：
sudo dnf install autofs nfs-utils cifs-utils -y補足：NFSを使う場合はnfs-common（またはnfs-utils）、Sambaを使う場合はcifs-utilsを追加インストールしておかないと、AutoFSがファイルシステム形式を認識できずエラーになります。
詳細設定：スマートな動作の仕組み
AutoFSの設定は主に2つのファイルに分かれています：マスターマップ（マウントポイントのルートを定義）とマップファイル（リモートサーバーの詳細情報）です。
1. マスターマップの設定
/etc/auto.masterファイルを開きます。ここでAutoFSに管理させる親ディレクトリを宣言します。
sudo nano /etc/auto.masterファイルの末尾に以下の行を追加します：
/mnt/remote /etc/auto.nfs --timeout=60 --ghost/mnt/remote：ローカルマシン上のルートディレクトリ。/etc/auto.nfs：詳細設定ファイル（次のステップで作成します）。--timeout=60：60秒間使用されなければ自動でアンマウントします。--ghost：マウントされていなくてもサブディレクトリを表示します（lsコマンドですぐ確認できて非常に便利）。
2. NFS用マップファイルの設定
次に、/etc/auto.nfsファイルを作成して、どのサーバーをどこにマウントするか指定します。
sudo nano /etc/auto.nfsファイルの内容：
backup -fstype=nfs,rw,soft,intr 192.168.1.100:/data/backup
data -fstype=nfs,rw,soft,intr 192.168.1.100:/data/public/mnt/remote/backupにアクセスすると、AutoFSが自動的に192.168.1.100に接続します。NFSには常にsoft,intrオプションを使うようにしています——サーバーがダウンしても、クライアントは無限に待ち続けるのではなく、すぐにエラーを返します。
3. Samba（Windows共有）用マップファイルの設定
WindowsやSambaを動かしているNASからドライブをマウントする場合、認証部分の設定が少し異なります。/etc/auto.sambaファイルを作成します：
shared_folder -fstype=cifs,credentials=/etc/creds_samba,iocharset=utf8 ://192.168.1.50/Sharedセキュリティのため、ユーザー名とパスワードを別ファイルに分けて保管します：
sudo nano /etc/creds_sambausername=your_user
password=your_password
domain=your_domainこのファイルはrootだけが読めるようにパーミッションを設定することを忘れずに：sudo chmod 600 /etc/creds_samba。最初の頃、これを忘れてパーミッション644のままにしてしまい、バックアップアカウントのパスワードが丸見えになってしまいました。皆さんもご注意を。
テストとモニタリング
設定を反映させるためにサービスを再起動します：
sudo systemctl restart autofs
sudo systemctl enable autofs最も手っ取り早いテスト方法は、実際にディレクトリにアクセスしてみることです：
cd /mnt/remote/backup
ls -lファイルが表示されれば成功です。mount | grep autofsで現在の詳細な状態を確認できます。
エラー発生時のデバッグ
ディレクトリにアクセスしてもエラーが出たり、まったく反応がない場合でも焦らないでください。サービスを停止してからAutoFSをフォアグラウンドモードで起動すると、ログをリアルタイムで確認できます：
sudo systemctl stop autofs
sudo automount -f -vこれで、権限エラー・サーバーIPの誤り・NFSバージョンの不一致といったエラーメッセージがターミナルに詳細表示されます。レガシーシステムの設定で難航するケースに、私がよく使う方法です。
システムログによる監視
長期運用においては、ドライブのアンマウントやネットワーク接続エラーが発生したタイミングをjournalctlで確認するようにしています：
journalctl -u autofs -f実体験から得た結論
正直、これほど小さな設定変更がこれだけ多くの問題を解決してくれるとは思っていませんでした。AutoFSに移行してから、サーバーが稼働中にNASをメンテナンスするときの緊張感がほぼ消えました。以前は事前アナウンス、チーム全員への通知、そして祈り——という手順が必要でした。今はただ電源を切るだけ。SSHセッションごと落ちる代わりに、クライアントはアクセス時にI/Oエラーを返すだけです。
初回の設定とテストに半日ほどかけましたが、その後2年以上、ネットワークドライブの突然の障害でサーバーがフリーズする心配がほぼなくなりました。ネットワークマウントポイントを持つサーバーを管理している方には、かけた手間以上の価値がある、ぜひおすすめしたいアップグレードです。
