Cloudron Forum

Just updated the last working version to the newest package. Everything is fine. I guess the cause was the strange group provisioning confusion I caused.

Smooth ride so far.

Is there a way to lead logged-in Nextcloud OICD users from Logout back to the Cloudron login form in logged-out state?

Expected behaviour

1. User is logged-in in Nextcloud
2. User presses "Logout" in Nextcloud.
3. User is logged out of the Nextcloud and from Cloudron.
4. User sees the Cloudron login form.

What happens with ˋallow_user_multiple_backendsˋ set to value=0:

1. User presses "Logout" in Nextcloud
2. User is invisibly getting redirected to Cloudron login form that reports to the Nextcloud instance that user is logged-in.
3. User ends up logged-in in Nextcloud.

This would be useful for instances where Nextcloud is the primarily hosted app. We have a server with Nextcloud and Collabora Office backend. There is usually no necessity for users to ever see the dashboard other than editing their profile.

Good Morning and thank you for supporting my thought process.

I restored from the last functioning backup and was able to login. Of course we are missing 24 hours of synced data but this is not a big issue. Backups are there and local folders are slowly getting synced up into nc.

Now, I was able to make a certain profile nc admin again via occ. This gave me the chance to get into the config of the Open ID Connect app inside nc.

Right now I suppose the problem occurs due to a conflict of group provisioning. We have OIDC users and their groups are being provisioned into nc. We also have legacy nc native groups. If the conflict really lies within the group provisioning, I am not sure what to do next.

Do you recommend to turn off group provisioning until it is clear?

On the weekend I will clone the working copy and update it to see if the issue is caused by the update or by something else. This is my strategy so far.

@BrutalBirdie

I changed which groups can manage users within Nextcloud. That is all.
Some users had lost their admin rights which I regranted them. I made a post a few hours ago that shows how I did this.

One thing that I noticed is that users I put into a Nextcloud group within Nextcloud did not stay there after re-logins at first. Then all of a sudden no user was able to login as described.

@BrutalBirdie

Same error log in Firefox.

The problem started before the update. I updated to the latest version in hope of a fix. To no avail.

This part of the error points to ShareDisableChecker.php. I don't know what to do with that.

/app/code/lib/private/Share20/ShareDisableChecker.php' line 59","userAgent":

Looking into Nextcloud's code I see this on line 59:

  $remainingGroups = array_diff($usersGroups, $excludedGroups);

Source:
https://github.com/nextcloud/server/blob/master/lib/private/Share20/ShareDisableChecker.php#L59

I assume it has something to do with Users Groups then. But this is as far as I get.

Group provisioning on Nextcloud OIDC plugin is enabled.

Nextcloud:
Nextcloud 31.0.2
com.nextcloud.cloudronapp@5.4.1

Cloudron:
v8.3.1 (Ubuntu 22.04.2 LTS)

Since a few hours ago users are not able to login into Nextcloud via OIDC.

Nothing I tried worked so far.

1. User ist logged in on dashboard.
2. User goes to Nextcloud URL
3. "Login with Cloudron" is offered
4. User clicks on "login with Cloudron"
5. Internal Server error appears

( image url)

Group provisioning is on, by the way.

Here is what I see in the logs:

A{"reqId":"1sHMHUYVvR0CKguCIsTd","level":3,"time":"2025-04-02T19:36:25+00:00","remoteAddr":"xx.xxx.xxx.xxx","user":"<***redactedforprivacy***>","app":"index","method":"GET","url":"/apps/user_oidc/code?code=<***redactedforprivacy***>&state=Z1XZJW6NB8D2DUNTYOIN63RXUF6KRXUP&iss=https%3A%2F%2F<***redactedforprivacy***>%2Fopenid","message":"array_diff(): Argument #2 must be of type array, stdClass given in file '/app/code/lib/private/Share20/ShareDisableChecker.php' line 59","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.3.1 Safari/605.1.15","version":"31.0.2.1","exception":{"Exception":"Exception","Message":"array_diff(): Argument #2 must be of type array, stdClass given in file '/app/code/lib/private/Share20/ShareDisableChecker.php' line 59","Code":0,"Trace":[{"file":"/app/code/lib/private/AppFramework/App.php","line":161,"function":"dispatch","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->"},{"file":"/app/code/lib/private/Route/Router.php","line":307,"function":"main","class":"OC\\AppFramework\\App","type":"::"},{"file":"/app/code/lib/base.php","line":1025,"function":"match","class":"OC\\Route\\Router","type":"->"},{"file":"/app/code/index.php","line":24,"function":"handleRequest","class":"OC","type":"::"}],"File":"/app/code/lib/private/AppFramework/Http/Dispatcher.php","Line":146,"Previous":{"Exception":"TypeError","Message":"array_diff(): Argument #2 must be of type array, stdClass given","Code":0,"Trace":[{"file":"/app/code/lib/private/Share20/ShareDisableChecker.php","line":59,"function":"array_diff"},{"file":"/app/code/lib/private/Share20/Manager.php","line":1976,"function":"sharingDisabledForUser","class":"OC\\Share20\\ShareDisableChecker","type":"->"},{"file":"/app/data/apps/files_sharing/lib/MountProvider.php","line":64,"function":"sharingDisabledForUser","class":"OC\\Share20\\Manager","type":"->"},{"file":"/app/code/lib/private/Files/Config/MountProviderCollection.php","line":72,"function":"getMountsForUser","class":"OCA\\Files_Sharing\\MountProvider","type":"->"},{"file":"/app/code/lib/private/Files/Config/MountProviderCollection.php","line":129,"function":"getMountsFromProvider","class":"OC\\Files\\Config\\MountProviderCollection","type":"->"},{"file":"/app/code/lib/private/Files/SetupManager.php","line":204,"function":"addMountForUser","class":"OC\\Files\\Config\\MountProviderCollection","type":"->"},{"file":"/app/code/lib/private/Files/SetupManager.php","line":311,"function":"OC\\Files\\{closure}","class":"OC\\Files\\SetupManager","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/app/code/lib/private/Files/SetupManager.php","line":203,"function":"setupForUserWith","class":"OC\\Files\\SetupManager","type":"->"},{"file":"/app/code/lib/private/Files/Filesystem.php","line":332,"function":"setupForUser","class":"OC\\Files\\SetupManager","type":"->"},{"file":"/app/code/lib/private/Cache/File.php","line":37,"function":"initMountPoints","class":"OC\\Files\\Filesystem","type":"::"},{"file":"/app/code/lib/private/Cache/File.php","line":158,"function":"getStorage","class":"OC\\Cache\\File","type":"->"},{"file":"/app/code/lib/base.php","line":860,"function":"gc","class":"OC\\Cache\\File","type":"->"},{"function":"{closure}","class":"OC","type":"::","args":["*** sensitive parameters replaced ***"]},{"file":"/app/code/lib/private/Hooks/EmitterTrait.php","line":88,"function":"call_user_func_array"},{"file":"/app/code/lib/private/Hooks/PublicEmitter.php","line":22,"function":"emit","class":"OC\\Hooks\\BasicEmitter","type":"->"},{"file":"/app/code/lib/private/User/Session.php","line":350,"function":"emit","class":"OC\\Hooks\\PublicEmitter","type":"->"},{"file":"/app/data/apps/user_oidc/lib/Controller/LoginController.php","line":526,"function":"completeLogin","class":"OC\\User\\Session","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/app/code/lib/private/AppFramework/Http/Dispatcher.php","line":200,"function":"code","class":"OCA\\UserOIDC\\Controller\\LoginController","type":"->"},{"file":"/app/code/lib/private/AppFramework/Http/Dispatcher.php","line":114,"function":"executeController","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->"},{"file":"/app/code/lib/private/AppFramework/App.php","line":161,"function":"dispatch","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->"},{"file":"/app/code/lib/private/Route/Router.php","line":307,"function":"main","class":"OC\\AppFramework\\App","type":"::"},{"file":"/app/code/lib/base.php","line":1025,"function":"match","class":"OC\\Route\\Router","type":"->"},{"file":"/app/code/index.php","line":24,"function":"handleRequest","class":"OC","type":"::"}],"File":"/app/code/lib/private/Share20/ShareDisableChecker.php","Line":59},"message":"array_diff(): Argument #2 must be of type array, stdClass given in file '/app/code/lib/private/Share20/ShareDisableChecker.php' line 59","exception":{},"CustomMessage":"array_diff(): Argument #2 must be of type array, stdClass given in file '/app/code/lib/private/Share20/ShareDisableChecker.php' line 59"}}

@jdaviescoates Yep, I read about it and it made sense. Problem was that I could not even get to the NC OIDC app config due to missing admin rights. thankfully the occ command made the native admin group reappear.

From a logical point of view provisioning admin rights to a certain OICD group should be an option.

This could be a field in the OIDC plugin where we could define a group name that is treated as admin and grants native NC admin rights to users within.

Never mind but if you happen to get yourself into a similar situation, do the following in the Nextcloud app's terminal:

sudo -u www-data php -f /app/code/occ group:adduser admin <username-of-existing-account-to-be-admin> -n

This way the native Nextcloud group "Administrators" reappears and the account is granted admin rights.

So, apparently the sync between OIDC groups and NC groups is broken. The NC group "admin" is nowhere to be seen within Nextcloud web UI and all users belonging to this group have lost their admin rights within Nextcloud.

How do I restore admin rights for accounts that exist both as OICD and NC?
I am locked out of administrative configuration within Nextcloud. As well as every other admin user.

I suppose that the OIDC regex expression might be a problem here. I can not edit it though, since I have no admin rights anymore.

Please help.

@joseph We are already up-to-date on a live Nextcloud. Thankfully problem 1. only affaects 5 accounts so far. We will manually transfer those to Cloudron.

A nice option would be to customize the text of the "Login with Cloudron" button and the info text shown above. Or, even better, a redirect to Cloudron's login form without a need of the button to begin with.

Basically yes. Here is the scenario in chronological order.

1. Fresh Nextcloud is installed on Cloudron instance pre-OIDC, user management being set to Cloudron, not Nextcloud
2. Accounts are created via Cloudron user management
3. Users start using Nextcloud
4. Users create more accounts within Nextcloud
5. Accounts created within Nextcloud do not sync back to Cloudron user directory. This was not seen as a problem since these local users were able to login into Nextcloud which is all they needed.
6. Nextcloud gets updated to OIDC version.
7. Accounts that were LDAP Cloudron accounts can not login via Nextcloud login form anymore. They have to "Login with Cloudron".
8. Accounts that were created within Nextcloud and did not reflect into Cloudron user directory can not log in anymore.

This is where we are now. The two problems summarized being:

1. Nextcloud accounts that do not exist in the Cloudron directory can not login into Nextcloud anymore.
2. Cloudron accounts that used to login with their Cloudron credentials into Nextcloud's login form, can not login directly. They have to "Login with Cloudron", get redirected to Cloudron's app specific login screen and only after that they are logged in into Nextcloud.

Expected behaviour:

1. Nextcloud accounts that do not exist in Cloudron user directory should be able to log in via Nextcloud login form.
2. Cloudron accounts should be able to login with their Cloudron credentials without the need of "Login with Cloudron" just by typing their Cloudron credentials into Nextcloud's login form.

This may be an exotic case:

I am running a Nextcloud instance where LDAP is enabled. Uses of the institution thereby have cloudron LDAP accounts that reflect into the Nextcloud instance.

Now the same institution is creating Nextcloud user accounts within Nextcloud. These users are signing up directly to the Nextcloud instance and not to the parent Cloudron instance. Their profiles do not appear in Cloudron's LDAP directory.

This results in two types of users. The institution must be able to create user accounts for external collaborators within the Nextcloud instance. They do not need to be Cloudron users.

Will the upgrade to OIDC affect the user accounts only created within the Nextcloud instance?

User Management is enabled for the Nextcloud app. Non-Cloudron Nextcloud-only accounts exist and are behaving normally right now.

The institution is in the process of creating 100+ Nextcloud accounts. Any recommendations before sh*t hits the fan?

@girish

I hope this is the right place. This is a minor one but it would be comfy: An option to delete accidental local backups from the UI. The scenario occurs when no backup volume is configured and backups are on, which if remembered correctly is the default.

The way to get rid of local backups right now involves ssh-ing into the server and manually deleting the files.‬

Has anyone successfully installed it DIY on Cloudron?

I am also interestedin using WriteFreely via Cloudron.

I stumbled upon OpenTrashMail since it is able to convert newsletter mails into subscribable RSS feeds. I would really like to separate newsletters from my mail inbox. OpenTrashMail seems to do the job. Any new considerations?

@girish Just contacted you.

In case I try migrating the users, does this also migrate all user settings, passwords and so on? Or do the user directories only contain data?

Users are managed by the app on this instance, not by Cloudron.

Running the app in recovery mode gives me the following:

Jan 07 20:51:02 Command "upgrade" is not defined.
Jan 07 20:51:02Nextcloud is not installed - only a limited number of commands are available
Jan 07 20:51:05[GET] /healthcheck
Jan 07 20:51:05box:tasks update 4766: {"percent":30,"message":"Setting up addons"}
Jan 07 20:51:05box:services setupAddons: Setting up ["postgresql","sendmail","ldap","redis","localstorage","scheduler","turn"]
Jan 07 20:51:05box:services setupAddons: setting up addon postgresql with options {}
Jan 07 20:51:05box:services Setting up postgresql
Jan 07 20:51:05box:services Setting postgresql addon config to [{"name":"CLOUDRON_POSTGRESQL_URL","value":"postgres://user1af67d47f12d4d8b9890304a9c7e915b:30234061fc3bfa5e3c9c8f6d760fee506c9d6cb66069523f6c00ea7bb4addd9c4fb5f942c853d832967cee25d5b42d08eb3e2c766bc13954f0bd54459685c9d9@postgresql/db1af67d47f12d4d8b9890304a9c7e915b"},{"name":"CLOUDRON_POSTGRESQL_USERNAME","value":"user1af67d47f12d4d8b9890304a9c7e915b"},{"name":"CLOUDRON_POSTGRESQL_PASSWORD","value":"30234061fc3bfa5e3c9c8f6d760fee506c9d6cb66069523f6c00ea7bb4addd9c4fb5f942c853d832967cee25d5b42d08eb3e2c766bc13954f0bd54459685c9d9"},{"name":"CLOUDRON_POSTGRESQL_HOST","value":"postgresql"},{"name":"CLOUDRON_POSTGRESQL_PORT","value":"5432"},{"name":"CLOUDRON_POSTGRESQL_DATABASE","value":"db1af67d47f12d4d8b9890304a9c7e915b"}]
Jan 07 20:51:05box:services setupAddons: setting up addon sendmail with options {"supportsDisplayName":false}
Jan 07 20:51:05box:services Setting up SendMail
Jan 07 20:51:05box:services Setting sendmail addon config to [{"name":"CLOUDRON_MAIL_SMTP_SERVER","value":"mail"},{"name":"CLOUDRON_MAIL_SMTP_PORT","value":"2525"},{"name":"CLOUDRON_MAIL_SMTPS_PORT","value":"2465"},{"name":"CLOUDRON_MAIL_STARTTLS_PORT","value":"2587"},{"name":"CLOUDRON_MAIL_SMTP_USERNAME","value":"wolke@tee-server.de"},{"name":"CLOUDRON_MAIL_SMTP_PASSWORD","value":"6257492a4e30247b589fefb907b9e8b4d5bdf3396d2c5914"},{"name":"CLOUDRON_MAIL_FROM","value":"wolke@tee-server.de"},{"name":"CLOUDRON_MAIL_DOMAIN","value":"tee-server.de"}]
Jan 07 20:51:05box:services setupAddons: setting up addon ldap with options {}
Jan 07 20:51:05box:services setupAddons: setting up addon redis with options {}
Jan 07 20:51:05box:services Re-using existing redis container with state: {"Status":"running","Running":true,"Paused":false,"Restarting":false,"OOMKilled":false,"Dead":false,"Pid":42957,"ExitCode":0,"Error":"","StartedAt":"2024-01-07T11:40:56.222621687Z","FinishedAt":"2024-01-07T11:40:55.251426628Z"}
Jan 07 20:51:05box:services Waiting for redis-1af67d47-f12d-4d8b-9890-304a9c7e915b
Jan 07 20:51:05box:services setupAddons: setting up addon localstorage with options {}
Jan 07 20:51:05box:services setupLocalStorage
Jan 07 20:51:05box:shell createVolume spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/mkdirvolume.sh /home/yellowtent/appsdata/1af67d47-f12d-4d8b-9890-304a9c7e915b/data
Jan 07 20:51:05box:shell createVolume (stderr): sudo: unable to resolve host 1001415-406: Name or service not known
Jan 07 20:51:05box:services setupAddons: setting up addon scheduler with options {"housekeeping":{"schedule":"*/5 * * * *","command":"/app/pkg/cron.sh"}}
Jan 07 20:51:05box:services setupAddons: setting up addon turn with options {"optional":true}
Jan 07 20:51:05box:services Setting up TURN
Jan 07 20:51:05box:tasks update 4766: {"percent":60,"message":"Creating container"}
Jan 07 20:51:05box:apptask createContainer: creating container
Jan 07 20:51:06Repair mode. Use the webterminal or cloudron exec to repair. Sleeping
Jan 07 20:51:06box:shell addLogrotateConfig spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/configurelogrotate.sh add 1af67d47-f12d-4d8b-9890-304a9c7e915b /tmp/1af67d47-f12d-4d8b-9890-304a9c7e915b.logrotate
Jan 07 20:51:06box:shell addLogrotateConfig (stderr): sudo: unable to resolve host 1001415-406: Name or service not known
Jan 07 20:51:06box:apptask startApp: starting container
Jan 07 20:51:06box:tasks update 4766: {"percent":100,"message":"Done"}
Jan 07 20:51:06box:tasks setCompleted - 4766: {"result":null,"error":null}
Jan 07 20:51:06box:taskworker Task took 9.183 seconds
Jan 07 20:51:06box:tasks update 4766: {"percent":100,"result":null,"error":null}
Jan 07 20:51:10=> Healtheck error: Error: connect ECONNREFUSED 172.18.19.126:80```

The backups got accidentally dropped as they were on the same volume as the system. Dumb situation. Nothing else got removed though. The disk full issue has been resolved. I will try and install a second instance to compare the config files.

I am wondering why the config.php does not contain a datadirectory parameter at all.

Update: The old config differs significantly compared to the new one. I suppose the "update config" and "run migration" steps in the log are trying to migrate the config.php to the new standard. This seems to fail for some reason. The application loops through the follwing again and again:

==> Copying htaccess
Jan 07 19:36:49==> update config
Jan 07 19:36:49==> run migration
Jan 07 19:36:49Nextcloud is not installed - only a limited number of commands are available
Jan 07 19:36:49
Jan 07 19:36:49
Jan 07 19:36:49 Command "upgrade" is not defined.
Jan 07 19:36:49
Jan 07 19:36:49
Jan 07 19:36:54=> Healtheck error: Error: connect EHOSTUNREACH 172.18.19.126:80