--- title: "NFS（Network File System）とは｜NFSv3とNFSv4の違い・ポート・Samba(SMB)との使い分けを実機で解説" url: "https://www.issoh.co.jp/tech/details/14681/" published: 2026-07-15 updated: 2026-10-18 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # NFS（Network File System）とは｜NFSv3とNFSv4の違い・ポート・Samba(SMB)との使い分けを実機で解説 NFS（Network File System）は、サーバーが公開したディレクトリを、クライアントが自分のディレクトリツリーにマウントして読み書きするファイル共有プロトコルです。Sun Microsystemsが開発し、1989年にNFSv2が[RFC 1094](https://www.rfc-editor.org/info/rfc1094/)として公開されたプロトコルで、いまもLinux／Unixのサーバー間共有で広く使われています。この記事では、NFSv3とNFSv4の違いを「開くポート」「状態管理」「認証」で比較し、Ubuntu 24.04で実際にNFSサーバーを立てて取った出力を根拠に、構築・バージョンの確認・NFSv4専用化の手順と、Samba（SMB）との使い分けを示します。 ## まとめ：対応環境でのNFSv4.2採用と互換性維持のためのv3併用 ファイアウォール設計でまず確認したい違いは、NFSv3とNFSv4で開けるポートの数です。Ubuntu 24.04の実測では、NFSv3を有効にしたサーバーは2049番に加えて rpcbind の111番、`mountd`・`statd`・`nlockmgr` が起動のたびに変わる動的ポートで待ち受けていました。NFSv4.1以降はTCP 2049番だけで通信し、rpcbindを止めてもマウントできます。v4はさらに、ロックとマウントの手続きをプロトコル本体に取り込んだステートフルな設計で、Kerberos認証（`sec=krb5`／`krb5i`／`krb5p`）の実装を仕様で必須にしています。 Linuxのクライアントはバージョンを指定しなければ4.2から順に下げて交渉するので、クライアントとサーバーの双方が4.2に対応し、その利用を許可していれば `vers=4.2` になります。新規構成はNFSv4.2を既定にし、v3は「WindowsのClient for NFS（v2／v3のみ対応）」や古いNAS・ハイパーバイザーがつなぐ場合だけ、ポートを固定して残すのが判断の基準です。Windows端末から部署フォルダを使う共有は、NFSではなくSMB（Linuxで提供するならSamba）を選びます。 ## NFSの仕組み：ディレクトリの公開・マウントとRPCによるファイル操作 サーバーは公開するディレクトリと許可するクライアントを `/etc/exports` に書き、クライアントはそれを `mount` でローカルのパスにつなぎます。アプリケーションは通常のファイル操作APIでアクセスでき、裏でNFSクライアントがファイル操作をRPC（Remote Procedure Call）の要求に変えてサーバーの `nfsd` へ送ります。前提になるLinuxのサービス管理は[Linuxの仕組みとサーバー用途の解説](/tech/details/13160/)、NFSが生まれたUnixの系譜は[UnixとLinuxの違いとPOSIXの解説](/tech/details/15827/)で扱っています。 ### NFSを構成するデーモン：nfsd・rpcbind・mountd・statd・lockd NFSは役割の違う複数のRPCサービスの組み合わせで動き、どれが要るかはバージョンで変わります。 | サービス | 役割 | v3 | v4 | | -------------------------- | ------------- | ------------ | --------- | | nfsd（RPC 100003） | ファイル操作の本体 | 2049番 | 2049番 | | rpcbind（RPC 100000） | RPCサービスのポート案内 | 通常使用・111番 | 不要 | | mountd（RPC 100005） | マウント要求の受付 | 必須・動的 | 通信には不要 | | statd（RPC 100024） | 再起動時のロック回復 | NLM利用時に必要・動的 | 不要 | | nlockmgr／lockd（RPC 100021） | ファイルロック | NLM利用時に必要・動的 | 不要（本体に統合） | v4でも `rpc.mountd` はサーバー側でexportの設定を管理するために動きますが、v4のマウント処理には関与しません。ただし後述の検証では `vers3=n` にしてもmountdの待ち受けは残っていたので、ポートまで閉じるには別の設定が要ります。v3のクライアントはまずrpcbindに「mountdは何番か」を問い合わせ、教わった番号へマウント要求を出してから2049番でファイル操作を始めます。この往復と動的ポートが、v3をファイアウォール越しに通しにくくしている理由です。 ## NFSのバージョン一覧：v2からv4.2までのRFCと主な変更点 NFSの仕様はRFCとして公開されています。v4系は改訂のたびにRFC番号が変わるので、仕様を引くときは現行の番号を使います。 | 版 | 現行のRFC | 公開 | 主な変更点 | | ------- | -------- | -------- | ----------------------- | | NFSv2 | RFC 1094 | 1989年3月 | UDP・32ビットのファイルサイズ | | NFSv3 | RFC 1813 | 1995年6月 | 64ビット化・非同期書き込み・TCP | | NFSv4.0 | RFC 7530 | 2015年3月 | ステートフル・COMPOUND・2049番集約 | | NFSv4.1 | RFC 8881 | 2020年8月 | セッション・pNFS | | NFSv4.2 | RFC 7862 | 2016年11月 | サーバーサイドコピー・スパースファイル | NFSv4.0の最初の仕様は2000年12月の[RFC 3010](https://datatracker.ietf.org/doc/html/rfc3010)で、2003年4月のRFC 3530を経て[RFC 7530](https://datatracker.ietf.org/doc/html/rfc7530)に置き換わりました。NFSv4.1も2010年1月のRFC 5661が[RFC 8881](https://datatracker.ietf.org/doc/html/rfc8881)で置き換えられています。4.2のRFCが4.1の改訂版より古い番号なのはこのためで、4.2は4.1の上に追加機能を載せた小改訂という位置づけです。 ## NFSv3とNFSv4の違い：ポート・状態管理・認証を比較 違いを先に一覧にし、運用に響く3点を実測と仕様で補います。 | 観点 | NFSv3 | NFSv4（4.0〜4.2） | | --------------- | -------------- | ----------------------- | | 開くポート | 111＋2049＋動的ポート | TCP 2049（4.0はコールバック用も） | | トランスポート | UDP／TCP | TCP（RDMAも可・UDPは不可） | | 状態管理 | ステートレス | ステートフル（リース） | | ロック | 別プロトコル（NLM） | プロトコル本体 | | マウント | MOUNTプロトコル | 疑似ファイルシステム | | ユーザーの表現 | 数値のUID／GID | user@domain（sec=sysは数値） | | ACL | POSIX ACL（拡張） | NFSv4 ACL | | Windows標準クライアント | 対応 | 非対応 | ### 開くポートの違い：rpcinfo -p で見るv3の動的ポート Ubuntu 24.04に `nfs-kernel-server` を入れ、v3とv4の両方が有効な既定の状態で `rpcinfo -p` を実行した結果の抜粋です。 ``` $ rpcinfo -p localhost program vers proto port service 100000 4 tcp 111 portmapper 100024 1 tcp 56267 status 100005 3 tcp 60081 mountd 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 4 tcp 34481 nlockmgr ``` nfs本体はv3もv4も2049番ですが、`status`（statd）・`mountd`・`nlockmgr` は5桁の動的ポートで、サービスを再起動すると番号が変わりました。v3をファイアウォール越しに通すには、これらを固定してから穴を開ける必要があります（手順は後述）。[RFC 7530](https://datatracker.ietf.org/doc/html/rfc7530)は、登録済みの2049番を既定の構成にすべき（SHOULD）とし、そうすればクライアントがRPCの番号案内（rpcbind）を使わずにファイアウォールを越えられると書いています。ただしv4.0では、サーバーがクライアントへ委任（delegation）の返却を求めるコールバックを別の接続で張るため、クライアント側のポートも考える必要があります。v4.1以降はコールバックも既存の接続に載るので、[Red Hatのファイアウォール手順](https://docs.redhat.com/en/documentation/red%5Fhat%5Fenterprise%5Flinux/9/html/securing%5Fnetworks/securing-network-services%5Fsecuring-networks)どおりサーバーのTCP 2049番を開ければ足ります。 ### 状態管理とロックの違い：ステートレスなv3とリースを持つv4 v3のサーバーは、誰がどのファイルを開いているかを覚えません。サーバーが再起動しても、クライアントは同じ要求を投げ直せば続きから処理できます。その代わりロックはNFSの外にあり、NLM（lockd）とNSM（statd）という別プロトコルが担います。statdが止まっているとロックの回復ができず、ロックを使うアプリケーションが固まる原因になります。 v4はOPEN・CLOSE・LOCKをプロトコルの操作として持ち、サーバーがクライアントごとの状態をリース（一定時間ごとに更新しないと失効する貸し出し）で管理します。サーバーが再起動すると猶予期間（grace period）が設けられ、その間にクライアントがロックを取り直します。複数の操作を1回の要求にまとめるCOMPOUNDも4.0で入り、往復の多いWANでの効率を上げています。4.1では要求の重複実行を防ぐセッションと、データを複数のサーバーに分散して並列に読み書きするpNFSが加わりました。 ### 認証とIDマッピングの違い：AUTH\_SYSとKerberos・user@domain 既定の認証 `sec=sys`（AUTH\_SYS）は、クライアントが申告するUID／GIDをそのまま信じる方式です。クライアントのroot権限を持つ人なら、任意のUIDを名乗れます。Linuxではv3でもKerberosを使えますが、仕様として実装を必須にしたのはv4です。RFC 7530はKerberos v5を使うRPCSEC\_GSSを「実装しなければならない（MUST）」とし、使うかどうかは運用者に任せています。選べるのは `sec=krb5`（認証のみ）、`krb5i`（改ざん検知）、`krb5p`（通信の暗号化）の3段階です。ユーザーの管理をActive Directoryや[LDAPの認証基盤](/tech/details/13316/)に寄せている組織なら、この仕組みに乗せられます。 もう1つの違いが、ユーザーの表し方です。v4のプロトコルはファイルの所有者を `user@domain` の文字列で送る設計です。ただしLinuxは、`sec=sys` のマウントでは数値のUID／GIDをそのまま受け渡すのが既定です（[カーネルパラメータ](https://docs.kernel.org/admin-guide/kernel-parameters.html) `nfs4_disable_idmapping` の既定値1）。実測でもv4.2のマウントで作ったファイルはサーバー上でUID 501のままでした。名前での対応付けが効くのはKerberosを使うときと、この既定を外したときで、そのときはサーバーとクライアントの `/etc/idmapd.conf` の `Domain` を揃えないと所有者が `nobody` と表示されます。所有者がnobodyと表示される場合は、NFSv4ドメインの不一致に加え、ユーザー名の解決設定やIDマッピングのキャッシュも確認します。 ## 使っているNFSバージョンを確認する方法：nfsstat -m と /proc [nfs(5)](https://man7.org/linux/man-pages/man5/nfs.5.html)によると、Linuxのクライアントは `nfsvers`（`vers`）を指定しないと、まず4.2を試し、サーバーが対応する版まで順に下げて交渉します。v3とv4の両方を有効にしたサーバーへ、版の指定ありとなしで1回ずつマウントした結果が次のとおりです。 ``` $ sudo mount -t nfs -o vers=3 127.0.0.1:/srv/nfs/data /mnt/v3 $ sudo mount -t nfs 127.0.0.1:/srv/nfs/data /mnt/v4 $ nfsstat -m /mnt/v3 from 127.0.0.1:/srv/nfs/data Flags: rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=127.0.0.1,mountvers=3,mountport=43297,mountproto=udp,local_lock=none,addr=127.0.0.1 /mnt/v4 from 127.0.0.1:/srv/nfs/data Flags: rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1 ``` 指定なしのマウントは `vers=4.2` に決まりました。v3のマウントにだけ `mountport=43297` と `mountproto=udp` が付いており、mountdの動的ポートへUDPで問い合わせてからマウントしたことが分かります。`nfsstat` が入っていないクライアントでは、`grep nfs /proc/mounts` で同じ情報が読めます（ファイルシステム種別もv3は `nfs`、v4は `nfs4` と表示されます）。 サーバー側で有効な版は `/proc/fs/nfsd/versions` に出ます（root権限が必要）。既定の状態では `+3 +4 +4.1 +4.2` でした。先頭の `+` が有効、`-` が無効です。 ## NFSサーバーの構築とマウント手順：Ubuntu 24.04の場合 ここからの手順は、colima上のUbuntu 24.04（`nfs-kernel-server` 2.6.4）で確認した操作を基に、別ホスト接続用のIPアドレスに置き換えて示しています。実測ログは同一VM内のループバック接続によるものです。RHEL系ではパッケージ名が `nfs-utils` になり、サービス名は同じ `nfs-server` です。 ### /etc/exports の設定と exportfs -ra による共有公開 ``` $ sudo apt-get install -y nfs-kernel-server $ sudo mkdir -p /srv/nfs/data $ echo '/srv/nfs/data 192.168.0.0/24(rw,sync,no_subtree_check)' | sudo tee -a /etc/exports $ sudo exportfs -ra $ sudo exportfs -v /srv/nfs/data 192.168.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash) ``` `exportfs -v` は、書いていないオプションも既定値込みで表示します。`rw,sync,no_subtree_check` の3つしか書いていないのに、`root_squash`・`secure`・`sec=sys` が付いているのが分かります。[exports(5)](https://man7.org/linux/man-pages/man5/exports.5.html)では、nfs-utils 1.0.0より後は `sync` が既定、1.1.0以降は `no_subtree_check` が既定です。`rw` を書かなければ読み取り専用になります。ただし、`rw` だけでは共有ディレクトリへの書き込み権限は付与されません。作成した `/srv/nfs/data` の所有者・グループとモードを設定し、クライアントの利用者に対応するUID／GIDへ書き込み権限を与える必要があります。ホスト名と括弧の間に空白を入れると、括弧内のオプションが「指定ホスト以外の全員」に適用されるので、`192.168.0.0/24 (rw)` のような書き方は避けます。exportsの変更は `exportfs -ra` で反映され、NFSサービスの再起動は要りません。 ### クライアントのマウント操作と /etc/fstab による永続化 ``` $ sudo apt-get install -y nfs-common $ sudo mkdir -p /mnt/data $ showmount -e 192.168.0.10 $ sudo mount -t nfs -o vers=4.2 192.168.0.10:/srv/nfs/data /mnt/data # /etc/fstab に追記（_netdev でネットワーク起動後にマウント） 192.168.0.10:/srv/nfs/data /mnt/data nfs vers=4.2,hard,_netdev 0 0 ``` `showmount -e` はmountdに問い合わせるv3系の仕組みなので、後述のNFSv4専用サーバーには使えません。fstabでは版を明記しておくと、サーバー側でv4が無効になったときに黙ってv3へ落ちるのを防げます。`hard` はサーバーが応答しない間、I/Oを失敗させずに待ち続ける既定の動作で、データの書き込みを扱う共有ではこちらを使います。 ## ファイアウォール越しにNFSを通す設定：v4専用化とv3のポート固定 サーバーとクライアントの間にファイアウォールやセキュリティグループがあるなら、まずv3が要るかを確認します。要らなければv4専用にし、要るならv3の補助サービスのポートを固定します。 ### NFSv4専用サーバーにする手順：vers3=n と rpcbind の停止 Red Hatの[NFSv4専用サーバーの設定](https://docs.redhat.com/ja/documentation/red%5Fhat%5Fenterprise%5Flinux/8/html/deploying%5Fdifferent%5Ftypes%5Fof%5Fservers/configuring-an-nfsv4-only-server%5Fdeploying-an-nfs-server)と同じ考え方で、`/etc/nfs.conf` の `[nfsd]` セクションに `vers3=n` を書き、rpcbindとstatdを止めます。Ubuntu 24.04では `/etc/nfs.conf.d/` に別ファイルとして置けます。以下はサーバー自身で行うループバック検証です。事前に `/etc/exports` で共有先として `127.0.0.1(rw,sync,no_subtree_check)` を許可し、`sudo exportfs -ra` で反映したうえで、`sudo mkdir -p /mnt/v3 /mnt/v4` を実行しておきます。 ``` $ printf '[nfsd]\nvers3=n\n' | sudo tee /etc/nfs.conf.d/v4only.conf $ sudo systemctl restart nfs-server $ sudo cat /proc/fs/nfsd/versions -3 +4 +4.1 +4.2 $ sudo systemctl stop rpcbind.socket rpcbind rpc-statd $ sudo mount -t nfs -o vers=4.2 127.0.0.1:/srv/nfs/data /mnt/v4 # 成功 $ sudo mount -t nfs -o vers=3 127.0.0.1:/srv/nfs/data /mnt/v3 mount.nfs: requested NFS version or transport protocol is not supported for /mnt/v3 ``` rpcbindが止まった状態でもv4のマウントは成功し、v3は「requested NFS version or transport protocol is not supported」で失敗しました（終了コード32）。v4.1以降のクライアントだけなら、開けるのはTCP 2049番だけです。Red Hatの手順は、さらに `rpc.mountd` を `--no-tcp --no-udp` で起動してネットワークで待ち受けないようにしています（mountd自体はexportの管理に必要なので止めません）。検証では `systemctl stop` で止めたところ、v3のマウントを試した時点でrpc-statdとrpcbindが自動で起動し直しました。本番では `sudo systemctl mask --now rpcbind.socket rpcbind rpc-statd` で自動起動ごと止めます（Red Hatの手順と同じ。mask後の挙動はこの検証では測っていません）。 v4専用にすると、WindowsのClient for NFSはつながらなくなります。[Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/storage/nfs/nfs-overview)の対応表では、WindowsのClient for NFSが対応するのはNFSv2とv3だけで、v4.1に対応しているのはWindows Server側のServer for NFSです。 ### NFSv3を残す場合にポートを固定する手順：nfs.conf と lockd の sysctl この手順は、NFSv3が有効で、rpcbindとrpc-statdがマスクされていないサーバーが対象です。直前のv4専用化を試した場合は、`sudo rm /etc/nfs.conf.d/v4only.conf` と `sudo systemctl unmask rpcbind.socket rpcbind rpc-statd` で設定を戻してから実行してください。 ``` # /etc/nfs.conf.d/ports.conf [mountd] port=20048 [statd] port=32765 outgoing-port=32766 # lockd はカーネル側の値なので sysctl で固定する $ sudo sysctl -w fs.nfs.nlm_tcpport=32803 fs.nfs.nlm_udpport=32769 $ sudo systemctl restart nfs-server rpc-statd $ rpcinfo -p localhost | grep -E 'mountd|status|nlockmgr' 100005 1 tcp 20048 mountd 100024 1 tcp 32765 status 100021 1 tcp 32803 nlockmgr ``` mountdとstatdは `nfs.conf` の設定だけで固定されました。[nfs.conf(5)](https://man7.org/linux/man-pages/man5/nfs.conf.5.html)には `[lockd]` の `port`／`udp-port` もありますが、今回の環境ではそれを書いて `nfs-server` を再起動しても動的ポートのままで、sysctlの `fs.nfs.nlm_tcpport`／`nlm_udpport` を設定して初めて固定されました（OSの再起動後に `[lockd]` が効くかは検証していません）。再起動後も保つには `/etc/sysctl.d/` に同じ値を書きます。開けるポートは111・2049・20048・32765・32803（UDPも使うなら32769）です。 ## exportsのセキュリティと性能のオプション：root\_squash と sync ### root\_squash・no\_root\_squash・all\_squash のID写像の実測結果 クライアントのrootと一般ユーザー（UID 501）で同じ共有にファイルを作り、サーバー側で所有者を確かめた結果です。 | exportのオプション | rootが作成 | UID 501が作成 | | ------------------------------------- | ----------- | ---------- | | 既定（root\_squash） | 65534:65534 | 501:1000 | | no\_root\_squash | 0:0 | 501:1000 | | all\_squash,anonuid=2000,anongid=2000 | 2000:2000 | 2000:2000 | 既定の `root_squash` は、クライアントのrootをサーバーの匿名ユーザー（UID／GID 65534＝nobody）に置き換えます。v3でもv4でも結果は同じでした。`no_root_squash` にするとクライアントのrootがサーバー上でもrootとして書き込めるので、クライアントを1台乗っ取られると共有の全ファイルが書き換えられます。exports(5)が「主にディスクレスクライアント向け」と説明しているとおり、使うのはサーバーと同じ管理者が持つ限られたホストだけにします。`root_squash` が匿名IDへ写像するのはUID 0とGID 0で、`sec=sys` では他のUIDを名乗ることは防げない点も押さえておきます。共有全体を1つのユーザーに揃えたいときは `all_squash` と `anonuid`／`anongid` を使います。 ### sync と async の書き込み性能の差 `async` は、サーバーがディスクへ書き終える前にクライアントへ完了を返すオプションです。速くなる代わりに、サーバーが落ちると完了を返したはずのデータが失われます。同じVM内のループバックで、v4.2のマウント先に2バイトのファイルを2,000個作成し、最後のsyncコマンドの完了までを2回ずつ測りました。sync、async、sync、asyncの順に実行した参考測定で、ストレージやキャッシュの条件を統制した性能比較ではありません。 | export | 小ファイル2,000個 | 512MiB（fsync付きdd） | | -------------- | ----------- | ----------------- | | sync（1回目／2回目） | 4.96秒／5.17秒 | 0.99秒／1.01秒 | | async（1回目／2回目） | 2.30秒／1.95秒 | 0.76秒／0.64秒 | 小ファイル作成の平均所要時間はsyncが5.065秒、asyncが2.125秒で、asyncはsyncの約42％の時間で完了しました。512MiBの連続書き込みでは差が縮みました。物理ネットワークを経由しないループバックでの参考値で、ディスク同期の待ち時間を個別に測った結果ではありません。ビルドの中間ファイルのように消えても作り直せるデータならasyncを選ぶ余地があり、業務データやデータベースのファイルはsyncのままにします。共有元のディスク障害には、[RAIDの構成と冗長化設計](/tech/details/13465/)で別に備えます。 ## NFSとSMB（Samba）の違い：対象OSと権限管理で選び分ける SMB（Server Message Block）はWindowsが標準で使うファイル共有プロトコルで、SambaはそのSMBをLinux／Unixで提供するソフトウェアです。NFSとSMBはどちらもファイル共有ですが、権限の考え方が違います。 | 観点 | NFS | SMB（Samba） | | --------- | ----------------------- | -------------- | | 標準のクライアント | Linux／Unix | Windows・macOS | | ユーザーの識別 | UID／GID（v4はuser@domain） | ユーザー名とパスワード・AD | | 使うポート | 2049（v3は111ほか） | 445 | | 向く用途 | サーバー間の共有・コンテナの永続ボリューム | 端末から使う部署フォルダ | 同じストレージをLinuxにはNFS、WindowsにはSMBで見せる併設もできますが、両方から同じファイルを書く場合は、サーバー実装と設定によるロックの連携およびキャッシュの整合性を確認する必要があります。Sambaの構築とActive Directory連携は[Sambaとは｜SMBのLinux実装の仕組みとNFSとの使い分け](/tech/details/14682/)で解説しています。 ## NFSの採用・見送り条件とクラウドのマネージドNFSの対応版 NFSが向くのは、UID／GIDを揃えられるLinuxサーバー群が同じファイルを共有する閉じたネットワークです。Webサーバーのアップロード領域、バッチの入出力、コンテナや仮想マシンの永続ボリュームが典型です。 見送るべきなのは次の場面です。Windows端末が主体の共有は、前述のとおり標準クライアントがv3止まりなのでSMBにします。インターネット越しにNFSv3をそのまま公開するのは、ポート開放の数と `sec=sys` の弱さの両方で避けます。拠点間でどうしても使うなら、v4.2＋Kerberos（`krb5p`）かVPNの中に閉じます。数億個のファイルをHTTPで配る用途は、ファイル共有ではなく[オブジェクトストレージ](/tech/details/13369/)の領分です。 クラウドでは、NFSサーバーを自前で立てずにマネージドサービスを使う選択肢があります。対応する版は各社で違い、v4.2を前提にした設定はそのまま持ち込めません。 | サービス | 対応するNFSの版 | | ---------------------- | --------------------------------------- | | Amazon EFS | v4.0・v4.1（4.1を推奨） | | Azure Files（NFS共有） | v4.1 | | Google Cloud Filestore | v3（全階層）・v4.1（Zonal・Regional・Enterprise） | [EFSのマウント手順](https://docs.aws.amazon.com/efs/latest/ug/mounting-fs-old.html)は `nfsvers=4.1` を推奨し、`nconnect` には対応していません。fstabの例は `nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,_netdev` です。Azure Filesは[計画ガイド](https://learn.microsoft.com/en-us/azure/storage/files/storage-files-planning)でNFS 4.1、Filestoreは[対応プロトコルのページ](https://docs.cloud.google.com/filestore/docs/about-supported-protocols)で階層ごとの版を示しています。AWSのEFSの料金とマウント手順は[Amazon EFSとは？S3・EBS・FSxとの違い](/tech/details/3418/)で、オンプレのNFSクライアントからS3へつなぐ構成は[AWS Storage Gatewayの使い分け](/tech/details/17250/)で扱っています。オンプレのNFSからクラウドへの移行や、NFS／SMB混在環境の設計は、[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)で承っています。 ## NFS（Network File System）に関するよくある質問 ### NFSが使うポート番号は何番ですか？ NFS本体はTCP 2049番で、NFSv4.1以降ならこの1つで済みます。NFSv3はこれに加えてrpcbindの111番と、起動のたびに変わるmountd・statd・lockdのポートが要るため、`nfs.conf` とsysctlで固定してから開けます。 ### NFSのバージョンはいくつありますか？ 現在使われているのはNFSv3（RFC 1813）とNFSv4の3つのマイナー版、v4.0（RFC 7530）・v4.1（RFC 8881）・v4.2（RFC 7862）です。NFSv2（RFC 1094）は古い版で、RHEL 9はクライアントもサーバーもNFSv2に対応していません。Linuxのクライアントは指定がなければ4.2から順に交渉します。 ### NFSとSMBはどちらが速いですか？ プロトコル名だけでは決まりません。Linux同士ではNFSが選択肢になり、Windows端末からの共有では標準のSMBが選択肢になります。性能の優劣は、同じ環境と処理内容で比較して判断します。速さを左右するのは、syncとasync、`rsize`／`wsize`、ネットワークの遅延、ファイルの大きさと数です。今回のループバック測定では、小ファイル2,000個の作成時間はasync設定でsync設定の半分未満でしたが、改善幅は環境と処理内容に依存します。 ### NFSはWindowsから使えますか？ 使えます。Windowsの「NFS用クライアント」機能を有効にすれば、Linuxの共有をマウントできます。ただし対応するのはNFSv2とv3だけなので、サーバー側でv3を有効にしておく必要があります。UID／GIDの対応付けも要るため、Windows端末が主体ならSMBを選ぶほうが運用は簡単です。 ### exportsの設定を変えたらNFSサーバーの再起動は必要ですか？ 不要です。`sudo exportfs -ra` で `/etc/exports` を読み直せば反映されます。ただし `/etc/nfs.conf` の版やポートの設定を変えたときは、`systemctl restart nfs-server` が要ります。マウント済みのクライアントは、パスや権限の変更によっては再マウントが必要です。 ## 関連記事 - [Sambaとは｜SMBのLinux実装の仕組みとNFSとの使い分け・AD連携を実装目線で解説](/tech/details/14682/) - [Amazon EFSとは？S3・EBS・FSxとの違いと東京の料金・マウント手順【2026年版】](/tech/details/3418/) - [AWS Storage Gatewayとは？3種のゲートウェイの使い分けとオンプレ段階移行の構成を実装者目線で解説](/tech/details/17250/) - [RAIDとは？RAID0/1/5/6/10の違いと構成・企業のディスク冗長化設計を実装目線で解説【2026年版】](/tech/details/13465/) - [ストレージとは？種類・HDDとSSDの違い・企業のクラウド選定まで解説【2026年】](/column/details/13333/) --- 出典: [NFS（Network File System）とは｜NFSv3とNFSv4の違い・ポート・Samba(SMB)との使い分けを実機で解説]()（株式会社一創）