Linux NFS Server v4 Configuration and Export Options

NFSv4 is a very different protocol from NFSv3, even though the configuration file looks similar. It uses a single well-known port (2049) for everything, it has a stateful protocol with leases and client recovery, and it introduces the pseudo-filesystem — an exported directory tree rooted at the server's export root, through which the client navigates to individual exports. Most NFSv4 problems come from misunderstanding that last point, or from export options that silently deny clients. This guide covers writing exports, the options that matter, firewall implications, and verification.

NFSv4 Versus NFSv3 in Practice

• Ports — NFSv4 needs only TCP 2049. NFSv3 needs rpcbind plus the mountd and statd ports, which is why v3 behind a firewall is painful.
• Path format — v4 uses a single root path with pseudo-filesystem traversal, e.g. /export/data. v3 uses separate mount points per export.
• Ownership — v4 uses user@domain names. A domain mismatch between server and client breaks ownership mapping even when the numeric IDs match.
• State — v4 is stateful, so the server tracks clients and leases. Restarting the server without allowing enough grace time can cause client I/O errors.

Install and Enable the Server

sudo apt install -y nfs-kernel-server
# or: sudo dnf install -y nfs-utils

sudo systemctl enable --now nfs-server
systemctl status nfs-server

Confirm which NFS versions the kernel is serving and that rpcbind is only needed for v3 compatibility:

cat /proc/fs/nfsd/versions
rpcinfo -p | grep -E "nfs|mountd"

Write the exports File

Each export names a directory and an access list with options. A minimal, sane v4 export:

/export/data   10.10.20.0/24(rw,sync,no_subtree_check,root_squash)
/export/home   10.10.20.0/24(rw,sync,no_subtree_check)
/export/iso    *(ro,sync,no_subtree_check)

Export option reference

The options worth understanding:

• rw / ro — read-write or read-only.
• sync — writes are committed before the request returns. Keep it. async is faster and risks data loss after a crash, which is a bad trade for a shared filesystem.
• no_subtree_check — disables the check that the requested file is within the exported subtree. It is the default recommendation because the check is slow and rarely catches anything useful.
• root_squash — maps client uid 0 to the anonymous user, preventing a client root from owning files on the server. Never disable it on a shared export; no_root_squash lets any client with root write arbitrarily as root on the server.
• all_squash / anonuid / anongid — force all access to an anonymous identity, which is the right pattern for a read-only public drop.
• sec=sys / sec=krb5 — security flavour. The default sys flavour trusts the client's claimed UID; Kerberos is required where that trust is unacceptable.

A hardening-focused export for a group-writable shared area:

/export/shared  10.10.20.0/24(rw,sync,no_subtree_check,root_squash,all_squash,anonuid=1001,anongid=1001)

Set the NFSv4 Domain

The v4 domain on the server must match what clients use, or ownership appears as nobody:nogroup:

sudo vi /etc/idmapd.conf
# [General]
# Domain = example.com

sudo systemctl restart nfs-idmapd nfs-server

On clients, set the same domain in /etc/idmapd.conf, and remember that with Kerberos the mapping is authoritative — an inconsistent domain will break access in ways that look like permissions problems but are not.

Apply, Export, and Verify

sudo exportfs -ra
sudo exportfs -v
sudo exportfs -s
showmount -e localhost
sudo systemctl reload nfs-server

exportfs -v prints the effective options the server will apply, which is the authoritative view — do not trust the file alone. showmount -e lists what clients will see.

Mount from a client and verify the result:

sudo mkdir -p /mnt/data
sudo mount -t nfs4 server01:/export/data /mnt/data
mount | grep nfs4
df -h /mnt/data
nfsstat -m

Auto-discovering exports with NFSv4

With v4, the client can also auto-discover exports by mounting the server's pseudo-filesystem root — mount -t nfs4 server01:/ /mnt — which shows every exported path in one directory tree. Use it during commissioning to confirm exactly what is exposed.

Firewall and Performance Notes

sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=mountd
sudo firewall-cmd --reload

For v4-only deployments, opening TCP 2049 is enough and mountd/rpcbind rules can be omitted. Keep the rpcbind rules if you still serve v3 clients.

For throughput, check the negotiated read and write sizes rather than assuming defaults are optimal, and consider rsize/wsize tuning on the client side along with jumbo frames on a dedicated storage network. Verify actual I/O with a real workload rather than trusting a single dd run — NFS performance varies enormously with access pattern.

Operational Notes

• Keep sync and root_squash on any shared export.
• Set a consistent NFSv4 domain on server and clients, or ownership mapping breaks.
• NFSv4 needs only TCP 2049; this is the single biggest operational advantage over v3.
• Verify with exportfs -v rather than reading the exports file, and test the mount from a real client.
• Never use no_root_squash on an export writable by untrusted clients.

Related reading: our NetApp ONTAP NFS export policy configuration guide, the Linux multipath configuration guide, and the SELinux denial troubleshooting with audit2allow article.

原文链接：https://docs.kernel.org/filesystems/nfs/nfsroot.html