Server: Upgrade Nextcloud17.0.0 to 17.0.1 no access to personally settings
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
}
ronny6927
All 28 comments
Same here. Only the admin account can go to the personally settings.
AleksCee
on 16 Nov 2019
@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 :thinking:
kesselb
on 16 Nov 2019
Nothing in the Nextcloud.log only a 302 http Status for the settings/user url in the Access.log
AleksCee
on 16 Nov 2019
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....
AleksCee
on 16 Nov 2019
Like "test2" in my screenshot? I made him group admin for "testers" and could access the personal settings.
kesselb
on 16 Nov 2019
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
on 17 Nov 2019
Ok, also with debug level no log output in nextcloud.log while accessing /settings/user
AleksCee
on 17 Nov 2019
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
AleksCee
on 17 Nov 2019
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.
Morganlej
on 17 Nov 2019
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.
https://github.com/e-alfred/ocdownloader/issues/140
AleksCee
on 19 Nov 2019
Hello, I do not have the OCDowloader enabled. Error still exists.
ronny6927
on 19 Nov 2019
@ronny6927 have you try to disable other apps to figure out which also can do this?
AleksCee
on 19 Nov 2019
I would still come up with flouwploud?
ronny6927
on 19 Nov 2019
flowupload is not
ronny6927
on 19 Nov 2019
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!
Morganlej
on 19 Nov 2019
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
on 16 Dec 2019
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.
MarkusKepert
on 16 Dec 2019
Also Rainloop does invoke the issue...
https://github.com/pierre-alain-b/rainloop-nextcloud/issues/121
noci2012
on 14 Jan 2020
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.
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
on 15 Jan 2020
Ah. That seems to be a regression of https://github.com/nextcloud/server/pull/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
kesselb
on 15 Jan 2020
Some apps
Has anyone reported this at the Rainloop repo?
ChristophWurst
on 15 Jan 2020
Yes. Link to issue has been posted earlier.
kesselb
on 15 Jan 2020
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?).
noci2012
on 15 Jan 2020
Is there a place where consistent & useable documentation can be found?
No. The developer experience is discussed here: https://github.com/nextcloud/server/issues/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.
kesselb
on 15 Jan 2020
I tried that, that makes the admin/personal page disappear..
Only the toplevel admin.php & personal.php work. So there is other stuff missing...
noci2012
on 15 Jan 2020
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.
ChristophWurst
on 22 Jan 2020
It would be perfectly acceptable to not show subadmin pages for old applications.
Not showing anything does raise eyebrows...
noci2012
on 22 Jan 2020
Possibly related: https://github.com/nextcloud/server/pull/19703/files#r386283373
ChristophWurst
on 2 Mar 2020
Related issues
egal88
·
100Comments
philippe-levan
·
78Comments
bruennlein
·
73Comments
daita
·
99Comments
knut-hildebrandt
·
73Comments
Most helpful comment
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.