NFS UID/GID Mapping: How to Remap User Permissions Across Servers


10 views

When working with NFS (Network File System) across multiple Linux servers, one of the most persistent headaches is UID/GID mismatch. Consider this scenario:

# Server1 user listing:
uid=1001(alice) gid=1001(devteam)

# Server2 user listing:
uid=1050(alice) gid=1050(devteam)

The same human user "alice" exists on both systems but with different numeric identifiers. When Server1 exports a directory via NFS and Server2 mounts it, permission checks fail spectacularly because:

  1. Files owned by UID 1001 on Server1 appear as "nobody" on Server2
  2. User Alice (UID 1050) on Server2 gets "permission denied"

The modern solution is rpc.idmapd, the NFSv4 identity mapping daemon. Here's how to configure it:

# /etc/idmapd.conf
[General]
Verbosity = 1
Domain = yourdomain.com

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = static

For static mappings, create a /etc/idmap-static file:

# Format: server-uid client-uid server-gid client-gid
1001 1050 1001 1050
1002 1051 1002 1051

For older NFSv3 environments, you have two main approaches:

Option 1: UID/GID standardization
Maintain identical /etc/passwd and /etc/group files across all servers using tools like LDAP or Puppet.

Option 2: exportfs with all_squash
Force all access to appear as a single user:

# /etc/exports on Server1
/shared/dir *(rw,all_squash,anonuid=1001,anongid=1001)

Let's implement a complete solution for two users:

# Server1 users:
dev1:1001:1001
dev2:1002:1002

# Server2 needs to map to:
dev1:2001:2001
dev2:2002:2002

# idmapd.conf static rules:
1001 2001 1001 2001
1002 2002 1002 2002

After configuration:

systemctl restart rpc-idmapd
exportfs -rav

Check your mappings with:

nfsidmap -d yourdomain.com -u 1001
nfsidmap -d yourdomain.com -g 1001

Remember that changes may take a few minutes to propagate. Always test with non-critical data first.


When mounting NFS shares between Linux servers with different UID/GID assignments for the same usernames, permission issues inevitably arise. The fundamental problem stems from NFS relying on numeric UIDs/GIDs rather than username mappings during file operations.

Consider this real-world scenario:


# Server A has user 'developer' with:
developer:x:1001:1001::/home/developer:/bin/bash

# Server B has user 'developer' with:
developer:x:2001:2001::/home/developer:/bin/bash

When Server B mounts Server A's NFS export, files owned by UID 1001 will appear as "nobody" or cause access denials.

The most robust solution involves configuring rpc.idmapd on both servers:

  1. Install required packages:
    
    sudo apt-get install nfs-common libnfsidmap2  # Debian/Ubuntu
    sudo yum install nfs-utils libnfsidmap       # RHEL/CentOS
    
  2. Configure /etc/idmapd.conf:
    
    [General]
    Domain = yourdomain.local
    
    [Translation]
    Method = nsswitch
    
  3. Enable and start the service:
    
    sudo systemctl enable rpc-idmapd
    sudo systemctl start rpc-idmapd
    

For temporary solutions or specific mounts, use these NFS mount options:


sudo mount -t nfs server:/path /mnt/nfs -o rw,noatime,anonuid=1001,anongid=1001

This forces all access to use specified UID/GID, but loses per-user granularity.

For larger environments, centralize identity management:


# Example LDAP configuration in /etc/nsswitch.conf:
passwd: files ldap
shadow: files ldap
group:  files ldap

After configuration, verify with:


# Check current mappings:
nfsidmap -d

# Test file operations:
sudo -u developer touch /mnt/nfs/testfile
ls -l /mnt/nfs/testfile

Common issues to check:

  • Firewall blocking rpcbind (port 111)
  • SELinux contexts on exported directories
  • Time synchronization between servers

Always ensure:

  1. Exports use root_squash (default)
  2. Network restrictions in /etc/exports
  3. Regular audits of permission mappings