How to Fix NFS Mount Permission Denied and Connection Refused

Updated: 12 October 2026 · Applies to: nfs-utils 2.8.3 with Linux 6.12 (Debian 13, tested in a lab virtual machine) and nfs-utils 2.8.3 with firewalld 2.4.3 on AlmaLinux 10.2 (packages and firewall services checked), Ubuntu 26.04 (nfs-utils 2.8.5) and 24.04 (nfs-utils 2.6.4) service names checked; the same on Rocky Linux and RHEL 9 and 10, NFS versions 3, 4.1 and 4.2

"Permission denied" while mounting NFS almost always means the server refused this client: the mount ends with mount.nfs: access denied by server while mounting, and the mount -v output also shows mount.nfs: mount(2): Permission denied. Fix it on the server: allow the client's address in /etc/exports (with no space before the bracket) and run sudo exportfs -ra. "Connection refused" means nothing answers on the NFS port, so start the server with sudo systemctl enable --now nfs-server. If the mount works but you get "Permission denied" on files, the cause is root_squash or different user IDs (section 6).

All output below is real and comes from our lab, where client and server were the same machine (address 127.0.0.1).

1. Read the reason on the server

1. On the NFS server, follow the log:

   sudo journalctl -f -u nfs-server -u nfs-mountd

2. On the client, mount with details:

   sudo mount -v -t nfs 203.0.113.20:/srv/share /mnt/share

3. Match the server message: unmatched host (section 2), illegal port (section 3), not exported (section 4).

In our test, mountd logged refusals only for NFSv3 requests. If the log stays empty, try once with -o nfsvers=3; mountd then printed, for example: rpc.mountd: refused mount request from 127.0.0.1 for /srv/share (/srv/share): unmatched host.

2. The client is not in the export list

1. On the server, show what is exported and to whom:

   $ sudo exportfs -v
   /srv/share    	192.0.2.50(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)

   Here only 192.0.2.50 may mount, so our client got access denied by server with NFS 4.2 and with NFS 3.
2. Edit /etc/exports and allow the address the server actually sees (behind NAT this is the public address). Host names work only if the server can resolve them.

   /srv/share  203.0.113.30(rw,sync,no_subtree_check)
   /srv/share  192.168.10.0/24(rw,sync,no_subtree_check)

3. Reload the exports with sudo exportfs -ra and mount again.

Watch for a space between the address and the bracket. The exports manual says no whitespace is permitted there. With /srv/share 127.0.0.1 (rw,sync,no_subtree_check) our server warned and exported the share read-only to the client and read-write to everyone:

$ sudo exportfs -ra
exportfs: No options for /srv/share 127.0.0.1: suggest 127.0.0.1(sync) to avoid warning
exportfs: No host name given with /srv/share (rw,sync,no_subtree_check), suggest *(rw,sync,no_subtree_check) to avoid warning
$ sudo exportfs -v
/srv/share    	127.0.0.1(sync,wdelay,hide,no_subtree_check,sec=sys,ro,secure,root_squash,no_all_squash)
/srv/share    	<world>(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)

3. The client uses a port above 1023 (illegal port)

Exports are secure by default: according to the exports manual, requests must come from a port below 1024. A client mounted with noresvport, or a NAT device that changes the source port, breaks that rule. In our test NFS 3 answered access denied by server (mountd logged illegal port 55715) and NFS 4.2 answered mount.nfs: Operation not permitted. Add insecure for that client only, then run sudo exportfs -ra; the same NFS 3 mount then worked:

/srv/share  203.0.113.30(rw,sync,no_subtree_check,insecure)

4. The path is not exported or does not exist

• A path that is not exported gave mount.nfs: mounting 127.0.0.1:/srv/nothere failed, reason given by server: No such file or directory with NFS 4.2, and access denied by server with NFS 3 (mountd: not exported). Mount exactly the exported path.
• List the exports from the client with showmount -e 203.0.113.20. It needs rpcbind and mountd on the server; with rpcbind stopped it answered clnt_create: RPC: Unable to receive, so an NFSv4-only server may not answer it.
• The folder must exist when the exports are loaded: exportfs: Failed to stat /srv/missing: No such file or directory.
• If the server uses fsid=0 (an NFSv4 root), NFSv4 clients mount paths relative to it: an export of /srv with fsid=0 is mounted as 203.0.113.20:/.

5. mount.nfs: Connection refused

With the NFS server stopped, a mount with default options waited about two minutes (the nfs manual gives 2 minutes as the default retry for normal mounts) and then failed:

$ sudo mount -t nfs 127.0.0.1:/srv/share /mnt/share
mount.nfs: Connection refused for 127.0.0.1:/srv/share on /mnt/share

1. Start the server and keep it enabled (the service is nfs-server on every distribution; on Debian and Ubuntu nfs-kernel-server is another name for it):

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

2. For NFS 3, rpcbind must run too: sudo systemctl enable --now rpcbind. With rpcbind running but no NFS service, an NFS 3 mount said requested NFS version or transport protocol is not supported; with rpcbind stopped as well, Connection refused.
3. Add -o retry=0 while testing to get the error at once instead of after two minutes.

A firewall that silently drops packets makes the mount hang until it times out rather than refuse it. NFSv4 needs TCP port 2049 only (firewalld's nfs service). NFS 3 also needs rpc-bind (111) and mountd (20048 on AlmaLinux and Rocky Linux), and Red Hat's guide adds fixed ports for statd and lockd. Allow only your clients, for example:

sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=203.0.113.30 service name=nfs accept'
sudo firewall-cmd --reload
sudo ufw allow from 203.0.113.30 to any port 2049 proto tcp     # Ubuntu with UFW

6. Mounted, but Permission denied on files

# touch /mnt/share/root-file
touch: cannot touch '/mnt/share/root-file': Permission denied
# ls -ldn /mnt/share
drwxr-xr-x 4 1000 1000 1024 Oct 11 18:04 /mnt/share

• root_squash (the default) maps root on the client to the anonymous user 65534, so root cannot write to folders owned by other users. A file that root created in a world-writable folder was owned by 65534.
• User IDs: with the default sec=sys, NFS compares numbers, not names. The user with UID 1000 (the owner) could write; a user with UID 1001 got Permission denied. Give users the same UID on client and server (id alice on both), or change the ownership on the server.
• no_root_squash lets client root write as root (our test file was then owned by 0). Use it only for trusted clients such as a backup server. For a shared upload folder, all_squash with anonuid= and anongid= maps every user to one account.

7. Other messages

• mount.nfs: failed to apply fstab options: a normal user ran the mount. Use sudo.
• Version mismatch: cat /proc/fs/nfsd/versions on the server showed +3 +4 +4.1 +4.2; ask for a version with -o nfsvers=4.2 or -o nfsvers=3.
• Kerberos: if the export has sec=krb5, krb5i or krb5p, the client must mount with the same sec= option and have a working Kerberos setup.

To set up a share from scratch, see the beginners guide to NFS; to mount it at boot or on demand, see automounting with autofs and systemd.

Official documentation: exports manual, nfs manual and Deploying an NFS server (Red Hat).