You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: user_ldap: getDomainDNFromDN() includes count element from ldap_explode_dn(), producing invalid DN passed to ldap_read() #61446
When files:scan (or any code path that resolves a user's primary group via getSID()) is executed for an LDAP/AD user, a PHP warning is emitted:
Error during scan: ldap_read(): Search: Invalid DN syntax
The error is cosmetic (it doesn't break authentication or file access), but it registers as an error in occ files:scan output and pollutes logs.
Root cause
getDomainDNFromDN() in apps/user_ldap/lib/Access.php calls ldap_explode_dn($dn, 0), which returns an array that includes a 'count' key with an integer value (e.g. 4). The foreach loop does not skip non-string elements, so after finding the first dc= component, the integer 4 is appended to $domainParts:
Hit this same root cause independently via a different entry point: occ files:scan on a user identified by UUID (post-ownCloud migration), reached through DefaultShareProvider::_getSharedWith() → Group\Manager::getUserGroupIds() rather than login. Confirmed via logging that $domainDN in getSID() comes back as dc=,dc=, where N matches the DN's component count — same ldap_explode_dn() count-key issue described above. Can confirm the fix works locally (patched getDomainDNFromDN() to strip the count key before the loop).
Activity
joshtrichards commentedon Jun 20, 2026
Thanks for reporting. Fix available for testing in #61479.
arshidkv12 commentedon Jun 30, 2026
Please check it php/php-src#22519
wslauson commentedon Jul 22, 2026
Hit this same root cause independently via a different entry point: occ files:scan on a user identified by UUID (post-ownCloud migration), reached through DefaultShareProvider::_getSharedWith() → Group\Manager::getUserGroupIds() rather than login. Confirmed via logging that $domainDN in getSID() comes back as dc=,dc=, where N matches the DN's component count — same ldap_explode_dn() count-key issue described above. Can confirm the fix works locally (patched getDomainDNFromDN() to strip the count key before the loop).