-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Description
⚠️ This issue respects the following points: ⚠️
- This is a bug, not a question or a configuration/webserver/proxy issue.
- This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
- Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- I agree to follow Nextcloud's Code of Conduct.
Bug description
Disabled users cannot be discovered in collaborator searches unless the exact internal user ID is provided. This makes disabled users effectively impossible to reference in environments where user IDs are not human-readable.
The collaborator search intentionally excludes disabled users from search results. They are only returned when the search query exactly matches the internal user ID.
While the user identity still exists and can technically receive shares or be referenced internally, the user becomes undiscoverable through the UI or API unless the exact ID is known.
This becomes particularly problematic when users originate from external identity providers (LDAP, OIDC, etc.), where the internal Nextcloud user ID may be an opaque identifier such as a UUID or random string.
In such cases:
• disabled users do not appear in collaborator search results
• administrators or users typically do not know the internal user ID
• therefore the user cannot realistically be referenced for actions such as sharing or group assignment
As a result, disabled users remain present in the system but are practically unusable because they cannot be located via normal search mechanisms.
This behavior is confusing from an operational perspective, especially in workflows where administrators intentionally disable login access to an account but still need the identity to remain usable for collaboration purposes.
Steps to reproduce
1. Create a user in Nextcloud (local user, LDAP, or OIDC).
2. Disable the user from the admin settings.
3. Go to a location where collaborator search is used (for example: share dialog in Files).
4. Try searching for the disabled user using:
• display name
• email address
• partial username
5. Observe that the disabled user does not appear in the search results.
6. If the exact internal user ID is entered as the search query, the disabled user can still be matched and referenced.
Expected behavior
Disabled users should remain discoverable in collaborator searches when searching by display name, email address, or username, while clearly indicating that the account is disabled.
This would allow administrators and users to still reference the identity (for example when creating shares or managing collaboration) even if the account is not allowed to log in.
At minimum, disabled users should be discoverable through standard search attributes rather than requiring the exact internal user ID, which may not be known or may be an opaque identifier when accounts originate from external identity providers (LDAP, OIDC, etc.).
Nextcloud Server version
32
Operating system
None
PHP engine version
None
Web server
None
Database engine version
None
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
- Default user-backend (database)
- LDAP/ Active Directory
- SSO - SAML
- Other
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response