[Bug]: LDAP accounts with UUID as internal UID can no longer authenticate via /ocs/v2.php/cloud/capabilities after upgrade 34 → 35 Edit: Seems related to android client 35.x rather than server

⚠️ This issue respects the following points: ⚠️

This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
I agree to follow Nextcloud's Code of Conduct.
I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.

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?

Default user-backend (database)
LDAP/ Active Directory
SSO - SAML
Other

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.

This might be related: #44164 (comment)

I'm encountering the same issue where the Nextcloud Android app tries to log in with the user's username alice (sending User-Agent: okhttp/5.5.0) which fails with App token login name does not match because the tokenLoginName is their email, alice123@example.com. sessionLoginName and user are both alice though.

Strangely, shortly thereafter I see successful GET and PROPFIND requests using username alice123@example.com, with User-Agent: Mozilla/5.0 (Android) Nextcloud-android/35.0.0 this time. Allowlisting the IP allows the app to function normally, otherwise the IP is instantly throttled forever from the spam of failed logins.

A fix may have been previously discussed here: #50254. Seems that logging in with an email has some pitfalls, and always logging in with a username is the way to go?

Same issue here — but on Nextcloud Server 34.0.4.1, not 35. So the server upgrade 34 → 35 does not seem to be the trigger; the common factor appears to be Nextcloud Android 35.0.0.

Environment

Server: 34.0.4.1 (managed hosting)
Android app: 35.0.0 — failing requests use user agent okhttp/5.5.0
User backend: LDAP / Active Directory
- ldapExpertUsernameAttr empty, ldapUuidUserAttribute = auto → internal UID is the objectGUID (UUID)
- ldapLoginFilter = (&(|(objectclass=person))(samaccountname=%uid))
- markRemnantsAsDisabled = 0
password_policy with maximumLoginAttempts = 5

Log (pseudonymised)
{"level":3,"time":"2026-09-24T11:03:10+02: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":"34.0.4.1","data":{"tokenLoginName":"jdoe","sessionLoginName":"AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE","app":"core","user":"AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE"}}

Followed by Login failed: 'AAAAAAAA-…' (no LDAP bind attempt, since the UUID does not match the samaccountname login filter), and after a few repetitions the account is disabled by password_policy → DisabledUserException → 503 on WebDAV → the app shows "maintenance mode".

Observations

Reproducible with a completely fresh setup: all tokens revoked, app data cleared, new login via Login Flow. The very first /ocs/v2.php/cloud/capabilities request after login already shows the mismatch.
WebDAV works initially (one file could be opened) until the account gets disabled.
Web login in the mobile browser works fine.
Multiple users and tablets affected; all users are LDAP users with UUID as internal UID.

Since the token's login name is correct (jdoe) and the client sends the internal user ID (UUID) as the Basic auth username for this request, this looks like a regression in the Android client (the okhttp-based code path uses the user ID instead of the login name) rather than a server-side issue. It might make sense to transfer/cross-post this to nextcloud/android.

Workaround in use here as well: occ config:app:set password_policy maximumLoginAttempts --value=0. We will test a downgrade of the Android app and report back.

@tux-sourceish

Thanks @tux-sourceish, that matches my data. Looking at my auth token list, the Android client was on 33.0.1 until the day of the server upgrade and on 35.0.0 in all failing requests, so the server upgrade and the app update coincided. Given the reproduction on server 34.0.4.1, this looks like an Android client regression rather than a server one. Could this be transferred to nextcloud/android?

@requiemmg

Thanks @requiemmg — I can now confirm this with a direct downgrade test.

Same server (34.0.4.1), same LDAP user, same mobile LTE network (not whitelisted for brute-force protection):

Nextcloud Android 34.1.1 (APK from GitHub releases): works flawlessly, not a single log entry.
Nextcloud Android 35.0.0 (Play Store): okhttp/5.5.0 requests to /ocs/v2.php/cloud/capabilities send the UUID instead of the login name → App token login name does not match → Login failed → TooManyRequests / disabled account via password_policy.

So the regression was introduced in the Android client between 34.1.1 and 35.0.0.

Filed on the Android side as nextcloud/android#17707, including the downgrade test result.

Hello,

I'm not sure server side should support this or not however for Android client I created a PR for this: nextcloud/android#17742 you can test and share your feedback and it should work with current server versions.

nextcloud/android#17742

Navigation Menu

Repository navigation

[Bug]: LDAP accounts with UUID as internal UID can no longer authenticate via /ocs/v2.php/cloud/capabilities after upgrade 34 → 35 Edit: Seems related to android client 35.x rather than server #64555

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

Is this bug present after an update or on a fresh install?

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

Relevant LDAP configuration

Things already ruled out

Operating system

Clients affected

Workaround in use

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: LDAP accounts with UUID as internal UID can no longer authenticate via /ocs/v2.php/cloud/capabilities after upgrade 34 → 35 Edit: Seems related to android client 35.x rather than server #64555

Description

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

Is this bug present after an update or on a fresh install?

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

Relevant LDAP configuration

Things already ruled out

Operating system

Clients affected

Workaround in use

Activity

magneticflux- commented on Sep 21, 2026

tux-sourceish commented on Sep 24, 2026

requiemmg commented on Sep 24, 2026

tux-sourceish commented on Sep 24, 2026

tux-sourceish commented on Sep 24, 2026

alperozturk96 commented on Sep 30, 2026

susnux commented on Oct 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions