Backup does not contain the unbound custom.conf .

I'm getting bombarded with redis connection errors causing major lag and it's why the manager isn't working right. I can rename a folder just fine with any other app. MB!

@joseph thanks for looking, it's in the same window/tab that it happens.

Ok, I've solved this for my purposes. Seems like when I try curl -v https://bind.0data.app/CloudronVersions.json from my Cloudron, it fails. * Trying •••.••.••.••:443... * connect to •••.••.••.•• port 443 failed: Connection timed out * Failed to connect to bind.0data.app port 443 after 129437 ms: Connection timed out * Closing connection 0 curl: (28) Failed to connect to bind.0data.app port 443 after 129437 ms: Connection timed out Which tells me there's some issue with loading URLs from the same server. Interestingly, if I find the internal IP via docker inspect <process> | grep '"IPAddress"' and port via docker inspect <process> | grep -A5 '"Ports"' I can call successfully load the file with curl -v -H "Host: bind.0data.app" http://<ip>:<port>/CloudronVersions.json But I have decided it's easier for me to simply host a kind of URL masking thing on another server. Anyway thanks for the help and attention from everyone who chimed in ️

Thanks for reporting, looks like that slipped through but is fixed then with https://git.cloudron.io/platform/box/-/commit/1586a286d85b3e097954c1345e6d19d4b179becb

@mendoksai said: Quick update — I just noticed cloudron-support --troubleshoot was reporting: [FAIL] Database migrations are pending. Last migration in DB: /20260217120000-mailPasswords-create-table.js This is a bug in the tool and not a real problem. It's fixed in 9.1.5.

@ekevu123 said: The Cloudron team can say for sure, but I believe it does - backups don't get deleted when you uninstall an app. I think I used this method before in a different setting. this is correct/

you have not set a value for medialinks ! Or one that is accessible. In CloudronManufest,json. Yeah that was the second mistake. Before, I got the message "Invalid manifest: mediaLinks is empty in manifest" I had a cryptic message like: "Could not resolve CloudronVersions.json from url". In the end, my CloudronVersions was wrong, and the error message before was not helpful. However, the medialinks error message was For this one: CloudronVersions.json needs to be publicly accessible also the Docker image CloudronVersions.json is public, yes Docker image is private - but it works I have the ghcr with credentials registered on the cloudron. So no issue anymore. In case you are interested in an error-message-improval-bug-hunt, I can send you a version of my "broken" CloudronVersions.json via PM - if not - I am happy now

Thanks

In the end I used S3 compatible option to set this up successfully. IDK why I could not get the Scaleway option to work. Thanks all for your help & input

Could you please check whether this applies to the PTR4 record as well? As I hadn’t configured it on the Cloudron – since I was using a relay – I experienced issues with incoming email delivery until I configured it. I then configured the PTR4 record and everything was solved. I know that PTR4 record is related only to outbound, but I want to figure out if there is some relationship on what happened. Thanks a lot

@girish yeah did found a solution, I only did recreate container before updating and it fixed the mysql issue.

I changed nothing, but it is working today. I imagine what is happening is that the upstream storage drops connections occasionally and cloudron simply passes that on to the user instead of having a retry loop in the background. So, I still believe this functionality would benefit from being more robust, as before it would manage 20-50MB per go before drop, and if the thing was in a retry loop it would be able to get the archive out by just resuming downloads. I realise it is annoying having to deal with people who insist on unreliable storage... but it is what we have.

@girish said: @sansguidon might be best to wait for the next release which should be out shortly. This bug is only in rsync and not in tgz. With the manual patch it did work . I'm not sure to understand your advice anyway, for me the backups are a very critical part of if not the most important of Cloudron, so they should not be skipped, and my understanding is that with rsync blocked my backups are local and no copy exists outside of my server, if I'm not mistaken? This seems risky enough and a sufficient motivation to take immediate action, or please correct me if I misunderstood.

@robi thank you. Indeed it does allow me to type a command . My bad (I was waiting for the prompt to blink or something) Case solved I guess

Aaaah, thank you for this explanation!

@girish Perfect thank you

Hello @nozy Please be aware that the ext4 volume option mounts the disk itself, so no need for a custom fstab entry. If you want to manage that yourself in fstab, you should use Filesystem (mountpoint).

Hello @davejgreen @davejgreen said: Is migration of users and email boxes only possible by using the "looking to restore" button for restoring full Cloudron backups? Yes. @davejgreen said: And is that button only available when you first install Cloudron? Yes. @davejgreen said: We have a second server up and running with a newer version of Ubuntu and Cloudron and were thinking about importing each app individually (after backing it up from the old Cloudron onto a backup site hosted on the new Cloudron), but I'm not sure if there's a way to import the users and email boxes? If not, I guess this approach will not work for us, we'd have to use a third site for a full backup. This is not recommended. The new server should be installed with the exact Cloudron version you are currently using. Otherwise you wont even be able to restore the system backup. @davejgreen said: Do we need to purchase another one for the new Cloudron instance? No. Once migrated simply write a mail to support@cloudron.io and inform us and we will switch the licence to the new server. To minimize downtime use the dry-run backup restore option: https://docs.cloudron.io/backups#dry-run-restore This way, you can restore the whole system, without changing DNS records and can validate each app / step manually. The old server stays up and running, serving all the apps, mail, chat etc. After a review of the migration, when ready to switch permanently, go to Domains view and click Sync DNS.