Resolving NFS Permission Denied Errors: Proper User/Group Mapping and Export Configuration


3 views

When mounting NFS shares between Unix-like systems, permission problems typically stem from user/group ID mismatches. Even when usernames match (like 'darren' in your case), the underlying UID/GID numbers might differ between systems.

First, verify your /etc/exports file contains proper permission flags:

# Example export with proper permissions
/home/darren/share 192.168.1.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1000,anongid=1000)

Key parameters:

  • rw: Read-write access
  • sync: Write operations complete when data is on disk
  • no_subtree_check: Improves reliability
  • all_squash: Maps all users to anonymous
  • anonuid/anongid: Specifies which UID/GID to use

Check and align user IDs:

# On server:
id darren
# On client (Mac):
id darren

If UIDs differ, either:

  1. Modify user IDs to match using usermod
  2. Use anonuid/anongid in exports to force mapping
  3. Configure NFS ID mapping (more complex)

MacOS handles NFS differently than Linux. Try mounting manually to see detailed errors:

sudo mount -t nfs -o resvport,nolocks,locallocks server:/path/to/share /mnt/point

Key Mac mount options:

  • resvport: Uses privileged port (required on newer MacOS)
  • nolocks: Disables file locking
  • locallocks: Handles locks locally
# Check NFS exports
showmount -e server-ip

# Verify server permissions
ls -ld /exported/path

# Check Mac mount options
mount | grep nfs

# Examine NFS server logs (typically /var/log/messages)

If UID/GID alignment isn't feasible:

# 1. Use root_squash with sudo access
/home/darren/share *(rw,sync,root_squash)

# 2. Set world-readable permissions temporarily
chmod -R 755 /exported/path
chown -R nobody:nogroup /exported/path

When working with NFS (Network File System), permission problems often stem from mismatched UID/GID mappings between client and server. Even if usernames appear identical (darren in your case), the underlying numeric IDs might differ across systems.

First verify the exact permissions on your server's exported directory:

# On the NFS server
ls -ld /path/to/export
stat /path/to/export

# Output should show UID/GID numbers, not just names

Your /etc/exports file needs proper options. For your case with user darren:

/path/to/export client.ip(rw,sync,no_subtree_check,all_squash,anonuid=1000,anongid=1000)

Replace 1000 with the actual UID/GID of darren from id darren output.

macOS handles NFS mounts differently. When mounting, specify the correct options:

mount -o resvport,nfsvers=3,rsize=8192,wsize=8192 server:/path/to/export /local/mountpoint

For consistent access, implement one of these approaches:

  1. Force UID/GID alignment: Set identical numeric IDs on both systems
  2. Use NFS ID mapping: Configure /etc/idmapd.conf on both ends
  3. Anonymous access: With careful permission setting (least secure)

These commands help diagnose NFS issues:

# Show active exports
showmount -e server

# Check NFS status
nfsstat -m

# View mount details
mount | grep nfs

# Test raw NFS access
rpcinfo -p server

Here's a complete working example for a development environment:

# Server /etc/exports
/var/devprojects 192.168.1.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1001,anongid=1001)

# Client /etc/fstab entry
devserver:/var/devprojects  /mnt/devprojects  nfs  rw,hard,intr,rsize=8192,wsize=8192  0  0

# Permission synchronization
chown -R 1001:1001 /var/devprojects

Don't forget these potential blockers:

# For SELinux (RHEL/CentOS)
setsebool -P nfs_export_all_rw 1

# Firewall rules
firewall-cmd --add-service=nfs --permanent
firewall-cmd --reload