Users not displaying in associated groups after update to NC28

[/details]

Nextcloud version (eg, 20.0.5): 28.0.4
Operating system and version (eg, Ubuntu 20.04): RHEL 8.9
Apache or nginx version (eg, Apache 2.4.25): 2.4.37
PHP version (eg, 7.4): 8.3.6

The issue you are facing:
Users assigned to particular groups are not displaying in the associated groups from the Users page.

For example:
John Doe is an active user in the system assigned to admin, ldap_group1, ldap_group2, ldap_group3.
The user will display under active users and the admin group.
The user does not display under the ldap_groups.

Is this the first time you’ve seen this error? (Y/N): Y

Steps to replicate it:

  1. Update from 27.1.(latest) to 28.0.4

The output of your Nextcloud log in Admin > Logging:

Debug	user_ldap	
Calling LDAP function ldap_unbind with parameters [{}]

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
Calling LDAP function ldap_unbind with parameters [{}]

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
readAttribute failed for DN cn=<string>\2C <name>,ou=users,ou=<name>,dc=<name>,dc=com

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
LDAP error No such object (32) after calling ldap_read

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
Calling LDAP function ldap_read with parameters [{},"cn=<string>\\2C <name>,ou=users,ou=<name>,dc=<name>,dc=com","objectClass=*",["displayname"],0,-1]

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
Calling LDAP function ldap_explode_dn with parameters ["<string>",0]

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
readAttribute failed for DN cn=<string>\2C <name>,ou=users,ou=<name>,dc=<name>,dc=com

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
LDAP error No such object (32) after calling ldap_read

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
Calling LDAP function ldap_read with parameters [{},"cn=<string>\\2C <name>,ou=users,ou=<name>,dc=<name>,dc=com","objectClass=*",["displayname"],0,-1]

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
readAttribute failed for DN cn=<string>\2C <name>,ou=users,ou=<name>,dc=<name>,dc=com

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
LDAP error No such object (32) after calling ldap_read

Apr 18, 2024, 10:30:43 AM	

Debug	user_ldap	
Calling LDAP function ldap_read with parameters [{},"cn=<string>\\2C <name>,ou=users,ou=<name>,dc=<name>,dc=com","objectClass=*",["displayname"],0,-1]

Apr 18, 2024, 10:30:43 AM

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

$CONFIG = array (
  'instanceid' => '<string>',
  'passwordsalt' => '<string',
  'secret' => '<string>',
  'trusted_domains' =>
  array (
    0 => '<my server .com>',
  ),
  'forcessl' => true,
  'forceSSLforSubdomains' => true,
  'default_phone_region' => 'US',
  'openssl' =>
  array (
    'config' => '<path to config file>',
  ),
  'mail_smtpdebug' => true,
  'allow_user_to_change_display_name' => true,
  'asset-pipeline.enabled' => false,
  'datadirectory' => '<path to store data>',
  'overwriteprotocol' => 'https',
  'overwrite.cli.url' => '<my site .com>',
  'version' => '28.0.4.1',
  'dbtype' => 'mysql',
  'dbname' => '<database name>',
  'dbhost' => '<database home>',
  'dbtableprefix' => 'oc_',
  'dbuser' => '<database user>',
  'dbpassword' => '<database password',
  'dbdriveroptions' =>
  array (
    1014 => true,
    1011 => '<method>',
  ),
  'logtimezone' => 'UTC',
  'installed' => true,
  'ldapIgnoreNamingRules' => false,
  'mail_from_address' => 'support',
  'mail_smtpmode' => 'smtp',
  'mail_domain' => '<domain>',
  'filelocking.enabled' => true,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => '<redis server>',
    'port' => <port>,
    'dbindex' => 0,
    'password' => '<redis string>',
    'timeout' => 2,
  ),
  'enable_previews' => true,
  'preview_libreoffice_path' => '<office path>',
  'preview_libreoffice_cl_parameters' => ' --headless --nologo --nofirststartwizard --invisible --norestore -convert-to pdf -outdir ',
  'enabledPreviewProviders' =>
  array (
    0 => 'OC\\Preview\\Image',
    1 => 'OC\\Preview\\MP3',
    2 => 'OC\\Preview\\TXT',
    3 => 'OC\\Preview\\MarkDown',
  ),
  'loglevel' => 0,
  'logfile' => '<self>',
  'log_rotate_size' => 104857600,
  'maintenance' => false,
  'appstore.experimental.enabled' => true,
  'trashbin_retention_obligation' => 'auto',
  'updatechecker' => false,
  'htaccess.RewriteBase' => '/',
  'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory',
  'updater.release.channel' => 'stable',
  'mail_smtphost' => '<smtp host>',
  'skeletondirectory' => '',
  'app_install_overwrite' =>
  array (
    0 => 'impersonate',
    1 => 'end_to_end_encryption',
    2 => 'nextant',
  ),
  'twofactor_enforced' => 'true',
  'twofactor_enforced_groups' =>
  array (
    0 => '<first group>',
    1 => '<second group>',
  ),
  'twofactor_enforced_excluded_groups' =>
  array (
  ),
  'encryption.legacy_format_support' => false,
  'encryption.key_storage_migrated' => false,
  'remember_login_cookie_lifetime' => 1296000,
  'session_lifetime' => 86400,
  'session_keepalive' => false,
  'auto_logout' => false,
  'quota_include_external_storage' => false,
  'ldapUserCleanupInterval' => 0,
  'mail_sendmailmode' => 'smtp',
  'mysql.utf8mb4' => true,
  'auth.webauthn.enabled' => false,
  'mail_smtpport' => '25',
  'mail_smtpauth' => 0,
  'mail_smtpstreamoptions' =>
  array (
    'ssl' =>
    array (
      'allow_self_signed' => true,
      'verify_peer' => false,
      'verify_peer_name' => false,
    ),
  ),
);

To determine whether it’s a frontend issue or actually an LDAP matter you may want to check ldap group membership/etc via the command line:

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/occ_command.html#ldap-commands

@jtr, thank you for the reply. I found it useful because it made me realize I needed to investigate more using occ. Also, my apologies for not getting back sooner.

A little background:
Our setup has test and production environments, that are as closely the same as we can get them.

Updated test from 27.1.6 to 27.1.7 to 28.0.3. During the update to 28.0.3 was running into the error discussed in:

and it lead me to:

The resolution to issue 43584 was to remove the offending serialized strings so the update could proceed which it did.
Updated to 28.0.4, hoping it would resolve the issue of users not displaying correctly.

Searching for solutions, found the post:

Tried the reconfigure solution and it did not resolve the issue.

Also, reviewed:

I’m beginning to suspect that I need to find a way to rebuild the data lost
by deleting the serialized string. I believe this is possible from the production environment. I need to figure that out is all.

Using the ldap options I can see the user and the group are listed using ldap:search ‘<user_name>’ and ldap:search --group ‘<group_name>’.
Using ldap:check-user or ldap:check-group, the user/group is still available on LDAP.

Using user:info, I can see the groups the user has assigned.
Using group:info, I can see the backends value which I’m assuming means that is from where the information for the group is coming.

Comparing the databases between test and production:
The table oc_ldap_group_mappings is quite different.
The table oc_ldap_user_mappings is the same.

The test site is where the issue is being seen and until we have a resolution to the users not displaying, we cannot move to 28 in production.
Everything else seems to be working fine. All the apps are working, all pages load, can upload, download and delete files.

I appreciate the help and advice.