Under NC17 it is impossible for normal user to reach user settings page when user is enabled as groupadmin same time

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 12.0.2): 17.0.2
Operating system and version (eg, Ubuntu 17.04): ubuntu-server 18.04.3
Apache or nginx version (eg, Apache 2.4.25): NGinx version 1.17.4
PHP version (eg, 7.1): 7.3.13

The issue you are facing: After update (successful) from 16.x to 17.0.2 i tested first with nc admin account. All well so far - at first - but today i wanted to change something in my user-account (an LDAP User - AD member) and that second i click on settings my cloud webui switched over to files.

I reproduced this several times - in log files no entry.

I tested with another user account but with local authentication - no problem.

I switched back again to admin account (local password) and double checked my LDAP/AD settings
All was tagged ok (Connection established, all good …)

I listed my users - alls well so far.

And back again to my user account with ldap credentials. Loged in properly but no admittance to enter the settings page. No error message, no logs - just pulled me back to files section every time i click to enter my settings page.

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

Steps to replicate it:

  1. update 16 to 17
  2. create ldap account
  3. make test
  4. take a click on settings page

The output of your Nextcloud log in Admin > Logging:

PASTE HERE see above - no logs

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

> <?php
> $CONFIG = array (
>   'instanceid' => 'my id',
>   'passwordsalt' => 'my pass',
>   'secret' => 'my secret',
>   'trusted_domains' => 
>   array (
>     0 => 'my.domain.de',
>     1 => 'my.local.IP',
>   ),
>   'activity_expire_days' => 14,
>   'auth.bruteforce.protection.enabled' => 'false',
>   'blacklisted_files' => 
>   array (
>     0 => '.htaccess',
>     1 => 'Thumbs.db',
>     2 => 'thumbs.db',
>   ),
>   'trusted_proxies' => 
>   array (
>     0 => 'my.Proxy.IP',
>   ),
>   'overwritehost' => 'my.domain.de',
>   'overwriteconaddr' => '^IPpart1\\.IPpart2\\.IPpart3\\.IPpart4$',
>   'forward_for_headers' => 
>   array (
>     0 => 'X_FORWARDED_FOR',
>     1 => 'HTTP_X_FORWARDED_FOR',
>   ),
>   'datadirectory' => '/media/cloud/data',
>   'overwriteprotocol' => 'https',
>   'overwrite.cli.url' => '/',
>   'dbtype' => 'pgsql',
>   'version' => '17.0.2.1',
>   'dbname' => 'cloud',
>   'dbhost' => '127.0.0.1',
>   'dbport' => '',
>   'dbtableprefix' => 'oc_',
>   'dbuser' => 'db-user',
>   'dbpassword' => 'db-password',
>   'htaccess.RewriteBase' => '/',
>   'logtimezone' => 'Europe/Berlin',
>   'logfile' => '/media/cloud/data/nextcloud.log',
>   'log_rotate_size' => 10485760,
>   'cron_log' => true,
>   'installed' => true,
>   'filesystem_check_changes' => 0,
>   'quota_include_external_storage' => false,
>   'skeletondirectory' => '',
>   'share_folder' => '/Shares',
>   'knowledgebaseenabled' => false,
>   'ldapIgnoreNamingRules' => false,
>   'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory',
>   'ldapUserCleanupInterval' => 20,
>   'memcache.local' => '\\OC\\Memcache\\Redis',
>   'filelocking.enabled' => 'true',
>   'memcache.locking' => '\\OC\\Memcache\\Redis',
>   'redis' => 
>   array (
>     'host' => '/var/run/redis/redis.sock',
>     'port' => 0,
>     'timeout' => 0.0,
>     'password' => 'my.REDIS.Password',
>   ),
>   'mail_smtpmode' => 'smtp',
>   'mail_smtpsecure' => 'ssl',
>   'mail_from_address' => 'info',
>   'mail_domain' => 'mail.domain.de',
>   'mail_smtphost' => 'mail.domain.de',
>   'mail_smtpport' => '465',
>   'maintenance' => false,
>   'integrity.check.disabled' => false,
>   'updater.release.channel' => 'stable',
>   'enable_previews' => true,
>   'enabledPreviewProviders' => 
>   array (
>     0 => 'OC\\Preview\\PNG',
>     1 => 'OC\\Preview\\JPEG',
>     2 => 'OC\\Preview\\GIF',
>     3 => 'OC\\Preview\\BMP',
>     4 => 'OC\\Preview\\XBitmap',
>     5 => 'OC\\Preview\\Movie',
>     6 => 'OC\\Preview\\PDF',
>     7 => 'OC\\Preview\\MP3',
>     8 => 'OC\\Preview\\TXT',
>     9 => 'OC\\Preview\\MarkDown',
>   ),
>   'preview_max_x' => 1024,
>   'preview_max_y' => 768,
>   'preview_max_scale_factor' => 1,
>   'trashbin_retention_obligation' => 'auto, 7',
>   'loglevel' => 2,
>   'mail_sendmailmode' => 'smtp',
>   'updater.secret' => 'my.updater.secret',
> );

The output of your Apache/nginx/system log in /var/log/____:

Dec 22 15:08:23 server systemd[1]: Starting Clean php session files...
Dec 22 15:08:23 server sessionclean[2148]: find: ‘/usr/local/tmp/sessions/sess_hash-value’ kann nicht gelöscht werden.: Das Dateisystem ist nur lesbar

I get many of these messages above - but no log entry for login failure. It is in my opinion no login failure itself because users can login - but after that are not able to enter their settings page.

For testing i deleted all sessions in /usr/local/tmp and loged in back again with no change.
I tried with safari browser instead of mozilla - no change.

I am not sure but the error occurs since update to 17.x version and in the change log i’ve read that since 17th version of Nextcloud there where changes concerning ldap / password etc.
That’s the reason why i’ve double checked my LDAP settings with admin account after remarking the error.

1 Like

Make sure that the underlying file system is mounted in read-write mode and that the system user, which is used to run the web server, is allowed to write to that directory.

Make sure logging is enabled in NC and PHP especially if you are running php-fpm, doublecheck.

OK with “no logs” i don’t think of a misconfigured logging in config.

As you see above i enabeled logging in my ./config/config.php under nextcloud
->
logfile => ‘/media/cloud/data/nextcloud.log’,

But allthough nc didn’t log any errors for the users that can not access this url
https://my.nextcloud.url/settings/user

The read write problem:

The permissions under /usr/local/tmp/sessions are
0777 for www-data:root

www-data is my webroot user also for the permissions to run the php occ commands in /var/www/nextcloud

My relevant folders should be writable for www-data see the following pics

mainly root:www-data but for the non-ad-users 100% ok to reach the settings pages

Please don’t mix-up different issues. The first problem you have to solve is the “Das Dateisystem ist nur lesbar” message which is logged to the web servers log file. Therefore you should fix this issue first because it impacts the underlying web server.
Once this has been fixed, you can address other issues.

For testing purpose i switched my nextcloud in upgrade mode and my settings are like this

After doing so i still can’t access my settings. But still only for my windows server ad users.
All local users don’t have those problems. So should be less a problem of the linux write settings under ubuntu server than more a ldap problem.

My Con String is the following

User:
LDAP-Filter: (&(|(objectclass=user))(|(|(memberof=CN=NC-GROUP,CN=Users,DC=my,DC=domain)(primaryGroupID=3106))))

Login-Attrib:
LDAP-Filter: (&(&(|(objectclass=user))(|(|(memberof=CN=NC-GROUP,CN=Users,DC=my,DC=domain)(primaryGroupID=3106))))(|(samaccountname=%uid)(|(mailPrimaryAddress=%uid)(mail=%uid))))

Groups:
LDAP-Filter: (&(|(objectclass=group))(|(cn=Domänen-Benutzer)))

And the result looks like this:

… Please don’t mix-up different issues. The first problem you have to solve is the “ Das Dateisystem ist nur lesbar ” message which is logged to the web servers log file. Therefore you should fix this issue…

So i did this first :slight_smile:

my session files were cleaned

Dec 23 15:15:01 server CRON[31264]: (www-data) CMD (php -f /var/www/nextcloud/cron.php > /dev/null 2>&1)
Dec 23 15:30:01 server CRON[1128]: (www-data) CMD (php -f /var/www/nextcloud/cron.php > /dev/null 2>&1)
Dec 23 15:38:01 server systemd[1]: Starting Clean php session files…
Dec 23 15:38:02 server systemd[1]: Started Clean php session files.
Dec 23 15:39:01 server CRON[13782]: (root) CMD (/usr/lib/php/sessionclean 2>&1)
Dec 23 15:45:01 server CRON[16731]: (www-data) CMD (php -f /var/www/nextcloud/cron.php > /dev/null 2>&1)
Dec 23 16:00:01 server CRON[28713]: (www-data) CMD (php -f /var/www/nextcloud/cron.php > /dev/null 2>&1)

Now i created a new user + pw in Active Directory

I logged in and voila i could access the settings page without any harm.

So my question - what is the diff between existing LDAP Accounts to newly (empty ones) that causes NC17 to block??

After 2 logins i activated the TOTP in newly created user as well as others LDAP user have.
Still no harm in entering settings. So LDAP settings should be fine.

Spooky, isn’t it?
And more important: How can i get back control over my existing AD Accounts in NC17 ?

OK folks i figured out what the problem seems to be in NC 17 (17.0.2)

I compared every LDAP setting of old and new users. Old ones don’t work / can’t reach their user settings pages - new ones can!

So what was different. All users that are unable to open their settings page had a privilege to do administrative things in user groups e.g. a guest group.
I disabled this privilege and voila all of them who are now “users” with no admin settings for special groups could open the settings page again.

Re-enabled this privilege and reproducable no access to settings again.

So there is a problem since NC 17.x with that feature. When a local admin (first user e.g.) is giving admin privileges to special users then those users are not able to enter their settings. Perhaps only in combination with LDAP authenticated users - don’t have tested with local authenticated users.

So my question at the developers - could you please review that and maybe reproduce that behaviour. If you are experiencing the same issue - is there a workaround for that?

I edited the title of my post because the error has obviously nothing in common with read / write permissions under nc server (linux server)

Many thanks! and Merry x-mas to all :slight_smile:

1 Like

Hello ,

I have met this same problem with Nextcloud native user administration, eg no LDAP.

Removing the group adminship of my own account gave me access to again to my settings page.

Nextcloud : 17.0.2
I upgraded from 16.0.x

So it is not LDAP related any how

@chrissi55 : a filed a bugreport with number : 18793