NFS access denied by server while mounting has 6 common causes. The right answer is to check /etc/exports on the server, the NFS version, the firewall, root_squash, the UID/GID mapping, and the NFSv4 domain. The team that walks through this list in order has the fix in under five minutes.
Table of contents
- Cause 1: client not in /etc/exports
- Cause 2: NFS version mismatch
- Cause 3: firewall
- Cause 4: root_squash
- Cause 5: UID/GID mismatch
- Cause 6: NFSv4 domain mismatch
- FAQ
Cause 1: client not in /etc/exports
The right answer is to check the server’s /etc/exports:
cat /etc/exportsThe right format is /path client(options). If the client’s IP is not in the list, the right fix is to add it and exportfs -a.
Cause 2: NFS version mismatch
The right answer is to check the supported versions on the server. The right way to force a version on the client:
mount -t nfs -o vers=3 server:/path /mnt
mount -t nfs -o vers=4.0 server:/path /mnt
mount -t nfs -o vers=4.1 server:/path /mnt
mount -t nfs -o vers=4.2 server:/path /mntThe right answer is to find the version the server supports.
Cause 3: firewall
The right answer is to open port 2049 in the server firewall. For NFSv3, also open 111 (rpcbind), 20048 (mountd), and the dynamic ports for statd and lockd. The right answer for NFSv4 only is to open 2049 and disable the auxiliary services.
Cause 4: root_squash
The default is root_squash, which maps the client’s root user to nobody on the server. The right answer is to set no_root_squash in /etc/exports if the client needs to write as root, but the right answer for security is to use a non-root user on the client.
Cause 5: UID/GID mismatch
The right answer is to use the same UID/GID on the client and server. The wrong answer is to assume the username maps to the same UID. NFS uses UID, not username.
Cause 6: NFSv4 domain mismatch
The right answer is to set the same Domain in /etc/idmapd.conf on both client and server. The right answer is the same domain string on both.
FAQ
What is the right order to debug?
- Check /etc/exports. 2. Check the NFS version. 3. Check the firewall. 4. Check root_squash. 5. Check UID/GID. 6. Check the NFSv4 domain.
How do I see why the server rejected the mount?
sudo journalctl -u nfs-server on the server. The log shows the exact reason.
What is the right NFS version?
NFSv4.2 for modern workloads. NFSv3 for legacy clients.
What is root_squash?
Maps the client’s root user to nobody on the server. The right answer is to leave it on unless the client needs to write as root.
How do I match UIDs across systems?
The right answer is to set the same UID on both client and server, or to use NFSv4 with idmapd for username mapping.
What is the NFSv4 domain?
A string in /etc/idmapd.conf that maps user@domain to a UID. The right answer is the same string on both client and server.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: