LinuxでNFS共有をマウントする最も安全な流れは、サーバー側で共有先を特定ホストまたは特定ネットワークに限定し、syncとroot_squashを基本にexportし、クライアント側では空のマウントポイントへ一度だけ手動マウントして読み書きを確認してから自動化することです。最初から/etc/fstabへ書いたり、全ホストへrw,no_root_squashで公開したりしないでください。
NFSはサーバーのディレクトリをクライアントのファイルシステム階層へ組み込む仕組みです。ローカルディスクと同じ見た目でも、ネットワーク断、サーバー再起動、UID/GID不一致、キャッシュ、ロック、認証方式が動作へ影響します。データベース、仮想マシンイメージ、排他制御が厳しいアプリケーションを置く場合は、その製品がNFSと対象バージョンをサポートするかを先に確認します。
構成を決める判断表
| 要件 | 推奨する出発点 | 避けること |
|---|---|---|
| 社内の少数Linuxホストで共有 | NFSv4、特定ホスト、root_squash | *による無制限公開 |
| 読み取り専用配布 | ro,syncと送信元制限 | 不要なrw |
| 起動時に必須ではない共有 | x-systemd.automountまたはautofs | 到達不能で起動を長時間止める設定 |
| 機密性・強い本人確認が必要 | Kerberosを含むsec設定を設計 | 信頼できないネットワークでAUTH_SYSだけに依存 |
| 高負荷・大容量 | 既定交渉値から計測 | 根拠なくrsize/wsizeやasyncを固定 |
NFSv4を使える環境では、利用ポートや機能がNFSv3より整理されていますが、既存ストレージやクライアントとの互換性を確認します。クライアント側でnfs4というファイルシステム種別を固定する旧手順より、現在のnfs-utilsマニュアルはnfsを使い、必要ならvers=4.2などでプロトコル版を指定する形を説明しています。版を固定するのは互換性確認や障害切り分けが必要な場合に限定します。
サーバー側の準備
パッケージとサービス
Ubuntu Serverではnfs-kernel-server、RHEL系では一般にnfs-utilsを導入します。サービス名と有効化方法は配布版の公式資料を確認してください。既存NFSサーバーへ追加する場合は、現在のexports、接続中クライアント、バックアップ、ファイアウォールを記録し、再起動ではなく設定再読込で済む変更かを確認します。
# Ubuntu Serverの例
sudo apt update
sudo apt install nfs-kernel-server
# RHEL系の例
sudo dnf install nfs-utils共有ディレクトリと所有権
共有ディレクトリを作る前に、どのローカルファイルシステム上に置くか、容量、バックアップ、スナップショット、inode、暗号化を確認します。NFSはサーバー上の通常の所有権と権限を無視しません。とりあえずchmod 777にするのではなく、アプリケーション用のUID/GIDとグループ書き込み、setgid、ACLを設計します。
LinuxのAUTH_SYSを使う一般的なNFSでは、サーバーはクライアントから渡された数値UID/GIDを基に権限を評価します。同じユーザー名でもUIDが違えば別人として扱われます。LDAP、SSSD、集中ID管理、または全ホストでのUID/GID統一を確認します。名前だけを合わせた状態で運用を始めないでください。
/etc/exportsを最小権限で書く
/etc/exportsは、共有パス、許可するホストまたはネットワーク、その直後の括弧内オプションで構成します。Red Hatの公式資料は、ホストと括弧の間に空白があると意味が大きく変わり、意図せず他ホストへ公開し得ることを警告しています。編集後はexportfs -raの結果とexportfs -vを確認します。
/srv/project 192.0.2.25(rw,sync,root_squash,no_subtree_check)例の192.0.2.25は文書用アドレスなので、実環境の固定IPまたは管理された名前へ置き換えます。ネットワーク全体を許可する場合も最小のCIDRにし、クライアント追加の手続きを決めます。root_squashはクライアントrootをサーバーrootとして扱わないための重要な既定保護です。no_root_squashは明確な製品要件と隔離された信頼境界がない限り使いません。
syncはサーバーが変更を書き込む前に応答しない方向の安全な既定です。asyncは性能上の利点があり得ても、障害時のデータ損失範囲を広げる可能性があります。ストレージの保護、アプリの書き込み特性、電源障害、復旧目標を測定せず切り替えません。no_subtree_checkは構成によって有用ですが、共有境界と移動・名前変更の挙動を理解して選びます。
サーバーのファイアウォール
NFSv4のみかNFSv3も必要かで、関連サービスとポートが異なります。RHELではfirewalldの事前定義サービス、UbuntuではUFWまたは上流のフィルタを使い、クライアント送信元に限定します。NFSを通すためにファイアウォール全体を停止しません。クラウド環境ではセキュリティグループにも同じ送信元制限を設定し、インターネットへ直接公開しないでください。
クライアントから手動マウントする
クライアントパッケージ
Ubuntuではnfs-common、RHEL系ではnfs-utilsが一般的です。マウント前にサーバー名が期待したIPへ解決されること、時刻、ネットワーク経路、サーバー側export許可を確認します。NFSv4ではshowmount -eだけで判断できない構成もあるため、最終的には実際のマウントとサーバーログで確認します。
# Ubuntuクライアント
sudo apt install nfs-common
# RHEL系クライアント
sudo dnf install nfs-utils空のマウントポイントを用意する
マウントポイントに既存ファイルがあると、マウント中はそのファイルが見えなくなります。削除されたわけではありませんが、アプリケーションが別データを参照して混乱します。新しい空ディレクトリを作り、findmntで既存マウントがないことを確認してから実行します。
sudo mkdir -p /mnt/project
findmnt /mnt/project
sudo mount -t nfs -o vers=4.2 server.example.com:/srv/project /mnt/project
findmnt -T /mnt/projectvers=4.2はサーバーとクライアントが対応している例です。失敗時に無闇に版を下げず、journalctl、dmesg、サーバーログ、exportパスを確認します。マウントできたら、許可された一般ユーザーで読み取り、作成、更新、削除をテストし、サーバー側でUID/GIDと所有権を確認します。rootだけで成功してもアプリケーションユーザーが動くとは限りません。
アンマウントと切り戻し
試験を戻すときは、対象ディレクトリを使用中のプロセスを止め、シェルの現在ディレクトリも外へ移してからumountします。『target is busy』で強制操作へ進む前にfindmntやfuserで利用者を確認します。強制アンマウントやlazy unmountは未完了I/Oを見えにくくするため、通常の切り戻し手段にしません。
cd /
sudo umount /mnt/project
findmnt /mnt/project自動マウントを安全に設定する
/etc/fstabを使う場合
手動試験が成功してから/etc/fstabへ追加します。編集前にバックアップし、再起動前にmount -aまたは対象だけのマウントで構文と到達性を確認します。NFSが業務上必須でないホストでは_netdev、nofail、x-systemd.automountなどを検討し、ネットワーク未確立時に起動を止めない設計にします。ただし、必須データがないのにアプリを起動させる危険もあるため、サービス依存関係を別途定義します。
server.example.com:/srv/project /mnt/project nfs rw,_netdev,nofail,x-systemd.automount 0 0切り戻すときは、まず利用サービスを停止し、該当行をコメントアウトし、systemd設定を再読込してからアンマウントします。fstabを誤ると起動時に保守モードへ入ることがあるため、遠隔サーバーでは管理コンソールを確保します。編集後のfindmnt --verifyなど利用可能な検証手段を使い、再起動試験はメンテナンス時間内に行います。
autofsを使う場合
多数の共有を常時マウントしたくない場合、autofsはアクセス時にマウントし、一定時間利用がなければ解除できます。Red Hatの公式資料は/etc/auto.masterとマップファイルを使う構成を説明しています。ホームディレクトリなどワイルドカードを使う設計では、ユーザー入力が意図しないパスへ展開されないか、認証と権限が一貫するかを確認します。
性能オプションを変更する前に
現在のLinux NFSクライアントは、rsizeとwsizeをサーバーと交渉できます。古い例にある8192などの値を固定すると、現行ネットワークで性能を下げる場合があります。まず既定値のnfsstat -m、遅延、スループット、再送、サーバーI/O、アプリケーション所要時間を測り、一つずつ変更します。ベンチマークだけでなく、障害時の復旧とデータ整合性を評価します。
softマウントはタイムアウト時にI/Oエラーを返し、アプリケーションによってはデータ破損や黙った欠落につながり得ます。一般的なファイル共有では既定のhard動作を基準にし、ハングに見える問題はネットワーク冗長性、タイムアウト監視、アプリ停止手順で扱います。hard/soft、timeo、retransを変える場合はnfs(5)の警告とアプリベンダーの要件を確認します。
セキュリティを強化する
AUTH_SYSによる数値UID/GIDだけでは、信頼できないクライアントからのなりすましを十分に防げません。機密データや広い組織ネットワークでは、Kerberosを使うsec=krb5、整合性保護のkrb5i、プライバシー保護のkrb5pを要件に応じて検討します。DNS、時刻同期、keytab、主体名、チケット更新を含むため、単一オプションの追加だけでは完了しません。
exportの送信元制限、ホストFW、ネットワーク分離、root_squash、最小権限、暗号化・認証は互いの代替ではなく層として組み合わせます。バックアップもNFS共有と同じ障害ドメインだけに置かず、削除や暗号化被害から復旧できる世代を別管理します。アクセスログと構成変更を監査し、不要になったクライアントの許可を削除します。
症状別トラブルシューティング
| 症状 | 確認点 | 安全な次の手順 |
|---|---|---|
| mountがタイムアウト | 名前解決、経路、FW、NFS版 | サーバーとクライアント両側のログを確認 |
| access denied by server | exportパス、送信元、空白、反映 | exportfs -vで実際の公開を照合 |
| Permission denied | 数値UID/GID、所有権、ACL、root_squash | 一般ユーザーでIDと権限を一致させる |
| 再起動後に起動が遅い | fstab、DNS、ネットワーク依存 | automount/nofailとサービス依存を再設計 |
| I/Oが固まる | サーバー負荷、再送、ネットワーク断 | 強制解除前にI/Oと利用プロセスを保全 |
| 性能が低い | 既定交渉値、再送、MTU、ストレージ | 一項目ずつ計測し、asyncやsoftへ逃げない |
共有が突然読めなくなったとき、アプリケーションがローカルの空ディレクトリへ書き始めると、NFS復旧後に別データが隠れて二重化します。起動時と実行中にfindmntや期待するファイルシステムIDを確認し、必須共有がない場合は書き込み処理を停止させます。既にローカルへ書かれたデータは勝手に上書きせず、時刻と所有者を照合して移送計画を作ります。
設定例を混在させないための確認
本文の手動マウント、fstab、autofsは、それぞれ別の構成例です。同じマウント先に複数の方式を同時適用しないでください。設定ファイルの行はシェルへ直接入力するコマンドではありません。古い例の固定rsize/wsize、async、共有全体への所有者変更を一括適用せず、現在の構成を確認します。
読み取り中心の確認コマンド
# クライアントで実行
findmnt -T /mnt/project
nfsstat -m
# サーバーで実行
sudo exportfs -v
ls -ldn /srv/projectパスは実環境に合わせます。findmntの結果は対象がNFSか、想定するサーバー／exportかまで確認してください。単に出力があるだけでは目的の共有をマウントできた証明になりません。権限不足は、まず数値UID/GIDとACLを調べ、nobodyへの一括chownで回避しません。
autofsのファイル対応例
autofsを選ぶ場合の間接マップ例です。既存のfstabやマウントと重複しないディレクトリを使い、配布版の設定読み込み方法を確認してから設定します。
# /etc/auto.master の例
/mnt/auto /etc/auto.nfs --timeout=600
# /etc/auto.nfs の例
project -fstype=nfs,rw server.example.com:/srv/projectこの例では /mnt/auto/project へのアクセスでマウントを要求します。サーバー名、共有パス、読み書き権限を実際の許可に合わせ、設定反映前に既存利用者への影響と切り戻しを確認してください。
エスカレーションの目安
業務データでI/Oエラーや破損の疑いがある、複数クライアントで同時に停止した、UID/GIDを組織全体で変更する必要がある、Kerberos認証を導入する、fstab誤設定で起動できない、強制アンマウントが必要な場合は、書き込みを止めてストレージ・Linux基盤担当へ連絡します。サーバー名、export、マウントオプション、発生時刻、nfsstat、findmnt、関連ログ、直前変更を保存してください。
よくある質問
NFS共有をインターネットへ公開できますか？
直接公開は避け、信頼できるプライベートネットワークやVPN、送信元制限、必要に応じたKerberos保護を使います。ポート開放だけで安全にはなりません。
no_root_squashを付ければ権限問題は解決しますか？
クライアントrootへ強い権限を与えるため、一般的な解決策にしません。UID/GID、所有権、ACL、アプリケーションユーザーを正しく合わせます。
/etc/fstabへ最初から書いてよいですか？
先に空のマウントポイントへ手動マウントし、読み書き、所有権、再接続を確認します。その後バックアップと起動時の切り戻しを用意して追加します。
rsizeとwsizeは8192にすべきですか？
固定値を前提にせず、現在の交渉値と実測を確認します。現行環境ではより大きい値が自動交渉されることがあり、古い固定値が性能を下げ得ます。
softマウントなら固まらず安全ですか？
I/Oエラーをアプリへ返し、データ破損につながる可能性があります。公式nfsマニュアルの警告とアプリ要件を確認し、一般にはhardを基準にします。
マウントポイントの元ファイルが消えました。
マウント中は下のディレクトリ内容が隠れます。書き込みを止めて正しくアンマウントすると再び見えます。強制削除やコピーをせず、どちら側のデータかを確認します。
公式情報源
- Ubuntu Server 公式ドキュメント
- Red Hat 公式ドキュメント
- Linux man-pages / nfs-utils マニュアル
- Linux man-pages / nfs-utils マニュアル
- Red Hat 公式ドキュメント
- Linux Kernel documentation: ext4 data mode
まとめ
NFSは、サーバーのexportを特定クライアントへ最小権限で公開し、UID/GIDと権限をそろえ、クライアントで手動試験してからfstabまたはautofsへ進むと安全に導入できます。syncとroot_squashを出発点にし、ファイアウォール全停止、no_root_squash、async、soft、古い固定バッファ値を安易に使わないでください。ネットワーク障害時にローカルへ誤書き込みしない確認と、アンマウント・設定復元の手順まで用意して運用します。
コメント