Samba and NFSv4 Disagree on AD User IDs
A media company stores project data on files01, a Samba 4.20 AD member server that also exports /srv/media over NFSv4 to Linux render nodes. Windows clients use Samba; Linux nodes mount files01:/srv/media. The AD domain is MEDIA.EXAMPLE.COM; users have RFC2307 uidNumber/gidNumber. Samba on files01 uses winbind with idmap config MEDIA : backend = rid, range = 20000-29999, and idmap config * : range = 3000-7999. The render nodes use SSSD with ldap_id_mapping = False, so MEDIA\mlee resolves to UID 7104 from AD. NFSv4 idmapd on files01 has Domain = media.example.com. Files created through Samba by mlee show UID 27104 on the render nodes and are owned by nobody. Files created on a render node show UID 7104 on files01, but Samba users get access denied when editing them. wbinfo -i MEDIA\mlee on files01 returns 27104. The share must remain usable from both protocols without changing application data ownership.
1. Diagnose the identity mismatch and explain the roles of winbind, SSSD, and NFSv4 idmapd.
Read the worked answer
Samba authorizes through winbind, which uses the RID backend: the SID for MEDIA\mlee is converted to 20000 plus the RID, here 27104, inside the MEDIA range. SSSD on the render nodes is configured for RFC2307 and resolves the same user to uidNumber 7104. Those are two different POSIX identities for one SID. NFSv4 normally carries user@domain names and lets idmapd translate them through NSS, but if idmapd is not translating correctly or is bypassed, numeric IDs leak across the export. Samba-created files are then 27104, which SSSD nodes cannot map; render-node files are 7104, which winbind maps to a different or unknown user, so Samba denies access. Authentication is unaffected because Kerberos uses the SID and principal, not the UID.
2. Which identity strategy should be standardized, and what configuration changes are needed on files01 and the NFS side?
Read the worked answer
Standardize on RFC2307 IDs because AD already has uidNumber/gidNumber and SSSD is using them. On files01, change winbind to idmap config MEDIA : backend = ad, idmap config MEDIA : schema_mode = rfc2307, and a range that covers 7104, for example 5000-999999, with idmap config * : range = 3000-4999. Ensure LDAP access to the RFC2307 attributes works, using ldap ssl = start tls if required. Restart winbind, run net cache flush, and verify wbinfo -i MEDIA\mlee returns 7104. Confirm NFSv4 idmapd uses Domain = media.example.com and that nfsidmap -c clears its cache. If RFC2307 attributes are incomplete, the alternative is to make SSSD use the same RID algorithm and ranges, but that is usually harder to keep aligned across NFS clients. Do not leave one protocol on RID and the other on RFC2307.
3. How would you migrate existing ownership and verify that both SMB and NFS clients now see consistent identities?
Read the worked answer
Stop writes to /srv/media, back up, and build an explicit old-to-new UID/GID map from AD: 27104 to 7104 for mlee, and similarly for every affected user and group. Apply chown and fix POSIX ACLs; do not blindly chown everything to one user. Clear Samba and NFS idmap caches, restart winbind and nfs-idmapd, and mount NFSv4 from a render node. Verify with wbinfo -i MEDIA\mlee, getent passwd mlee, id mlee, and stat a file created via Samba and one created via NFS. Test edit and delete from both a Windows SMB client and a Linux NFS client. Check nfsidmap -l and Samba logs for nobody or ACCESS_DENIED. Keep the AD uidNumber/gidNumber attributes under change control so the two protocols cannot drift again.