Facing NFS Error 13? Here’s What Causes Permission Denied

nfs server returned error 13, causing access issues? Our NFS Support team shares how to keep your NFS shares secure and running smoothly.

Facing NFS Error 13? Here’s What Causes Permission Denied

Access to shared files should never slow down your system, yet a single permission mistake can break every connection to an NFS share. The “NFS Error 13 Permission Denied” message is one of the most common and confusing roadblocks in network storage, and it can stop applications, block system boot processes, and lock users out of important data without warning. Understanding why this error happens and how to prevent it is key to keeping NFS environments stable, secure, and accessible.

What Does NFS Error 13 Permission Denied Mean

The NFS error 13 shows a permission denied problem. It appears when a client tries to reach an NFS share without the required access. Wrong file permissions, export rules, or user rights on the server or client side can block the request and trigger this message. When proper access is granted, the client can read or write to the shared files without restrictions.

NFS Error 13 Permission Denied: Key Impacts

• It blocks the client from mounting the shared directory.
• Applications that store or read data from the NFS share may stop working.
• Users lose access to important files stored on the NFS server.
• Systems that depend on NFS during startup may fail to boot.
• Root squash limits the root user on the client, which can cause access issues during admin tasks.
• Changing permissions carelessly to fix this error can open security risks and give unwanted access.

Main causes and how to fix them

• Incorrect export settings and directory permissions

Cause: The exports file or the shared directory restricts the client.

Fix:

1. Open and review the exports file on the server.

sudo nano /etc/exports

2. Ensure the share and client entry look similar to this:

/path/to/share client_ip(rw,sync)

/path/to/share client_ip(rw,sync,no_root_squash)

Use no_root_squash only when the client root user really needs full rights.

3. Apply changes:

sudo exportfs -ra

sudo exportfs -v

4. Check folder ownership and permissions:

ls -ld /path/to/share

sudo chown -R nfsnobody:nfsnobody /path/to/share

sudo chmod -R 755 /path/to/share

ls -ld /path/to/share

• Root squash behavior

Cause: NFS maps the client root user to an anonymous user. That user may not have rights on the share.

Fix:

1. Confirm which user owns the shared path:

ls -l /path/to/share

2. Give that user or group the needed access, or carefully use no_root_squash in the exports entry when root access is required.

• Misconfigured export file

Cause: The export entry syntax or client definition is wrong.

Fix:

1. Edit the exports file:

sudo nano /etc/exports

2. Use a correct line for the exported directory:

/path/to/exported/directory client_ip(rw,sync,no_root_squash)

3. Apply and verify:

sudo exportfs -a

sudo exportfs -v

• Firewall rules blocking NFS traffic

Cause: The firewall on the server or client blocks NFS ports.

Fix:

1. View rules:

sudo iptables -L -n

2. Allow NFS traffic:

sudo iptables -A INPUT -p tcp --dport 2049 -j ACCEPT

sudo iptables -A INPUT -p udp --dport 2049 -j ACCEPT

sudo iptables -A INPUT -p tcp --dport 111 -j ACCEPT

sudo iptables -A INPUT -p udp --dport 111 -j ACCEPT

3. Save rules if your system needs an explicit save:

sudo service iptables save

4. Restart NFS service:

sudo systemctl restart nfs-server

• SELinux policy restrictions

Cause: SELinux blocks access to the exported directory even when NFS and permissions look correct.

Fix:

1. Test with permissive mode:

sudo setenforce 0

If error 13 disappears, SELinux policy is the source.

2. Set a proper context for the share:

sudo semanage fcontext -a -t nfs_t '/path/to/exported/directory(/.*)?'

sudo restorecon -Rv /path/to/exported/directory

3. Return SELinux to enforcing mode:

sudo setenforce 1

• Client using incorrect mount options

Cause: The client mount command uses options that cause access issues.

Fix:

1. Check current NFS mounts:

mount | grep nfs

2. Use a clean mount command:

sudo mount -t nfs server_ip:/path/to/exported/directory /mount/point

3. If needed, add options such as read, write, and safe flags:

sudo mount -o rw,nosuid,noexec server_ip:/path/to/exported/directory /mount/point

• NFS version mismatch 

Cause: The client and server speak different NFS versions in a way that leads to permission problems.

Fix:

1. Check supported NFS services and versions on the server:

rpcinfo -p | grep nfs

2. On the client, mount with an explicit version:

sudo mount -o nfsvers=4 server_ip:/path/to/exported/directory /mount/point

Try another supported version if your setup needs it, such as nfsvers=3.

• User and group ID mismatch

Cause: User IDs and group IDs differ between client and server, so the same username maps to a different numeric ID.

Fix:

1. Check IDs on both systems:

id username

2. Align UIDs and GIDs or use a central directory service such as LDAP so that the same user has the same ID on both sides.

• Network configuration issues

Cause: Network problems stop the client from reaching the NFS server correctly, which can surface as access errors.

Fix:

1. Test connectivity:

ping server_ip

2. Confirm IP and subnet details:

ip addr

ip route

Ensure correct routes exist between client and server or that they share a valid subnet.

Key Prevention Steps

• Configure /etc/exports to allow the right client IP or network range with suitable read or write options.
• Use no_root_squash only if the client’s root user needs full access.
• Keep user and group IDs consistent across both server and client systems, especially when using NFSv4.
• Confirm network reachability and allow NFS ports through firewalls on both ends.
• Ensure proper hostname resolution through DNS or /etc/hosts entries.
• Use the correct NFS mount options and the supported version on both client and server.
• Regularly monitor system logs to detect permission issues early.

[Need assistance with a different issue? Our team is available 24/7.]

Conclusion 

Fixing the nfs server returned error 13 comes down to proper access rules, correct user mapping, and clean network settings. Once these are in place, NFS shares stay secure and fully accessible without interruptions.