Hello @mad_mattho This is not really a support topic regarding Cloudron more so generic Linux hosting administration support. I have moved to the topic to the @help-wanted-or-offered category. But I'll provide some assistance nonetheless. @Mad_Mattho said: Are my cloudron users also users on that server, i.e. Are my cloudron admins also server admins, are they able to login directly to that server by default or not? No. Cloudron users are not Linux users on the server itself. Restoring root access on a system you have lost all access to is possible, but needs some manual work. Here is a good guide from the Ubuntu discourse: https://discourse.ubuntu.com/t/how-to-reset-ubuntu-server-password-using-live-cd-in-bare-metal-or-hypervisor/55745

Hi, this is still not working - any idea?

All good. A few backups have happened since the change and it all went smoothly. What has created the issue for the past few days is a mystery (since instance has been running like this for years) but thanks to you it's all back on track.

I have fixed the crash itself. I think the 38k rows is causing the timeout. Maybe your disk or CPU is slow? But the default transaction lock is 50 seconds, and I can't think why reading 38k rows will take that long. I have changed the transaction's isolation level that should at least make it faster. Let's see how it is in the next release.

Hello @romu79230 @romu79230 said: Is there any technically viable and supported method to migrate this Nextcloud application directly from Cloudron 7.4.1 to an existing Cloudron 7.3.6 instance, without upgrading the destination? It is no longer possible since the app store API changed. You will have to update. @romu79230 said: If we use a recent Cloudron version, can we import the historical Nextcloud 4.17.0 application backup into an existing destination instance without affecting its other applications or users? If you try to import an app from e.g.: Cloudron 10.1.0 to Cloudron 7.3.6 or Cloudron 7.4.1. No, the same issue as above. Also, another issue is that newer Cloudron version use different MySQL and PostgreSQL versions which might not be backwards compatible. In all honesty, the best approach would be to install a new Cloudron server on the latest version and slowly migrate all the apps from the outdated ones to this new Cloudron server. This also is protecting the current running infrastructure from any issues. And with every software, keep it updated.

Right, this is a bug. I have fixed it now. Redis in non-persistent mode deletes the dump on start up Box code will skip backup and restore of non-persistent redis Box code deletes the dump when the redis non-persistent flag is set

RIght, had to add no_root_squash to the NFS server. remounted & All seems to work again now. Thanks!

Sorry for the delay, but I finally got another reboot notification to test it. It does go to 0 after a page refresh. I tested Firefox and Brave with both having this same cache issue. HTH.

Ok, thats good to know because the problem popped back a week later.

Good catch. Was easy to create a test and fix.

Alright, impersonate is back. I removed the option to create app password for another user since this is causing much confusion. The feature was not well-thought-out.

Yes, the patch is applied at restore time, so restore from some old backup and archive will work. I would say you should take a more recent backup though after upgrading to 10.1.x. It will create dumps with the correct quoting. I don't think we will maintain this taiga specific patch for many releases. It's just a hack right now to move forward.

@james the resets for a long time no longer regularly, at least the mailboxes and the instances are still unchanged for over a week. Also gives it a problem with nextcloud which is in an update loop sometimes you get the very current version and sometimes you have to update 2 times up to the current version.

Ah sorry. Yes, it works now. Thanks very much! BTW. I have tried the "impersonate" option and it has a similar problem...

jdaviescoates said: Yep, the most recent rsync back-up into the new folder (rather than the same folder as the rsync backups were going into before the server migration) worked fine too and now I have rsync backups that pass the integrity check - finally! So it seems clear the issue was some file changes that happening during the full Cloudron server migration got rsync confused. Think I may have spoken too soon. Every rsync back since the one that passed the integrity check has failed it again [image: Screenshot from 2026-10-04 13-30-28.png] It's always the Jellyfin app that fails. Plus once also the Mail server again.

We have fixed some of the apps developed by us like surfer, calendearm, mail,.... to gracefully shut down handling the SIGTERM. Will be part of their next releases. So thanks for bringing this on the table good to have that improved!

Thanks, I have fixed the regression.

Thanks, this was an oversight and indeed the task got never refreshed. This is fixed then with https://git.cloudron.io/platform/box/-/commit/6178538a4c4b712b426a8b11eeb6ae8ac5fe9f10