Cloudron Forum

@james Uptime Kuma on a different instance. We had no significant downtimes since last week. Yet, sometimes the backup task gets aborted.

So, now that the server is running on 24.04 everything seems fine most of the time. Except we see the server seemingly restarting once it has finished its backup to a remote CIFS share. It's only a few minutes but enough for our monitoring to notify us.

Is there probably some relation to the way backups work on current Cloudron version?

The machine was stuck on Ubuntu 20.04.6 LTS Linux 5.4.0-124-generic. It has been upgraded to Ubuntu 22.04.5 LTS Linux 5.15.0-170-generic. It was still too slow for normal operation after the upgrade. The provider scaled it up to compensate. Now it is working fine but a doubling in CPU and RAM seems quite strange of a need so sudden.

Yes, indeed both machines are hosted by the same provider. Regarding data center and node, I can not say for sure. Would a storage issue not reflect in I/O numbers of the VPS? Those seem fine.

I used iotop to look at %user / %system% / iowait / %idle and everything looks normal.

w/s 31
%util 4.8
w_await 5.35 ms

It does not seem problematic.

Yesterday one of my Cloudron VPS es started being really slow. Apps were unusably slow. We checked and saw that we are on 20.0 with Cloudron 9. Trying to do a backup before upgrading was impossible. We have Hetzner Storage Boxes as CIFS shares which used to work just fine all the time.

Anyways, we supposed it may be the EOL-Ubuntu, so my hoster upgraded the server to 22.04, recreated containers and so on. Unfortuately the lag was still present. Backup task takes for ever.

To make the VPS useable we temporarily scaled it to 8 vCPUs and 24 GB RAM. This made apps respond properly again. We were on 4 vCPUs and 12 GB RAM a few days ago and the only thing we added was a niche WordPress (Managed) site. Looking at graphs it does not explain the sudden slowdown which also persists in 22.04.

This morning another of our VPSes shows the same pattern. Sudden Slowdown of all apps, failing backup. There are only two apps running on this VPS and we certainly don´t have more users or anything extraordinarily demanding from the outside. Also on 20.04. An upgrade will be made today.

As a side note: our 20.04 kernel on the first machine has been stuck on some 124 version for some reason.

Now it is clear that 20.04 is not supported anymore. But why is the machine similarly slow after upgrade to a supported version (22.04) and why do backups fail? There is a certain lag on the UI as well that correlates with it. Another thing that happens is that "Disk Usage" displays nothing. Not even empty bars. The whole passage is just missing.

Do you have any ideas?

Open for ssh-support by Cloudron team, if you have time.

Chain of events:

1. Cloudron 9 running on 20.04
2. Sudden performance issues correlating with unstable backup tasks
3. We upgrade to 22.04
4. We recreate containers and also do the post-upgrade routines
5. Performance is still laggy. Not as unusable as in the incident but definitely slower.

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?