How to troubleshoot NFS ID mapping

Wrong ownership on an NFS mount usually means the client can reach the export but cannot translate the file owner into the expected local account. The symptom appears as nobody, nogroup, or numeric UID and GID values on files that should belong to a known project user.

On NFSv4, owner and group attributes are translated through user@domain names, local account lookup, and the host's NFSv4 mapping domain. Recent Linux clients call nfsidmap through request-key and cache results in the kernel keyring, while server-side name translation can still involve rpc.idmapd.

Work from the affected mounted path before changing shared data. Separate the live protocol version, numeric owner, account lookup, domain agreement, and stale keyring cache; changing ownership on the export can hide identity trouble and affect every client using the share.

Steps to troubleshoot NFS ID mapping:

Reproduce the wrong ownership on the affected client.
```
$ ls -l /mnt/projects/report.txt
-rw-r--r-- 1 nobody nogroup 42 Jul  5 09:15 /mnt/projects/report.txt
```
Use the same mounted path, account, and client that showed the bad owner. If the failure is a denied write rather than a displayed owner, check export permissions first.
Related: How to troubleshoot NFS permission denied errors
Print the numeric owner and group for the same file.
```
$ ls -ln /mnt/projects/report.txt
-rw-r--r-- 1 1001 2000 42 Jul  5 09:15 /mnt/projects/report.txt
```
Expected numeric IDs with bad names point toward client name lookup, NFSv4 domain mapping, or cached idmap results. Unexpected numeric IDs point toward server-side ownership, anonymous squashing, or a different exported path.
Identify the live NFS mount version and security flavor.
```
$ findmnt --target /mnt/projects --types nfs,nfs4 --output TARGET,SOURCE,FSTYPE,OPTIONS
TARGET        SOURCE                              FSTYPE OPTIONS
/mnt/projects files.example.net:/srv/nfs/projects nfs4   rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,proto=tcp,sec=sys
```
If the mount uses NFSv3, or if the only problem is a numeric UID/GID mismatch under sec=sys, /etc/idmapd.conf will not make unrelated IDs match. Fix the account namespace, directory service, or export mapping policy instead.
Related: How to check the NFS version for a mounted export
Compare the server-side numeric owner for the exported file.
```
$ sudo ls -ln /srv/nfs/projects/report.txt
-rw-r--r-- 1 1001 2000 42 Jul  5 09:15 /srv/nfs/projects/report.txt
```
Run this on files.example.net. Matching numeric IDs confirm that the client sees the same owner and group as the exported file; different IDs mean the server path or export policy needs attention before cache changes.
Related: How to list NFS exports on a server
Check that the client can resolve the file owner UID.
```
$ getent passwd 1001
appuser:x:1001:2000::/home/appuser:/bin/sh
```
If no row appears, add or repair the account through the normal identity source for the host, such as local users, LDAP, Active Directory, or another NSS source. Do not change shared file ownership just to hide a missing account lookup.
Check that the client can resolve the file group GID.
```
$ getent group 2000
projectusers:x:2000:
```
The group name must resolve on the client that displays the file. A server-side group name is not enough when the affected client cannot map GID 2000 to projectusers.
Check the client's effective NFSv4 domain.
```
$ sudo nfsidmap -d
localdomain
```
nfsidmap -d prints the domain used for NFSv4 name mapping on the local host. A default such as localdomain is often wrong when several hosts share one identity namespace.
Check the server's effective NFSv4 domain.
```
$ sudo nfsidmap -d
example.net
```
The client and server must use the same NFSv4 mapping domain when name mapping is in use. A mismatch can leave ownership displayed as nobody even when the numeric owner is the expected one.
Set the shared NFSv4 domain on the host with the wrong value.
```
$ sudoedit /etc/idmapd.conf
```
```
[General]
Domain = example.net
```
Use the domain chosen for the shared identity namespace, not an individual host name. Apply the same value to each NFSv4 client and server that relies on name mapping.
Restart the server-side idmapper when the server domain changed.
```
$ sudo systemctl restart nfs-idmapd.service
```
Recent Linux clients usually use nfsidmap through the kernel keyring path rather than a long-running client daemon. Restart the distribution-equivalent NFS idmapper service only on a server whose /etc/idmapd.conf changed.
Clear stale NFSv4 idmap cache entries on the affected client.
```
$ sudo nfsidmap -c
```
The command normally prints no output. It clears cached idmap keys so the next lookup uses the corrected account and domain settings.
Unmount the affected client mount during a safe window.
```
$ sudo umount /mnt/projects
```
Unmounting a busy share can interrupt applications using that path. Stop the affected workload first or schedule the remount for a quiet period.
Mount the export again from the existing client configuration.
```
$ sudo mount /mnt/projects
```
If the export is not saved in /etc/fstab or an automount map, repeat the original manual mount command instead.
Related: How to mount an NFS export on Linux
Retest the original file ownership from the client.
```
$ stat -c '%U %G %u %g' /mnt/projects/report.txt
appuser projectusers 1001 2000
```
The owner and group names should match the client account database while the numeric UID and GID stay tied to the shared identity namespace.

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.