[BUG] LDAP groups not working with Nextcloud

[funbotan]

Hello! I am trying to set up Nextcloud with LLDAP as the user backend. Users are working fine, but there is a problem with groups. I am not sure if this is a problem with LLDAP or NC, and I have no idea how to debug it. I might also just be misunderstanding something, although I think I've read all available documentation by now. Any help is greatly appreciated!

Describe the bug
When I set up the LDAP connection through the LDAP/AD integration app, clicking "Verify settings and count the groups" returns the correct number of groups, which are also visible in the list above. However, they are not visible either in the Nextcloud interface or OCC. The group list only shows internal LLDAP groups (lldap_admin, lldap_password_manager & lldap_strict_readonly), but no custom groups.

To Reproduce

1. Set up Nextcloud with LLDAP as the user and group backend, for example, with this Compose configuration:

  lldap:
    image: lldap/lldap:stable
    container_name: lldap
    ports:
      - 17170:17170
    expose:
      - 3890
    environment:
      UID: 0
      GID: 0
      LLDAP_JWT_SECRET: ${LDAP_JWT_SECRET}
      LLDAP_KEY_SEED: ${LDAP_KEY_SEED}
      LLDAP_LDAP_BASE_DN: ~redacted~
      LLDAP_DATABASE_URL: postgres://lldap:${PASSWORD}@lldapdb/lldap
      LLDAP_HTTP_URL: ~redacted~
      LLDAP_ADMIN_USERNAME: ~redacted~
      LLDAP_LDAP_USER_PASS: ${LDAP_ADMIN_PASSWORD}
    depends_on:
      - lldapdb

  lldapdb:
    image: postgres:16
    container_name: lldapdb
    volumes:
      - lldap-db:/var/lib/postgresql/data
    expose:
      - 5432
    environment:
      POSTGRES_PASSWORD: ${PASSWORD}
      POSTGRES_USER: lldap
      POSTGRES_DB: lldap
    healthcheck:
      test: pg_isready -d lldap -U lldap
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 5s

  nextcloud:
    image: nextcloud
    container_name: nextcloud
    depends_on:
      - nextclouddb
      - redis
    ports:
      - 8081:80
    volumes:
      - ./nextcloud:/var/www/html
      - /mnt/ncdata:/var/www/html/data
    environment:
      PUID: 1000
      PGID: 1000
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: ${PASSWORD}
      MYSQL_HOST: nextclouddb
      REDIS_HOST: redis
      NEXTCLOUD_ADMIN_USER: nc_admin
      NEXTCLOUD_ADMIN_PASSWORD: ${NC_ADMIN_PASSWORD}
      NEXTCLOUD_TRUSTED_DOMAINS: ~redacted~

2. Set up the connection between NC and LLDAP following these instructions. The corresponding group filter is (&(|(objectclass=groupOfUniqueNames))).
3. Run docker exec --user www-data -it nextcloud php occ group:list

Expected behavior
All groups created in LLDAP should be available from Nextcloud.

Logs
There are likely related repeating warnings from LLDAP:

┕━ 🚧 [warn]: Ignoring unrecognized group attribute: \n\
┕━ 🚧 [warn]: Ignoring unknown user attribute "uniquemember" in filter.\n\
┕━ 🚧 [warn]: Ignoring unrecognized group attribute: primarygrouptoken\n\

Nextcloud does not seem to throw anything once the connector is configured.

[nitnelave]

• Can you share your NextCloud configuration? The part relevant to LDAP of course.
• Did you configure it in the UI or in the CLI?
• Can you restart LLDAP in verbose mode, configure NextCloud until you see the list of groups, (i.e. run the query listing the groups), then check the list where you said the custom groups were missing, and post the LLDAP logs for all of that?

I think you might have some extra filters somewhere, or there is a NextCloud cache and you created the group after configuring NextCloud. There is nothing special about the lldap_admin etc groups, except that they are created on startup and can't be modified (and grant permissions). But from the point of view of NextCloud they're just regular groups.

[funbotan]

Thank you for the prompt response! I went to follow your instructions and found the cause in the process 😅
It just so happened that all custom group names had uppercase letters, and because I'm using the stable channel, it is still version 0.5.0 where #849 is not fixed. Therefore, this was just a duplicate of #849. Sorry for wasting your time!