After successfully configuring LDAP authentication on CentOS 6 clients mounting NFS shares (/home and /opt), all files appear owned by nobody:nobody (UID/GID 99) despite proper user mapping through SSSD. The id command shows correct credentials:

$ id
uid=3000(myusername) gid=3000(employees) groups=3000(employees)

The issue typically stems from NFS and LDAP UID/GID mapping inconsistencies. Let's examine critical components:

NFS Server Configuration

On your NFS server (storage1), verify these settings in /etc/exports:

/nas/home *(rw,sync,no_subtree_check,all_squash,anonuid=3000,anongid=3000)
/nas/opt *(rw,sync,no_subtree_check,all_squash,anonuid=3000,anongid=3000)

The all_squash option forces all accesses to be mapped to anonymous users. Either remove it or ensure anonuid/anongid match your LDAP users.

Client-Side NFS Mount Options

Modify your /etc/fstab entries with proper NFS version and security flags:

storage1:/nas/home  /home  nfs  rw,vers=3,sec=sys,hard,intr,rsize=8192,wsize=8192 0 0
storage1:/nas/opt  /opt  nfs  rw,vers=3,sec=sys,hard,intr,rsize=8192,wsize=8192 0 0

Your sssd.conf needs these critical additions for proper ID mapping:

[domain/default]
ldap_id_mapping = True
ldap_user_objectsid = msSFU30Sid
ldap_group_objectsid = msSFU30Sid
ldap_user_uuid = msSFU30UidNumber
ldap_group_uuid = msSFU30GidNumber

Enable and configure rpcidmapd:

# yum install nfs-utils-lib
# service rpcidmapd start
# chkconfig rpcidmapd on

Configure /etc/idmapd.conf:

[General]
Domain = mycompany.com
Local-Realms = EXAMPLE.COM,MYCOMPANY.COM

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

After making changes, test with:

# idmapd -vvv -f
# getent passwd myusername
# mount -o remount /home
# ls -l /home/myusername

The complete workflow should show proper UID/GID mapping through the entire chain: LDAP → SSSD → NFS → local filesystem.

---

When mounting NFS shares on a CentOS 6 client with LDAP authentication, you might encounter files showing ownership as nobody:nobody (UID/GID 99) despite successful authentication. This typically indicates a UID/GID mapping issue between the NFS server and client.

First confirm these critical points:

# Check user mapping
$ id
uid=3000(myusername) gid=3000(employees) groups=3000(employees)

# Verify NFS mounts
$ mount | grep nfs
storage1:/nas/home on /home type nfs (rw,soft,intr,rsize=8192,wsize=8192)
storage1:/nas/opt on /opt type nfs (rw,soft,intr,rsize=8192,wsize=8192)

The root cause often lies in these server-side NFS export settings:

# Example of problematic export (on NFS server)
/nas/home *(rw,sync,no_root_squash)
/nas/opt *(rw,sync)

The missing no_root_squash option for /nas/opt causes the UID mapping issue. Update your exports file:

# Corrected /etc/exports configuration
/nas/home *(rw,sync,no_root_squash,no_subtree_check)
/nas/opt *(rw,sync,no_root_squash,no_subtree_check)

Then apply changes:

exportfs -ra

Adjust your fstab entries with these recommended options:

# /etc/fstab modifications
storage1:/nas/home  /home  nfs  rw,soft,intr,rsize=8192,wsize=8192,noatime,nodiratime,proto=tcp,vers=3 0 0
storage1:/nas/opt  /opt  nfs  rw,soft,intr,rsize=8192,wsize=8192,noatime,nodiratime,proto=tcp,vers=3 0 0

Ensure your SSSD configuration properly handles UID/GID mapping:

# /etc/sssd/sssd.conf additions
[domain/default]
ldap_id_mapping = True
ldap_user_objectsid = none
ldap_group_objectsid = none

After making these changes:

# Restart services
service sssd restart
service nfs restart

# Test with new file creation
touch /home/testfile
ls -l /home/testfile
# Should show correct UID/GID now

If issues persist, enable NFS debugging:

# On client
rpcdebug -m nfs -s all
# Check logs
tail -f /var/log/messages