When mounting an NFSv4 share between two identical EC2 instances, you might encounter files showing ownership by the numeric UID/GID 4294967294 instead of the expected user/group names. This typically appears as:
drwxr-xr-x 6 4294967294 4294967294 92 2010-01-01 20:21 logs
drwxr-xr-x 2 4294967294 4294967294 20 2009-12-23 01:14 monit.d
The number 4294967294 (2³²-2) appears when there's a mismatch between UID/GID mappings between the NFS server and client. This occurs because:
- NFSv4 uses numeric IDs exclusively (unlike NFSv3 which can use usernames)
- The ID mapping service (idmapd) isn't properly configured or running
- Different user namespace configurations between systems
First, check if idmapd is running on both systems:
systemctl status rpc-idmapd
ps aux | grep idmapd
Then verify UID/GID consistency:
# On both server and client:
cat /etc/passwd | grep your_username
cat /etc/group | grep your_group
Here's how to properly configure NFSv4 ID mapping:
# /etc/idmapd.conf on BOTH server and client
[General]
Domain = yourdomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
Then restart the services:
systemctl restart rpc-idmapd
systemctl restart nfs-client.target
If you don't need user-specific permissions, modify your exports file:
/websites 10.0.0.0/8(fsid=0,no_subtree_check,rw,all_squash,anonuid=65534,anongid=65534)
This maps all accesses to the nobody/nogroup user (typically UID/GID 65534).
Use these commands to troubleshoot:
# Check NFS version being used
nfsstat -m
# View active ID mappings
nfsidmap -l
# Check RPC services
rpcinfo -p
For AWS EC2 instances, add this to your cloud-init configuration:
#cloud-config
bootcmd:
- echo "YOURDOMAIN" > /etc/idmapd.conf
- systemctl enable --now rpc-idmapd
Remember to replace YOURDOMAIN with your actual domain or use the AWS internal domain.
When mounting NFSv4 shares between Linux systems, you might encounter files showing ownership by UID/GID 4294967294 (which equals -2 in signed 32-bit integer). This typically indicates one of several possible scenarios:
// Example of the problematic output
$ ls -l /mnt/nfs_share/
drwxr-xr-x 2 4294967294 4294967294 4096 Jan 1 10:00 data
The primary reasons for this behavior include:
- Missing idmapd configuration on client or server
- Incorrect domain setting in idmapd.conf
- UID/GID namespace mismatch between systems
- Kerberos authentication issues (when used)
Here's what you need to verify on both client and server:
# On both systems:
$ cat /etc/idmapd.conf | grep Domain
Domain = yourdomain.local
# Verify NFS versions supported
$ cat /proc/fs/nfsd/versions
-2 +3 +4 +4.1 +4.2
Follow these steps to properly configure NFSv4 with correct UID/GID mapping:
# 1. Edit /etc/idmapd.conf on both client and server
[General]
Domain = yourdomain.local
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
# 2. Restart services
$ systemctl restart rpcidmapd
$ systemctl restart nfs-server # on server
$ systemctl restart nfs-client # on client
# 3. Remount with proper options
$ umount /websites
$ mount -t nfs4 -o rw,vers=4.2,async,_netdev master-server:/ /websites
If you don't need individual user mappings, this approach works well:
# Server's /etc/exports:
/websites 10.0.0.0/8(rw,all_squash,anonuid=1000,anongid=1000)
# Client mount command:
mount -t nfs4 -o rw,vers=4.2 master-server:/ /websites
After implementing changes, verify the mapping works:
# Create test file and check ownership
$ touch /websites/testfile
$ ls -n /websites/testfile
-rw-r--r-- 1 1000 1000 0 Jan 1 12:00 testfile
# Check idmap status
$ nfsidmap -d yourdomain.local
- Ensure identical time synchronization (NTP)
- Verify network connectivity between client/server
- Check firewall rules for NFS ports (2049)
- Confirm matching domain names in idmapd.conf
For environments requiring security:
# Server exports entry:
/websites 10.0.0.0/8(rw,sec=krb5p)
# Client mount options:
mount -t nfs4 -o rw,sec=krb5p,vers=4.2 server:/ /mnt