[Bug]: LDAP Groups cannot be synced from occ cli
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 36.9k
- Forks
- 5.2k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 713
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
After a fresh install and configuration of the LDAP backend (using occ) verification succeeds using ldap:check-config. Sign-in is possible, however the groups the user is assigned (in fact no LDAP group is recognized) to are not recognized. Neither appear they in group:list nor the Settings UI.
An attempt to force update the group using occ ldap:check-group --update --force succeeds and reports that the group is still available. ldap:check-user --update --force also shows all groups the user has been assigned to, however occ user:info recognizes the user, shows the correct backend and quota but does not show any groups. Also if signed in as the user it is evident that the groups are not recognized indeed.
Going to the LDAP settings and hitting "Verify settings and count the groups" in the "Groups" tab gets rid of all of these problems. Now occ groups:list recognizes the groups as well as occ user:info and the UI.
After having triggered the action once via the GUI adding new groups to LDAP with a subsequent run of ldap:check-group --update --force not only succeeds but also correctly updates users and groups throughout the system without the need to retrigger the "Verify settings and count the groups" action in the UI.
Steps to reproduce
- Install nextcloud
- Configure LDAP via
occ ldap:set-configcommands - Verify that groups are available via
occ ldap:check-groupand do not appear inocc group:list.
Expected behavior
LDAP groups should be available across the system.
Installation method
Community Docker image
Nextcloud Server version
29
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Fresh Nextcloud Server install
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": {
"memcache.local": "\\OC\\Memcache\\APCu",
"apps_paths": [
{
"path": "\/var\/www\/html\/apps",
"url": "\/apps",
"writable": false
},
{
"path": "\/var\/www\/html\/custom_apps",
"url": "\/custom_apps",
"writable": true
}
],
"dbtype": "pgsql",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbtableprefix": "oc_",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"localhost",
"***REMOVED SENSITIVE VALUE***"
],
"mail_smtpmode": "smtp",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "465",
"mail_smtpsecure": "",
"mail_smtpauth": true,
"mail_smtpauthtype": "LOGIN",
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"memcache.locking": "\\OC\\Memcache\\Redis",
"redis": {
"host": "***REMOVED SENSITIVE VALUE***",
"password": "***REMOVED SENSITIVE VALUE***",
"port": 6379
},
"trusted_proxies": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"version": "29.0.2.2",
"overwrite.cli.url": "http:\/\/localhost",
"installed": true,
"instanceid": "***REMOVED SENSITIVE VALUE***",
"ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
"maintenance": false,
"memcache.distributed": "\\OC\\Memcache\\Redis"
}
}
List of activated Apps
Enabled:
- activity: 2.21.1
- bruteforcesettings: 2.9.0
- calendar: 4.7.8
- checksum: 1.2.4
- circles: 29.0.0-dev
- cloud_federation_api: 1.12.0
- comments: 1.19.0
- contacts: 6.0.0
- contactsinteraction: 1.10.0
- dashboard: 7.9.0
- dav: 1.30.1
- deck: 1.13.1
- drawio: 3.0.2
- federatedfilesharing: 1.19.0
- federation: 1.19.0
- files: 2.1.0
- files_downloadlimit: 2.0.0
- files_external: 1.21.0
- files_pdfviewer: 2.10.0
- files_reminders: 1.2.0
- files_sharing: 1.21.0
- files_trashbin: 1.19.0
- files_versions: 1.22.0
- fileslibreofficeedit: 1.1.0
- firstrunwizard: 2.18.0
- forms: 4.2.4
- groupfolders: 17.0.1
- impersonate: 1.16.0
- logreader: 2.14.0
- lookup_server_connector: 1.17.0
- mail: 3.7.2
- nextcloud_announcements: 1.18.0
- notes: 4.10.0
- notifications: 2.17.0
- oauth2: 1.17.0
- onlyoffice: 9.3.0
- passman: 2.4.9
- password_policy: 1.19.0
- photos: 2.5.0
- polls: 7.1.3
- privacy: 1.13.0
- provisioning_api: 1.19.0
- recommendations: 2.1.0
- related_resources: 1.4.0
- serverinfo: 1.19.0
- settings: 1.12.0
- sharebymail: 1.19.0
- support: 1.12.0
- survey_client: 1.17.0
- systemtags: 1.19.0
- tasks: 0.16.0
- text: 3.10.0
- theming: 2.4.0
- twofactor_backupcodes: 1.18.0
- twofactor_totp: 11.0.0-dev
- twofactor_webauthn: 1.4.0
- unroundedcorners: 1.1.3
- updatenotification: 1.19.1
- user_ldap: 1.20.0
- user_status: 1.9.0
- viewer: 2.3.0
- weather_status: 1.9.0
- workflowengine: 2.11.0
Disabled:
- admin_audit: 1.19.0
- encryption: 2.17.0
- suspicious_login: 7.0.0
Nextcloud Signing status
No errors have been found.
Nextcloud Logs
No response
Additional info
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the fresh-install flow with occ ldap:set-config, ldap:check-group, ldap:check-user, group:list, and user:info, then compare it with the LDAP settings action that verifies settings and counts groups. Trace the difference between the CLI checks and the GUI verification. Done means LDAP groups appear in group:list, user:info, and the UI without requiring the GUI action.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- authentication, cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100