Description: In a big customerenvironment on some school replicas fileshare listing and therefor fileshare access was no longer possible after upgrade to 5.2(-2) The log.smbd shows this messages, whe someone trys to list \\ucs-replica in the windows explorer. [2025/07/02 14:53:51.780825, 0, pid=1137277] ../../source4/auth/unix_token.c:123(security_token_to_unix_token) Unable to convert SID (S-1-5-21-0-0-0-497) at index 4 in user token to a GID. Conversion was returned as type 0, full token: [2025/07/02 14:53:51.780877, 0, pid=1137277] ../../libcli/security/security_token.c:133(security_token_debug) Security token SIDs (10): SID[ 0]: S-1-5-21-2258795110-56359529-1961293181-73274 SID[ 1]: S-1-5-21-2258795110-56359529-1961293181-515 SID[ 2]: S-1-5-21-2258795110-56359529-1961293181-11243 SID[ 3]: S-1-18-1 SID[ 4]: S-1-5-21-0-0-0-497 SID[ 5]: S-1-1-0 SID[ 6]: S-1-5-2 SID[ 7]: S-1-5-11 SID[ 8]: S-1-5-32-554 SID[ 9]: S-1-5-32-545 So this mysterious SID seems to be a claims_valid SID. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab So since 4.21-1 (or 4-20) samba seems to strictly validate all SIDs found in Security token. This one cannot be looked up by windows and the access is completely not possible. Workaround: Add the missing entry in the idmap.ldb like this: root@ucs-replica:~# cat > 497.ldif dn: CN=S-1-5-21-0-0-0-497 cn: S-1-5-21-0-0-0-497 objectClass: sidMap objectSid: S-1-5-21-0-0-0-497 type: ID_TYPE_BOTH xidNumber: 3000577 distinguishedName: CN=S-1-5-21-0-0-0-497 ^C root@ucs-replica:~# ldbadd -H /var/lib/samba/private/idmap.ldb 497.ldif Added 1 records successfully root@ucs-replica:~# net cache flush root@ucs-replica:~# /etc/init.d/winbind restart Interesting: This was not a problem on all servers but on 5 out of 85. The other server already had this entry in the idmap.ldb
S-1-5-21-0-0-0-497 is already in Samba for a long time (git history says about 4.16 ?) > Unable to convert SID (S-1-5-21-0-0-0-497) at index 4 in user token to a GID I'd guess it needs to be added "somehow" to OpenLDAP, so that it a GID or UID is assigned. When I look into the joinscript of univention-samba4 I see a function _create_group_with_special_sid, so that may be a recipe to follow to solve this.
Knowledge Base Article: https://help.univention.com/t/problem-unable-to-access-file-shares-on-certain-ucs-replica-servers-after-upgrade-to-5-2-2/24463