⚠️ This issue respects the following points: ⚠️
Bug description
After upgrading from Nextcloud 34 to 35.0.0, LDAP-backed accounts whose internal
UID is a UUID (while the login name is the AD samaccountname) can no longer
authenticate against /ocs/v2.php/cloud/capabilities. The server logs
App token login name does not match followed by Login failed.
This configuration has been running without problems for about a year on NC 32–34.
The failures started immediately after the upgrade to 35.
Two things make this different from the previously reported occurrences of this
message (#45216, #51928, #6783), where the mismatch was logged but synchronisation
kept working:
- The login now actually fails instead of just emitting a log entry.
- The repeated failures are counted by
password_policy, which then disables
the account ("Too many consecutive failed login attempts, disabling user").
The disabled account causes Sabre\DAV\Exception\ServiceUnavailable (HTTP 503)
on WebDAV, which clients display to the user as "server is in maintenance mode".
Removing the account on the device and setting it up from scratch does not help —
a freshly created token shows the same mismatch on its first request. Deleting all
auth tokens for the user (verified: oc_authtoken empty for that UID) and flushing
APCu/Redis does not help either.
remote.php/dav requests authenticate successfully; only /ocs/v2.php/cloud/capabilities
fails. This seems to narrow down the affected code path.
Steps to reproduce
- Configure
user_ldap against Active Directory with ldapExpertUsernameAttr empty, so the internal UID becomes the AD objectGUID (a UUID) while users log in with
their samaccountname.
- Run this on Nextcloud 34 — everything works.
- Upgrade to 35.0.0.
- Log in from the Nextcloud Android app using the
samaccountname.
- Watch
nextcloud.log.
Expected behavior
The token is accepted and /ocs/v2.php/cloud/capabilities returns 200, as it did on 34.
Nextcloud Server version
35
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.3
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 31 to 32)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{
"system": {
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"localhost",
"192.168.0.18",
"nextcloud.mydomain.de"
],
"trusted_proxies": "***REMOVED SENSITIVE VALUE***",
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "35.0.0.10",
"overwriteprotocol": "https",
"overwrite.cli.url": "https:\/\/nextcloud.mydomain.de",
"default_phone_region": "DE",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"instanceid": "***REMOVED SENSITIVE VALUE***",
"memcache.local": "\\OC\\Memcache\\APCu",
"redis": {
"host": "***REMOVED SENSITIVE VALUE***",
"port": 6379
},
"filelocking.enabled": true,
"memcache.locking": "\\OC\\Memcache\\Redis",
"log_type": "file",
"logfile": "\/mnt\/ncdata\/nextcloud.log",
"loglevel": "2",
"maintenance": false,
"theme": "",
"updater.secret": "***REMOVED SENSITIVE VALUE***",
"config_preset": 2,
"mail_smtpmode": "smtp",
"mail_smtpsecure": "ssl",
"mail_sendmailmode": "smtp",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "465",
"mail_smtpauth": true,
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"maintenance_window_start": 1,
"ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
"twofactor_enforced": "true",
"twofactor_enforced_groups": [
"Dom\u00e4nen-Benutzer",
"admin"
],
"twofactor_enforced_excluded_groups": [],
"security.trusted_device_duration": "7776000",
"serverid": 1,
"updater.skip.backup": true
}
}
List of activated Apps
Enabled:
- activity: 8.0.0
- appstore: 2.0.0-dev.0
- bruteforcesettings: 8.0.0
- circles: 35.0.0
- cloud_federation_api: 2.0.0-dev.0
- comments: 2.0.0-dev.0
- contactsinteraction: 2.0.0-dev.0
- dashboard: 8.0.0-dev.0
- dav: 2.0.0-dev.1
- federatedfilesharing: 2.0.0-dev.1
- federation: 2.0.0-dev.0
- files: 3.0.0-dev.0
- files_downloadlimit: 5.3.0
- files_lock: 35.0.0
- files_pdfviewer: 8.0.0
- files_reminders: 2.0.0-dev.0
- files_sharing: 2.0.0-dev.1
- files_trashbin: 2.0.0-dev.0
- files_versions: 2.0.0-dev.0
- firstrunwizard: 8.0.0
- groupfolders: 23.0.1
- guests: 4.10.0
- logreader: 8.0.0
- lookup_server_connector: 2.0.0-dev.0
- nextcloud_announcements: 7.0.0
- notifications: 8.0.0
- oauth2: 2.0.0-dev.0
- office: 1.1.0
- password_policy: 7.0.0
- photos: 8.0.0
- privacy: 7.0.0
- profile: 2.0.0-dev.0
- provisioning_api: 2.0.0-dev.0
- recommendations: 8.0.0
- related_resources: 6.0.0
- serverinfo: 7.0.0
- settings: 2.0.0-dev.0
- sharebymail: 2.0.0-dev.0
- sharing: 1.0.4
- support: 7.0.0
- survey_client: 7.0.0
- systemtags: 2.0.0-dev.0
- text: 9.0.0
- theming: 3.0.0-dev.0
- twofactor_backupcodes: 2.0.0-dev.0
- twofactor_totp: 17.1.0
- updatenotification: 2.0.0-dev.0
- user_ldap: 2.0.0-dev.0
- user_status: 2.0.0-dev.0
- viewer: 8.0.0
- weather_status: 2.0.0-dev.0
- webhook_listeners: 2.0.0-dev.0
- workflowengine: 3.0.0-dev.0
Disabled:
- admin_audit: 2.0.0-dev.0
- app_api: 35.0.0 (installed 35.0.0)
- encryption: 3.0.0-dev.0
- files_external: 2.0.0-dev.0
- suspicious_login: 13.0.0
- testing: 1.23.0
- twofactor_nextcloud_notification: 9.0.0
Nextcloud Signing status
No errors have been found.
Nextcloud Logs
Login-name mismatch (login name and UUID pseudonymised, IP and domain removed):
{"level":3,"time":"2026-09-19T07:26:32+00:00","user":"--","app":"core",
"method":"GET","url":"/ocs/v2.php/cloud/capabilities","scriptName":"/ocs/v2.php",
"message":"App token login name does not match","userAgent":"okhttp/5.5.0",
"version":"35.0.0.10","data":{"tokenLoginName":"jdoe",
"sessionLoginName":"AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE","app":"core",
"user":"AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE"}}
{"level":2,"time":"2026-09-19T07:26:32+00:00","user":"--","app":"core",
"method":"GET","url":"/ocs/v2.php/cloud/capabilities","scriptName":"/ocs/v2.php",
"message":"Login failed: 'AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE'",
"userAgent":"okhttp/5.5.0","version":"35.0.0.10","data":{"app":"core"}}
Account being disabled after a handful of these:
{"level":2,"time":"2026-09-19T04:50:16+00:00","user":"--","app":"password_policy",
"method":"GET","url":"/ocs/v2.php/cloud/capabilities","scriptName":"/ocs/v2.php",
"message":"Too many consecutive failed login attempts, disabling user",
"userAgent":"okhttp/5.5.0","version":"35.0.0.10",
"data":{"app":"password_policy","uid":"AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE"}}
Resulting 503 on WebDAV once the account is disabled:
{"level":3,"time":"2026-09-19T04:50:23+00:00","app":"webdav","method":"PROPFIND",
"url":"/remote.php/dav/files/AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE/",
"message":"OC\\User\\DisabledUserException: Konto deaktiviert",
"userAgent":"Mozilla/5.0 (Android) Nextcloud-android/35.0.0","version":"35.0.0.10",
"exception":{"Exception":"Sabre\\DAV\\Exception\\ServiceUnavailable",
"Message":"OC\\User\\DisabledUserException: Konto deaktiviert",
"File":"/var/www/nextcloud/apps/dav/lib/Connector/Sabre/Auth.php","Line":122}}
Additional info
Stack trace of the underlying exception:
OC\User\DisabledUserException at lib/private/User/Session.php:339
#0 lib/private/User/Session.php(633): OC\User\Session->completeLogin()
#1 lib/private/User/Session.php(322): OC\User\Session->loginWithToken()
#2 lib/private/User/Session.php(427): OC\User\Session->login()
#3 apps/dav/lib/Connector/Sabre/Auth.php(89): OC\User\Session->logClientIn()
#4 3rdparty/sabre/dav/lib/DAV/Auth/Backend/AbstractBasic.php(103): ...->validateUserPass()
#5 apps/dav/lib/Connector/Sabre/Auth.php(202): ...->check()
Relevant LDAP configuration
ldapConfigurationActive 1
ldapExpertUsernameAttr (empty)
ldapExpertUUIDUserAttr (empty)
ldapUuidUserAttribute auto
ldapLoginFilter (&(&(|(objectclass=person))(|(|(memberof=CN=,CN=Users,DC=example,DC=local)(primaryGroupID=513))))(samaccountname=%uid))
ldapUserDisplayName displayname
markRemnantsAsDisabled 0
occ user:list --info shows user_id = UUID, backend: LDAP for all affected accounts.
Things already ruled out
- No stale tokens:
SELECT * FROM oc_authtoken WHERE uid='<uuid>' returns zero rows,
and occ user:auth-tokens:list is empty — yet the mismatch still occurs on the next request.
- Not a cache artefact:
systemctl restart php-fpm apache2 and redis-cli FLUSHALL do not change it.
- Not a stale client: account fully removed and re-created on the device.
- Not LDAP disabling the account:
markRemnantsAsDisabled is 0; the disable comes from password_policy.
Operating system
Debian 13 (Trixie), TurnKey Linux appliance in a Proxmox LXC
Clients affected
- Nextcloud Android 35.0.0 (requests via
okhttp/5.5.0) — fails
- Nextcloud Desktop (Windows) 34.0.3 — works, since it uses
remote.php/dav
Workaround in use
Setting occ config:app:set password_policy maximumLoginAttempts --value=0 stops the
account from being disabled. The core brute-force throttling remains active, so this
keeps the instance usable without removing protection — but the failed logins continue.
Bug description
After upgrading from Nextcloud 34 to 35.0.0, LDAP-backed accounts whose internal
UID is a UUID (while the login name is the AD
samaccountname) can no longerauthenticate against
/ocs/v2.php/cloud/capabilities. The server logsApp token login name does not matchfollowed byLogin failed.This configuration has been running without problems for about a year on NC 32–34.
The failures started immediately after the upgrade to 35.
Two things make this different from the previously reported occurrences of this
message (#45216, #51928, #6783), where the mismatch was logged but synchronisation
kept working:
password_policy, which then disablesthe account ("Too many consecutive failed login attempts, disabling user").
The disabled account causes
Sabre\DAV\Exception\ServiceUnavailable(HTTP 503)on WebDAV, which clients display to the user as "server is in maintenance mode".
Removing the account on the device and setting it up from scratch does not help —
a freshly created token shows the same mismatch on its first request. Deleting all
auth tokens for the user (verified:
oc_authtokenempty for that UID) and flushingAPCu/Redis does not help either.
remote.php/davrequests authenticate successfully; only/ocs/v2.php/cloud/capabilitiesfails. This seems to narrow down the affected code path.
Steps to reproduce
user_ldapagainst Active Directory withldapExpertUsernameAttrempty, so the internal UID becomes the AD objectGUID (a UUID) while users log in withtheir
samaccountname.samaccountname.nextcloud.log.Expected behavior
The token is accepted and
/ocs/v2.php/cloud/capabilitiesreturns 200, as it did on 34.Nextcloud Server version
35
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.3
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 31 to 32)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{ "system": { "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "localhost", "192.168.0.18", "nextcloud.mydomain.de" ], "trusted_proxies": "***REMOVED SENSITIVE VALUE***", "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "mysql", "version": "35.0.0.10", "overwriteprotocol": "https", "overwrite.cli.url": "https:\/\/nextcloud.mydomain.de", "default_phone_region": "DE", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "mysql.utf8mb4": true, "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "instanceid": "***REMOVED SENSITIVE VALUE***", "memcache.local": "\\OC\\Memcache\\APCu", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 6379 }, "filelocking.enabled": true, "memcache.locking": "\\OC\\Memcache\\Redis", "log_type": "file", "logfile": "\/mnt\/ncdata\/nextcloud.log", "loglevel": "2", "maintenance": false, "theme": "", "updater.secret": "***REMOVED SENSITIVE VALUE***", "config_preset": 2, "mail_smtpmode": "smtp", "mail_smtpsecure": "ssl", "mail_sendmailmode": "smtp", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "465", "mail_smtpauth": true, "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***", "maintenance_window_start": 1, "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory", "twofactor_enforced": "true", "twofactor_enforced_groups": [ "Dom\u00e4nen-Benutzer", "admin" ], "twofactor_enforced_excluded_groups": [], "security.trusted_device_duration": "7776000", "serverid": 1, "updater.skip.backup": true } }List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
Stack trace of the underlying exception:
OC\User\DisabledUserException at lib/private/User/Session.php:339
#0 lib/private/User/Session.php(633): OC\User\Session->completeLogin()
#1 lib/private/User/Session.php(322): OC\User\Session->loginWithToken()
#2 lib/private/User/Session.php(427): OC\User\Session->login()
#3 apps/dav/lib/Connector/Sabre/Auth.php(89): OC\User\Session->logClientIn()
#4 3rdparty/sabre/dav/lib/DAV/Auth/Backend/AbstractBasic.php(103): ...->validateUserPass()
#5 apps/dav/lib/Connector/Sabre/Auth.php(202): ...->check()
Relevant LDAP configuration
ldapConfigurationActive 1
ldapExpertUsernameAttr (empty)
ldapExpertUUIDUserAttr (empty)
ldapUuidUserAttribute auto
ldapLoginFilter (&(&(|(objectclass=person))(|(|(memberof=CN=,CN=Users,DC=example,DC=local)(primaryGroupID=513))))(samaccountname=%uid))
ldapUserDisplayName displayname
markRemnantsAsDisabled 0
occ user:list --infoshowsuser_id= UUID,backend: LDAPfor all affected accounts.Things already ruled out
SELECT * FROM oc_authtoken WHERE uid='<uuid>'returns zero rows,and
occ user:auth-tokens:listis empty — yet the mismatch still occurs on the next request.systemctl restart php-fpm apache2andredis-cli FLUSHALLdo not change it.markRemnantsAsDisabledis0; the disable comes frompassword_policy.Operating system
Debian 13 (Trixie), TurnKey Linux appliance in a Proxmox LXC
Clients affected
okhttp/5.5.0) — failsremote.php/davWorkaround in use
Setting
occ config:app:set password_policy maximumLoginAttempts --value=0stops theaccount from being disabled. The core brute-force throttling remains active, so this
keeps the instance usable without removing protection — but the failed logins continue.