Hello @romu79230 Both of your existing servers are extremely outdated. Cloudron version 7.3.6 https://forum.cloudron.io/topic/8268/cloudron-7-3-released Cloudron version 7.4.1 https://forum.cloudron.io/topic/9179/cloudron-7-4-released Both from 2022/2023 and did not update Cloudron since then. @romu79230 said: Given these constraints, is a migration from Cloudron 7.4.1 to 7.3.6 technically supported, or would upgrading the destination be necessary before restoring Nextcloud? Yes and No. Yes you should upgrade your servers to the latest Cloudron version. Is it needed to test a migration from server A=>B, no. When you install a new Cloudron server, with the latest Cloudron version you can install Nextcloud version 4.17.0 and then import the backup config from the production Cloudron. This way you can test a migration from the production Cloudron server 7.4.1 to a fresh latest version Cloudron. I want to clarify and understand the following: @romu79230 said: Source: Cloudron 7.4.1, running Nextcloud 26.0.1 (package 4.17.0). Destination: Cloudron 7.3.6. Why would you want to migrate a Nextcloud app from one outdated Cloudron to an even more outdated Cloudron?

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

This is now fixed for next release with https://git.cloudron.io/platform/box/-/commit/d122f06a05803f2cb71a51d5e9a7f078202ca71b

Hello @dualoswinwiz Thanks for providing the output of the troubleshoot. Your Cloudron version 9.2.0 is outdated. The latest Cloudron version is 10.0.5, and we are moving towards Cloudron 10.1. Since Cloudron 9.2.0 many improvements and fixes have been implemented regarding Passkeys. Please update your Cloudron to the latest version so we ensure this is not just an outdated Cloudron issue.

@james Well, looking at the logs, it’s actually running fine. Even though the UI dashboard looks stuck at 5%, I managed to successfully update it to version 10.0.5

@humpty Not just you, but usually if you refresh the page, it goes to 0, so probably a caching thing.

Hello @archos This is already fixed in the upcomming Cloudron udpate.

Hello @jayonrails The only instruction was: james said: To fix this please run the following command from your ssh root/sudo session: bash /home/yellowtent/box/setup/start.sh But you also did run: systemctl stop box apt install mysql-server systemctl start box From the log it looks like everything worked out correctly. Please make sure to carefully read provided instructions in the future since you did run commands that where not instruced to be executed. Please also read https://forum.cloudron.io/post/129886 which explains that the binlogs might not be purged correctly and how to clean it up. Otherwise some binlog files might remain and block some diskspace.

@msbt previously, forwarding feature did not use sieve rules. It was implemented in Haraka, so this setting was not needed.

Hi @james - I also received a response today. Hope its the same group of people you talk to I let the AI compare the responses: Key differences between response I received and from your summary: Root cause: GC overload vs. synchronous unlinking of old object data. 504: Both say the proxy times out after 600s while backend processing continues. HEAD vs. GET: Response I received assumes processing may still be ongoing and no data loss; from your summary says the affected data is unrecoverable. CopyObject / MPU: Covered as under investigation in response I received; not addressed in your summary. Fix: General GC optimization vs. explicitly decoupling GC from CompleteMultipartUpload. Anyway - looks like we helped uncovering the root cause