インフラ

NFS(Network File System)とは|仕組みとNFSv4/v3の違い・Samba(SMB)との使い分けを実装目線で解説

NFS(Network File System)は、リモートのサーバ上にあるディレクトリを、あたかもローカルのファイルシステムのようにマウントして読み書きするための共有プロトコルです。1984年にSun Microsystemsが設計した、歴史あるファイル共有の仕組みです。いまもLinux/Unix系のサーバ間ファイル共有では標準的な選択肢になっています。本記事ではRPCによるマウントの仕組み、NFSv3とNFSv4の設計差、SMB/Sambaとの使い分け、採用と見送りの判断基準を実装者の解像度で整理しました。/etc/exports やroot_squashといった運用の勘所も扱います。

まとめ:NFSはUnix/Linux間のファイル共有基盤・SMBとは対象と用途で選び分ける

NFSはサーバのディレクトリをネットワーク越しにマウントさせるプロトコルで、Unix/Linuxサーバ同士のファイル共有に向きます。クライアントはRPC経由でサーバにマウント要求を出し、共有されたディレクトリをローカルのパスとして扱えます。設計上の大きな分かれ目はバージョンです。NFSv3系は rpcbind(ポート111)と複数の補助デーモンを使う構成、NFSv4系はTCP 2049の単一ポートに集約して状態管理と認証(Kerberos連携)を組み込んだ構成になります。ファイアウォール越しやクラウド前提なら、迷わずNFSv4系を選ぶのが実装上の素直な判断です。

WindowsクライアントからのアクセスやユーザーごとのアクセスコントロールをActive Directoryで統合したい共有には、SMB(Windows標準のプロトコル)とその実装であるSambaが向きます。NFSはプロトコルそのもの、Sambaは別プロトコルSMBのLinux実装、という関係を押さえると選定が速く進みます。ファイル単位ではなくオブジェクト単位でHTTP APIから扱う共有が必要なら、候補はそもそもファイル共有ではありません。以降で仕組みと判断基準を具体的に掘り下げます。

NFSの定義と仕組み:RPCでリモートディレクトリをマウントする構造

NFSの中核は「サーバが公開(export)したディレクトリを、クライアントが自分のディレクトリツリーの一点にマウントする」という動作にあります。アプリケーションから見ればローカルパスへの読み書きと変わらず、その裏でNFSクライアントがネットワーク越しのファイル操作へ変換しています。この透過性が、複数サーバで同じデータを参照させたい構成でNFSが選ばれる理由です。

クライアント/サーバとRPC — マウント要求からアクセスまでの流れ

NFSはRPC(Remote Procedure Call)の上に構築された仕組みです。クライアントは「ファイルを読む」「ディレクトリを一覧する」といった操作を、ローカル関数呼び出しと同じ形でサーバへ送ります。受け取ったサーバ側のNFSデーモン(nfsd)が処理し、結果をクライアントへ返す流れです。実体はネットワークをまたいだ手続き呼び出しでありながら、呼び出す側のコードはローカル処理と区別せずに書けます。動作の前提となるLinuxそのものの基礎は、Linuxとはで解説したファイルシステムとサービス管理で確認できます。NFSの提供側は、突き詰めればファイル共有機能を担う一台のサーバーとはで整理したサーバの役割の一形態です。

exportとmount — 公開設定とマウント手順の実際の流れ

サーバ側は公開するディレクトリと許可するクライアント、権限を /etc/exports に記述し、exportfs -ra で反映します。クライアント側はmountコマンドで共有をマウントし、恒久化するなら /etc/fstab に登録します。具体的な手順は次のとおりです。

  1. サーバの /etc/exports に「/data 192.168.0.0/24(rw,sync,no_subtree_check)」のように公開範囲とオプションを定義する
  2. exportfs -ra で設定を再読み込みし、NFSサービスを起動する
  3. クライアントで「mount -t nfs 10.0.0.10:/data /mnt/data」を実行してマウントする
  4. 安定運用では /etc/fstab に登録し、再起動後も自動マウントされるようにする

ここで指定する sync(書き込みを同期)や no_root_squash の扱いは、後述のセキュリティと性能の章で判断基準を示します。オプションの意味を理解せずに rw を広い範囲へ開けると、共有全体が誰からでも書き換え可能になり、権限事故につながります。

NFSのバージョン差:NFSv3とNFSv4の設計はどこが違うのか

NFSは版によって通信の作法が変わります。既存環境の互換性、ファイアウォール構成、認証要件のどれを優先するかで選ぶ版が決まるため、実装前に版を固定しておくと運用がぶれません。

NFSv3とNFSv4の違い — 使用ポート・状態管理・認証方式

NFSv3系(RFC 1813・1995年)は、マウント要求を rpcbind(ポート111)が仲介し、mountdstatd といった補助デーモンが動的ポートを使う構成です。サーバはクライアントの状態を保持しない設計(ステートレス寄り)で、ファイルロックは別デーモンが担います。一方のNFSv4系(RFC 7530系・2010年代に改訂)は、通信をTCP 2049の単一ポートへ集約し、ロックやマウントの手続きをプロトコル本体へ取り込みました。状態を持つステートフルな設計になり、Kerberosによるユーザー認証(RPCSEC_GSS)も標準で組み込めます。

観点 NFSv3系 NFSv4系
使用ポート 111(rpcbind)+動的ポート群 2049(TCP)単一に集約
状態管理 ステートレス寄り・ロックは別 ステートフル・ロックを統合
認証 ホスト/UID・GIDベース Kerberos認証を標準サポート
ファイアウォール 複数ポート開放が必要 単一ポートで通しやすい

クラウドやDMZ越しの共有、ゼロトラスト寄りの環境ならNFSv4系が扱いやすく、既存のNFSv3資産と互換を保ちたい閉じたLAN内ならv3系を維持する、という切り分けが実務では現実的です。

NFSv4.1/4.2の拡張 — pNFSとサーバサイドコピー

NFSv4.1系(RFC 5661)はpNFS(Parallel NFS)を導入しました。メタデータ管理サーバとデータ格納サーバを分離し、大規模データを複数ノードから並列に読み書きできる構造です。続くNFSv4.2系(RFC 7862・2016年公開)では、サーバ内でのファイル複製をクライアント経由のコピーなしで実行するサーバサイドコピーなどが加わりました。版番号と実装機能の対応は環境で異なるため、採用時はカーネルと nfs-utils の版で実際に有効な機能を確認してから設計へ織り込むのが安全です。ここは「NFSv4.2系(2016年前後の実装)」のように時点付きで扱い、断定は避けます。

NFSとSMB/Samba:ファイル共有プロトコルをどう選び分けるか

ファイル共有プロトコルの二大選択肢がNFSとSMBです。NFSはネットワークプロトコルそのもので、SMBはWindowsが標準採用する別のプロトコル、そのSMBをLinux上で提供するソフトウェアがSambaにあたります。両者は競合というより、対象OSと管理体系で棲み分けます。

NFSとSMB(Samba)の違い — 対象OS・実装・用途

NFSはUnix/Linux間の共有で、UID/GIDを前提にしたPOSIX的な権限管理と相性が良い仕組みです。対するSMB/Sambaは、ユーザー名/パスワードやActive Directoryと統合した権限管理に強みがあります。「サーバ群が同じデータボリュームを参照するバックエンド共有」ならNFS、「社内のWindows端末から部署フォルダへアクセスするファイルサーバ」ならSMB/Sambaが素直な選択です。

観点 NFS SMB / Samba
種別 ファイル共有プロトコル本体 SMBはプロトコル・Sambaは実装
主な対象OS Unix/Linux Windows(Linuxも利用可)
権限管理 UID/GIDベース(POSIX) ユーザー認証・AD統合に強い
典型用途 サーバ間のバックエンド共有 端末からの部署フォルダ共有

混在環境では、Linuxサーバ群にNFS、Windows端末向けにSMB(Samba)を同一ストレージ上で併設する構成も取れます。この共有の土台になる記憶装置の選び方は、ストレージとはで整理した記憶装置の種類と選定を前提にすると設計が具体化します。SMB/Sambaそのものの仕組みと選び方は、Sambaとはで解説したSMBのLinux実装とNFSとの使い分けで扱っています。

NFSを採用する構成と見送るべき構成:判断基準を条件付きで示す

ここは競合が曖昧に済ませがちな判断部分です。NFSは万能ではなく、向く構成と向かない構成がはっきり分かれます。採用条件と見送るべき場面を、条件付きで示します。

NFSが適する構成/見送るべき構成 — 採用条件と失敗パターン

採用が適するのは次の3つの場合です。第一に、複数のLinuxサーバ(Webサーバ群やバッチサーバ群)が同一のファイル群を共有し、UID/GIDで権限を統一できる閉じたネットワーク。第二に、コンテナや仮想マシンの永続ボリュームとして、同じデータを複数ノードから参照させたい構成。第三に、すでにUnix/Linuxで運用が固まっており、追加の認証基盤を増やしたくない環境です。

逆に見送るべき場面もあります。Windowsクライアントからのアクセスが主体なら、NFSを無理に通さずSMB/Sambaを選ぶべきです。UID/GIDの整合を取れない不特定多数の端末へ開く共有も、NFSの権限モデルでは事故のもとになります。インターネット越しに広域公開したい共有や、ファイル単位ではなくオブジェクト単位で大量データを扱いたい要件では、オブジェクトストレージとはで解説したオブジェクト指向の格納方式が適します。典型的な失敗は、WAN越しにNFSv3をそのまま通そうとしてポート開放と遅延に苦しむケースで、この場合は要件自体を見直すのが近道です。

自社では、オンプレとクラウドをまたぐファイル共有基盤の設計や、NFS/SMB混在環境の移行を含むインフラ構築を受託しています。共有方式の選定から可用性設計まで踏み込みたい場合は、AWS/GCP/Azureのインフラ構築サービスから相談いただけます。

NFS運用で外せない注意点:セキュリティ設定と性能チューニングの勘所

NFSは動かすだけなら簡単ですが、既定値のまま本番へ出すと権限と可用性で問題を抱えます。運用で外せない設定を絞って示します。

セキュリティと性能 — root_squash・TCP・可用性の勘所

セキュリティ面でまず押さえるのは root_squash です。既定の root_squash は、クライアント側のrootをサーバ上の匿名ユーザー(nobody)へ写像し、共有先でroot権限を握られる事故を防ぎます。これを no_root_squash へ変えてよいのは、バックアップ用途など影響を理解した限定的な場面だけです。公開範囲は /etc/exports でIPレンジを絞り、社外へは直接開かず、必要ならNFSv4系のKerberos認証を併用します。

性能と可用性では、トランスポートにTCPを用い(いまの実装は既定でTCP)、書き込み整合性が要る用途は sync、スループット優先で許容できる用途は async と、要件で使い分けます。共有元ストレージが単一障害点にならないよう、下位の記憶装置は RAIDとはで解説した冗長化の考え方で守るのが前提です。サーバ自体も冗長構成を検討します。NFSサーバが停止すると、マウントしている全クライアントのI/Oが待たされます。だからこそ可用性設計は、共有プロトコルの選定と同じ比重で扱うのが実務の要点です。

NFS(Network File System)に関するよくある質問

NFSの導入・選定でつまずきやすい点を、実装者からの質問形式で整理します。

NFSとSMBはどちらが速いですか?

一概には決まりません。Linuxサーバ間でUID/GID前提のバックエンド共有ならNFSがオーバーヘッドの少ない構成にしやすく、Windows端末からのアクセスやAD統合が絡む共有ではSMB/Sambaのほうが管理と体感の両面で有利になりがちです。プロトコル版(NFSv4系かv3系か)、TCP設定、ネットワーク遅延で結果が変わるため、実データに近い条件でベンチマークして判断するのが確実です。

NFSv3とNFSv4のどちらを使うべきですか?

新規構成でファイアウォール越しやクラウド、Kerberos認証を見込むならNFSv4系が扱いやすく、既存のNFSv3資産と互換を保ちたい閉じたLANならv3系維持が現実的です。v4系はポートを2049へ集約でき、状態管理と認証をプロトコル本体に取り込んでいる点が選定の決め手になります。

NFSはWindowsから使えますか?

使えます。WindowsにはNFSクライアント機能があり、Linuxサーバの共有をマウントできます。ただしWindows端末が主体の環境では、権限管理とドメイン統合の面でSMB(Samba)を選んだほうが運用は素直です。混在環境では、同一ストレージにNFSとSMBを併設する構成も取れます。

exportsの設定を変えたら再起動が必要ですか?

サービス全体の再起動は不要な場合が多く、exportfs -ra で公開設定を再読み込みすれば反映されます。マウント済みクライアント側の挙動が変わる変更(権限やパスの変更)では、クライアントで再マウントが必要になることもあります。

NFSとオブジェクトストレージはどう違いますか?

NFSはディレクトリとファイルをパスで扱い、POSIX的な読み書きができるファイル共有です。オブジェクトストレージはファイルをキーで識別するオブジェクトとして格納し、HTTP API経由で大量データを扱うのに向きます。既存アプリがローカルファイル前提で動くならNFS、Webスケールの非構造データ蓄積ならオブジェクトストレージ、と用途で選び分けます。

関連記事

  • Linuxとは:NFSサーバ/クライアントが動くLinuxの基礎とサービス管理を確認できます。
  • サーバーとは:NFSサーバもその一形態であるサーバの役割全体を整理しています。
  • ストレージとは:NFSで共有する土台となる記憶装置の種類と選定を解説しています。
  • オブジェクトストレージとは:ファイル共有ではなくオブジェクト単位で扱う格納方式との違いが分かります。
  • RAIDとは:NFSの共有元ストレージを守る冗長化の考え方を扱っています。
資料請求

RELATED POSTS 関連記事