Nextcloud version (eg, 12.0.2): 18.0.3
Operating system and version (eg, Ubuntu 17.04): Debian 9
Apache or nginx version (eg, Apache 2.4.25): Nginx
PHP version (eg, 7.1): 7.3-FPM
The issue you are facing:
Is this the first time you’ve seen this error? (Y/N):Y
Steps to replicate it:
- Create a share
- Apply a (LDAP)-Group to it
The output of your Nextcloud log in Admin > Logging:
Operation is not logged in Fatal-Mode
The output of your config.php file in
/path/to/nextcloud (make sure you remove any identifiable information!):
$CONFIG = array ( 'instanceid' => 'REMOVED', 'passwordsalt' => 'REMOVED', 'trusted_domains' => array ( 0 => 'REMOVED', ), 'datadirectory' => '/var/www/REMOVED/priv/data', 'memcache.local' => '\\OC\\Memcache\\APCu', 'memcache.locking' => '\\OC\\Memcache\\Redis', 'redis' => array ( 'host' => 'localhost', 'port' => 6379, ), 'dbtype' => 'mysql', 'version' => '22.214.171.124', 'dbname' => 'owncloud', 'dbhost' => 'localhost', 'dbtableprefix' => 'oc_', 'dbuser' => 'owncloud', 'dbpassword' => 'REMOVED', 'installed' => true, 'forcessl' => true, 'mail_from_address' => 'nextcloud', 'mail_smtpmode' => 'sendmail', 'mail_domain' => 'REMOVED', 'preview_libreoffice_path' => '/usr/bin/libreoffice', 'loglevel' => 4, 'ldapIgnoreNamingRules' => false, 'ldapUserCleanupInterval' => 30, 'preview_max_x' => 100, 'preview_max_y' => 100, 'theme' => '', 'secret' => 'REMOVED', 'maintenance' => false, 'trashbin_retention_obligation' => 'auto', 'updater.release.channel' => 'stable', 'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory', 'overwrite.cli.url' => 'https://REMOVED/', 'htaccess.RewriteBase' => '/', 'mail_smtpauthtype' => 'LOGIN', 'app_install_overwrite' => array ( 0 => 'circles', 1 => 'spreed', 2 => 'twofactor_admin', 3 => 'quota_warning', 4 => 'impersonate', 5 => 'ransomware_detection', 6 => 'activitylog', ), 'mysql.utf8mb4' => true, );
I alread asked in the german sektion of the board, but it seems to me there is more activity on the global boards.
The problem is that (ldap) groups are not processed completely, when applying them to shares. E.g. a group of 30 persons is only processed until member 27.
I had a look into oc_shares table and could see that the entries were missing.
So I removed the group from this share and reapplied it. No luck.
I figured out some SQL statements to create the missing entries, but now users began to create new shares…
I thought it could be a timing problem because the server is under heavy load (700 pupils and 80 teachers) and increased the php runtime limit to 300s. But this did not help.