How to validate NFS export configuration

An NFS export is the boundary between a local server directory and the clients allowed to mount it. A saved line can look right in /etc/exports or a drop-in file and still fail at handoff if the file was ignored, the client selector parsed differently than intended, or the active export table was not rebuilt.

Linux NFS servers read /etc/exports and files ending in .exports under /etc/exports.d. The exportfs command rebuilds the active table from those files, reports parser and path errors during reload, and shows the loaded selector and option set with defaults expanded.

Server-side validation stops before the network and client permission boundary. Finish from a host that should be allowed to mount the export, because firewall rules, protocol-version policy, UID/GID mapping, Kerberos or TLS settings, and filesystem permissions can still block access after exportfs -v shows the intended entry.

Steps to validate NFS export configuration:

Open a shell on the NFS server with an account that can use sudo.
Open the export file that changed.
```
$ sudoedit /etc/exports.d/projects.exports
```
Use /etc/exports for a small server with one shared export file. Use a drop-in under /etc/exports.d when separate files make ownership clearer; exportfs reads only drop-ins whose names end in .exports.
Confirm that the saved export line uses the intended path, client selector, and options.
```
/srv/nfs/projects 192.0.2.0/24(rw,sync,no_subtree_check,root_squash)
```
Keep the client selector directly attached to its option list. 192.0.2.0/24(rw,sync) applies those options to that subnet, while 192.0.2.0/24 (rw,sync) changes how exports(5) parses the rule.
Reload the saved export table with verbose output.
```
$ sudo exportfs -rv
exporting 192.0.2.0/24:/srv/nfs/projects
```
Fix any reported path, selector, or option error before checking clients. A reload warning means the active table may not match the saved file.

Related: How to reload NFS exports
Check the active export table for the loaded selector and options.
```
$ sudo exportfs -v
/srv/nfs/projects
		192.0.2.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash,no_all_squash)
```
exportfs may show defaults such as wdelay, hide, sec=sys, root_squash, and no_all_squash even when the saved file lists only the options that were deliberately set.

Related: How to list NFS exports on a server
Confirm that the NFS server unit is active before client testing.
```
$ sudo systemctl is-active nfs-server
active
```
On many systemd distributions, nfs-server.service is the main server unit. Some Debian and Ubuntu tools also expose nfs-kernel-server as a package or service alias.

Related: How to check NFS server status in Linux
Query the export list from a client that should be allowed.
```
$ showmount --exports files.example.net
Export list for files.example.net:
/srv/nfs/projects 192.0.2.0/24
```
showmount depends on the mount discovery service and may not answer on NFSv4-only servers. If the server is intentionally NFSv4-only, use the server-side exportfs table plus a real mount test for the final proof.

Related: How to list NFS exports from a client
Create an empty client mount point for the test mount.
```
$ sudo mkdir --parents /mnt/projects
```
Files already under /mnt/projects become hidden while the NFS filesystem is mounted there.
Mount the export from the allowed client.
```
$ sudo mount -t nfs -o vers=4.2 files.example.net:/srv/nfs/projects /mnt/projects
```
Omit vers=4.2 when the client should negotiate the newest server-supported version automatically. Use a server-required option such as vers=3 only for older NFSv3 exports.

Related: How to mount an NFS export on Linux

Verify that the client mounted the expected server path.

$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/projects
TARGET        SOURCE                               FSTYPE OPTIONS
/mnt/projects files.example.net:/srv/nfs/projects nfs4   rw,relatime,vers=4.2,proto=tcp,sec=sys

Create a temporary write probe when the export is meant to be writable.
```
$ touch /mnt/projects/.nfs-export-test
```
Run the probe as a user that should be able to write through the export. For a read-only export, list or read an expected file instead of creating a probe.

Related: How to troubleshoot NFS permission denied errors
Remove the temporary probe file.
```
$ rm /mnt/projects/.nfs-export-test
```
Unmount the temporary client test mount.
```
$ sudo umount /mnt/projects
```

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.