How to Fix mount.nfs: access denied by server while mounting

Updated: 28 September 2026 · Applies to: nfs-utils 2.5 to 2.8 on AlmaLinux and Rocky Linux 9 and 10, RHEL 9 and 10, Ubuntu 24.04 and 26.04, Debian 13 (NFS versions 3, 4.1 and 4.2)

The error below means the NFS server received the mount request and refused it:

mount.nfs: access denied by server while mounting 203.0.113.20:/srv/share

The server decides this from its export list (/etc/exports), so most fixes are made on the server. The quickest way to find the reason is the server's own log.

1. Read the reason on the server

1. On the NFS server, watch the log while you retry the mount from the client:

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

2. On the client, mount with details:

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

3. Match the server message to the fixes below: unmatched host (fix 2), illegal port (fix 3), not exported (fix 4).

2. The client is not in the export list

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

   exportfs -v

2. Edit /etc/exports so the client's address is allowed. Use the address the server actually sees (behind NAT this is the public address):

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

   There must be no space between the address and the bracket: host (rw) with a space gives read-write access to everyone and read-only to that host. If you use host names, the server must be able to resolve them.
3. Reload the exports: exportfs -ra

3. The client connects from an unprivileged port

By default the server only accepts requests from ports below 1024. Some clients use higher ports, for example macOS, or mounts through NAT. Add insecure to that client's options, then run exportfs -ra:

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

4. The path does not match the export

• Mount exactly the exported path. List the exports from the client with showmount -e 203.0.113.20. This needs NFSv3 services; a server that only runs NFSv4 may not answer it.
• If the export 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:/.
• The folder must exist on the server when the export is loaded.

5. NFS version or security mismatch

• See which versions the server offers: cat /proc/fs/nfsd/versions on the server (for example -2 +3 +4 +4.1 +4.2).
• Ask for a version explicitly on the client: mount -t nfs -o nfsvers=4.2 ... or -o nfsvers=3. Current servers no longer offer NFSv2.
• If the export requires Kerberos (sec=krb5, krb5i or krb5p), the client must mount with the same sec= option and have a valid Kerberos setup.

6. Firewall

A blocked port usually causes a timeout rather than "access denied", but check it while you are there. NFSv4 needs TCP port 2049 only. NFSv3 also needs rpcbind (port 111) and mountd:

firewall-cmd --permanent --add-service=nfs --add-service=mountd --add-service=rpc-bind
firewall-cmd --reload

Allow these only from your client addresses, never from the whole internet.

Mounted, but "Permission denied" on files

That is a different problem. By default the server maps the client's root user to nobody (root_squash), so root on the client cannot write to folders owned by other users. Give the folder suitable ownership on the server, or match user IDs between client and server. Use no_root_squash only for trusted clients, such as a backup server.

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