Upgrade Nextcloud17.0.0 to 17.0.1 no access to personally settings

[ronny6927]

The following problem after updating from NC 17.0.0 to NC 17.0.1, users can no longer access their personal settings.
When the user settings are called, the users are directed to their home directory.
If user is also set as a group administrator, this behavior occurs.

Installed on Ubuntu server 18.04 x64
Apache 2.4.29
PHP 7.3.11
Maria DB 10.4.10

I think it has to do with user rights?
The access rights are correct in the web directory.

Does anyone have a hint?

Server configuration detail

Operating system: Linux 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64

Webserver: Apache/2 (apache2handler)

Database: mysql 10.4.10

PHP version: 7.3.11-1+ubuntu18.04.1+deb.sury.org+1

Modules loaded: Core, date, libxml, openssl, pcre, zlib, filter, hash, Reflection, SPL, sodium, session, standard, apache2handler, mysqlnd, PDO, xml, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, gmp, iconv, imagick, intl, json, exif, mysqli, pdo_mysql, Phar, posix, readline, shmop, SimpleXML, sockets, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xmlreader, xmlrpc, xmlwriter, xsl, zip, Zend OPcache

Nextcloud version: 17.0.1 - 17.0.1.1

Updated from an older Nextcloud/ownCloud or fresh install:

Where did you install Nextcloud from: unknown

Signing status

Array
(
)

List of activated apps

Enabled:
 - accessibility: 1.3.0
 - activity: 2.10.1
 - admin_audit: 1.7.0
 - apporder: 0.8.0
 - bruteforcesettings: 1.4.0
 - calendar: 1.7.1
 - cloud_federation_api: 1.0.0
 - comments: 1.7.0
 - contacts: 3.1.6
 - dav: 1.13.0
 - deck: 0.7.0
 - federatedfilesharing: 1.7.0
 - federation: 1.7.0
 - files: 1.12.0
 - files_accesscontrol: 1.7.0
 - files_automatedtagging: 1.7.0
 - files_downloadactivity: 1.6.0
 - files_external: 1.8.0
 - files_pdfviewer: 1.6.0
 - files_retention: 1.6.0
 - files_rightclick: 0.15.1
 - files_sharing: 1.9.0
 - files_trackdownloads: 1.6.0
 - files_trashbin: 1.7.0
 - files_versions: 1.10.0
 - files_videoplayer: 1.6.0
 - firstrunwizard: 2.6.0
 - flowupload: 0.1.5
 - gallery: 18.4.0
 - groupfolders: 5.0.4
 - logreader: 2.2.0
 - lookup_server_connector: 1.5.0
 - nextcloud_announcements: 1.6.0
 - notes: 3.0.3
 - notifications: 2.5.0
 - oauth2: 1.5.0
 - password_policy: 1.7.0
 - printer: 0.0.1
 - privacy: 1.1.0
 - provisioning_api: 1.7.0
 - rainloop: 6.0.4
 - ransomware_detection: 0.6.0
 - ransomware_protection: 1.5.0
 - richdocuments: 3.4.4
 - serverinfo: 1.7.0
 - sharebymail: 1.7.0
 - sharerenamer: 2.7.2
 - spreed: 7.0.1
 - support: 1.0.1
 - survey_client: 1.5.0
 - systemtags: 1.7.0
 - talk_simple_poll: 1.0.0
 - tasks: 0.11.3
 - terms_of_service: 1.3.0
 - text: 1.1.1
 - theming: 1.8.0
 - twofactor_backupcodes: 1.6.0
 - updatenotification: 1.7.0
 - viewer: 1.2.0
 - workflow_pdf_converter: 1.2.0
 - workflowengine: 1.7.0
Disabled:
 - audioplayer
 - carnet
 - circles
 - cospend
 - drawio
 - encryption
 - event_update_notification
 - external
 - files_antivirus
 - files_mindmap
 - ocr
 - phonetrack
 - recommendations
 - user_external
 - user_ldap
 - w2g2

Configuration (config/config.php)

{
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "#######################",
        "###############"
    ],
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "17.0.1.1",
    "overwrite.cli.url": "https:\/\/cloud.krueger-heizungsanlagen.de",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbport": "",
    "dbtableprefix": "oc_",
    "mysql.utf8mb4": true,
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "installed": true,
    "updater.release.channel": "stable",
    "app_install_overwrite": [
        "apporder"
    ],
    "maintenance": false,
    "mail_smtpmode": "smtp",
    "mail_sendmailmode": "smtp",
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpport": "25",
    "simpleSignUpLink.shown": false,
    "default_language": "de",
    "force_language": "de",
    "session_lifetime": 3600,
    "session_keepalive": true,
    "has_rebuilt_cache": true,
    "theme": "",
    "loglevel": 2
}

[AleksCee]

Same here. Only the admin account can go to the personally settings.

[kesselb]

@ronny6927 @AleksCee anything in your logs? Tried to reproduce it with 17.0.1 and works for me.

Test1 and Test2 can both access the personal settings 🤔

[AleksCee]

Nothing in the Nextcloud.log only a 302 http Status for the settings/user url in the Access.log

[AleksCee]

Ok, I found out another hint: a „normal“ user can access but a user which is a group-admin was redirect to / an then to /files....

[kesselb]

Like "test2" in my screenshot? I made him group admin for "testers" and could access the personal settings.

[AleksCee]

Yes, like Test2. Dam. What else can do the behavior..... two way authentication is another different between the two users. But the admin has two way authentication too and works fine.
Is there a way to increase the log level for this situation?

[AleksCee]

Ok, also with debug level no log output in nextcloud.log while accessing /settings/user

[AleksCee]

Another hint. I have revoked the group admin privileges of the affected user and I can access the private settings of this user. After Grand the group admin privileges again, the user was redirected to /files again. So I think, the reason is the group admin privileges.
Another user on my installation with group admin privileges has the same issue.
Only the server admin and the normal users can access the private setting on my installation.
Any idea what this can be?
Thanks, Alex

[Morganlej]

I saw this problem om NC 17.0.0. It was a freesh install and is not yet updated to 17.0.1.
It is running as an instance at OwnCube.com. Unfortunately without shell access.

I saw this issue now and decided to help testing - but today i can not reproduce this!
Maybe because of a rebuild of cache due to database was moved to SSD (for speed) or some other result of that move. I do not know how the technicians at OwnCube performed the move.

[AleksCee]

Ok I found out the reason. If the plugin ocDownloader activated, I can reproduce the behavior. If I deactivate ocDownloader all users can access there personal settings. I will create issue in this project an link it.
e-alfred/ocdownloader#140

[ronny6927]

Hello, I do not have the OCDowloader enabled. Error still exists.

[AleksCee]

@ronny6927 have you try to disable other apps to figure out which also can do this?

[ronny6927]

I would still come up with flouwploud?

[ronny6927]

flowupload is not

[Morganlej]

I see this issue when ocDownloader 1.7.5 is enabled, not with it disabled.
For me, FlowUpload 0.1.5 can be enabled no problem.
NexCloud version 17.0.0.9

I had ocDownloader enabled before, but disabled it as nobody here used it, and forgot about that. That is why the problem disappeared for me. Good find!

[MarkusKepert]

Hey guys,

i also figured out exact that behaviour with rainloop installed. Disabling rainloop -> fine. Enable rainloop -> settings.php 302 to main. No output in Logs.

[MarkusKepert]

Hey, additional investigation, i found the issue (but no code based solution)

The problem occured on one account only: My own, oldest account with large number of oc_preferences. So tested with different other accounts, no one has this issue.

Found root cause: Combination of "group admin" and roundcube installed cause the 302 redirect from settings to home. Disabling the group admin functionality solved that for me me. In this case it isn't a big issue, because i have an global admin account also.

[noci2012]

Also Rainloop does invoke the issue...
pierre-alain-b/rainloop-nextcloud#121

[kesselb]

https://github.com/e-alfred/ocdownloader/blob/9d36fb0da7cfacba990e71b683a7b28f7321197b/settings/admin.php#L14

https://github.com/pierre-alain-b/rainloop-nextcloud/blob/b93c22966e5ca4dbfc0e1caa6ddd67fe403ee888/rainloop/admin.php#L11

Some apps are still using the old way to register a admin page. This will trigger a redirect for sub admins if they access the personal settings.

At best they would probably just update the apps and use the new way. Old way is deprecated for a while but still there. That seems to be a very frustrating issue.

I don't know much about the "old world". It was not possible in general for sub admins to access the administration section? If that's the case (and that would explain why they use checkAdminUser) we could trigger the include for the legacy forms only for admins and not sub admins.

server/apps/settings/lib/Controller/CommonSettingsTrait.php

Line 95 in 5bf3d1b

if (empty($settings) && !($section->getID() === 'additional' && count(\OC_App::getForms('admin')) > 0)) {

server/apps/settings/lib/Controller/AdminSettingsController.php

Line 95 in 5bf3d1b

$forms = \OC_App::getForms('admin');

Actually that's quite bad. \OC_App::getForms('admin'); will include the legacy forms. It's done twice now. 1. Get the number of legacy forms, 2. Include the the legacy forms. The right way to do this is a new method getFormsCount that will only return the number of forms and not do the include.

cc @nextcloud/server-triage @juliushaertl

[kesselb]

Ah. That seems to be a regression of #15679. The patch introduced admin section for sub admins. And that's the reason it does not work for Nextcloud 17 anymore. Legacy forms have no idea about sub admins ;)

cc @ChristophWurst

[ChristophWurst]

Some apps

Has anyone reported this at the Rainloop repo?

[kesselb]

Yes. Link to issue has been posted earlier.

[noci2012]

This issue triggered something to try to actually fix something.. the findings are:
wrt. updating code for Nextcloud..:
I tried following the guidelines in the docs (https://docs.nextcloud.com/server/17/developer_manual/app/settings.html ) for updating files_opds only to find the settings page-let to disappear.
Also that page is hardly consistent at some places myappid is used and at other survey_client and elsewhere yourappid...
Is there a place where consistent & useable documentation can be found?
Unlike the documentation only the apps\files_opds\admin.php & personal.php old methd seem to work.
Checking out existing plugins doesn't help either. There are even more implementation differences there. Part of the plugins use the Admin settings method also for Personal settings, and seem to work.
So updating is not that trivial, would it be to harsh to describe this as a swampy area? (bordering to a mess?).

[kesselb]

Is there a place where consistent & useable documentation can be found?

No. The developer experience is discussed here: #18677.

Part of the plugins use the Admin settings method also for Personal settings,

Yes. That's the recommended way. A good example for admin and personal settings seems to be the activity app: https://github.com/nextcloud/activity/blob/9601838be45451201b748eaf84946c863479e416/appinfo/info.xml#L51-L56 I think they are using the latest non deprecated approach.

[noci2012]

I tried that, that makes the admin/personal page disappear..
Only the toplevel admin.php & personal.php work. So there is other stuff missing...

[ChristophWurst]

I don't know much about the "old world". It was not possible in general for sub admins to access the administration section? If that's the case (and that would explain why they use checkAdminUser) we could trigger the include for the legacy forms only for admins and not sub admins.

Exactly. In the past admin settings were only shown to real admins. Now some are available to sub admins as well.

[noci2012]

It would be perfectly acceptable to not show subadmin pages for old applications.
Not showing anything does raise eyebrows...

[ChristophWurst]

Possibly related: https://github.com/nextcloud/server/pull/19703/files#r386283373

[szaimen]

As I cannot reproduce the original issue anymore, I will close this ticket. If this is still happening please make sure to upgrade to the latest version. After that, feel free to reopen. The latest version can be seen by checking https://nextcloud.com/install/#install-clients and https://nextcloud.com/install/#instructions-server respectively.