Hello @firmansi Thanks for reporting, we will be on the lookout for more reports like that.

There should be a periodic => Run cron job in your app logs . Do you see it? If not immediately, just keep the log window open for 20 mins, it will print every 5 mins.

Thanks for your reply! I guess we'll just keep the existing users on oidc then. Or maybe, if they're willing to, they can migrate manually. Most shares and other tools (collectives, calendars) are shared via groups, not link.

@sponch thanks for the reminder

Here's how I've temporarily worked around the situation: Manually synced all auto upload folders to ensure I'm not missing any files Cleared the cache on the Nextcloud app Told it to ignore all pending uploads I think there is some sort of rate limit causing issues - once you get too many items pending re-upload, it just keeps hitting the server and Cloudron starts rejecting / ignoring requests from the client, which puts it into a weird state.

From cloudron side, you can get an app password with mail access for the user. This is easy with REST API. On nextcloud side, you have to figure how to automate a mailbox set up for a user with that password .

That did the trick! Thank you! We can close this topic now.

@jdaviescoates Pure gold! I just cleaned up 30ish GB I hope setting the max/min age to 30/7 should prevent this from building up anytime soon.

Thank you for your reply. I have disabled the Nextcloud standard login a while ago so for now users can only login via their Cloudron’s account (including me ). I will try to figure out how to revert that

I've been following the instructions in threads cited below, and it looks like notify_push is up and running configure nginx https://forum.cloudron.io/post/48343 run notify_push via script https://forum.cloudron.io/post/48298

Thank for the reply! I was able to resolve the issue. The external SSHFS volume was still registered in Cloudron, but the remote server was offline, causing the container to fail during startup. Since the mount point was stuck and not removable at first, I proceeded as follows: sudo rmdir /mnt/volumes/... mkdir /mnt/volumes/... cd /mnt/volumes/... By recreating an empty local folder at the exact path Cloudron expected, the app was finally able to start again. Once the app was running, I could remove the external volume cleanly from the Storage configuration in the Cloudron dashboard.

@SolarSimon I'd never even spotted those settings before but see e.g. here https://github.com/nextcloud/server/issues/53705#issuecomment-3012715584 In short, open the web terminal and run: occ config:system:set updatechecker --value=true --type=boolean It should then reappear for you: [image: 1764933999185-img_20251205_112552.jpg]

@vitalymp You can simply create a new user with some bot name and then make a POST call to your nextcloud instance using that users basic auth credentials after recieving data with a webhook. Something like this: { "nodes": [ { "parameters": { "method": "POST", "url": "https://cloud.tld.com/ocs/v2.php/apps/spreed/api/v4/chat/CHAT-ID", "authentication": "genericCredentialType", "genericAuthType": "httpBasicAuth", "sendQuery": true, "queryParameters": { "parameters": [ { "name": "message", "value": "=Message content" } ] }, "sendHeaders": true, "headerParameters": { "parameters": [ { "name": "OCS-APIRequest", "value": "true" }, { "name": "Content-Type", "value": "application/json" }, { "name": "Accept", "value": "application/json" } ] }, "options": {} }, "id": "3efc34ee-e77a-477f-9cbd-9e039f64e143", "name": "Post Message to NC Talk room", "type": "n8n-nodes-base.httpRequest", "typeVersion": 4.2, "position": [ 1872, 160 ], "credentials": { "nextCloudApi": { "id": "RQ8xpIKWFMblRfYZ", "name": "cloud.tld.com – bot" }, "httpHeaderAuth": { "id": "v09VrkQtu9eIAUEl", "name": "Header Auth account" }, "httpBasicAuth": { "id": "6ASiFBk1BEcktXcq", "name": "cloud.tld.com bot" } } }, { "parameters": { "path": "a907934a-19a1-4ced-b919-f1db35a4fa93", "options": {} }, "id": "f11e1143-0a6b-4867-abb2-f03a235e0ed0", "name": "Webhook", "type": "n8n-nodes-base.webhook", "typeVersion": 2, "position": [ 1424, 160 ], "webhookId": "a907934a-19a1-4ced-b919-f1db35a4fa93" } ], "connections": { "Webhook": { "main": [ [ { "node": "Post Message to NC Talk room", "type": "main", "index": 0 } ] ] } }, "pinData": {}, "meta": { "templateCredsSetupCompleted": true, "instanceId": "a382289a228a66b7e622210301ab5b6d8d06d93edb07378019866ea75d7e5793" } }

Hello @Jordy Be very careful with Nextcloud and migrating an OIDC setup. I know that Nextcloud does not play well with these type of migrations. Always test this with a clone from backup and a new installation with the same version where you select let the app handle accounts. There is this app https://apps.nextcloud.com/apps/user_migration for user migration but still, proceed with caution. I've looked into the LDAP to local user migration and have all SQL queries to do that, but not for OIDC to local user. How Nextcloud behaves if you simply change the OIDC provider I can't tell right now. So please keep us updated with findings.

@jdaviescoates so here is my config which works well and gets around the admin group issue. In the OIDC NC app config: [image: 1761898465348-d83b7885-4c11-4657-a8ec-04de244e47e7-image.png] Then you create a group folder per NC group, and when you add a user to Cloudron and add to a specific Cloudron group, it gets automatically added to the corresponding MC group and gets access to the group folder associated with that group. In addition, in order not to confuse users with the NC login form I now disable other login methods using this command: occ config:app:set --value=0 user_oidc allow_multiple_user_backends and set a custom end point to my Cloudron dashboard when people try to log out of Nextcloud: [image: 1761898688780-4316b19b-2691-44b7-b6ec-5fc19a0f335c-image.png]

oh! yes I forgot about that aspect of update control. Thanks for letting us know. I have set it now to show a stable update for all. Sorry for the confusion.