I was under impression I'm quite clear... I don't think the decision made by authors correct. I'm forced to do the backup, even though there is no technical requirement for that. I'm forced to do the backup the way authors want, even though I have my remedies. As a result, I've just found out one Cloudron instance seriously out of date with a Docker security vulnerability in it. Just because authors decided that I have to have a backup to have automatic backup - to have my systems up to date. Not sure I follow that...

If the second contains the System backups it would include those of stopped apps, where a backup was made there (since otherwise the backup data simply wouldn't be there). But I agree this is not great to migrate. I guess for now you would have to start the app, make a full system backup on the scondary backup site and then stop the app again. The code for retrieving backup data for integrity check depeneds on format and storage type. Memory consumption is hard to predict, so presumably S3 with some kind of data on that storage just gets it over the 400MB

@girish Thanks a lot - Much appreciated!

glad it worked out in the end, when too many things fail all at once it is often a hardware/virtualization issue

Hello @cylon Always happy to help.

@sebastienserre Thank you. Your input on this error was very useful!

@jakomo-freshi Yes, mysql 8.4 will be part of next Cloudron release (9.2) . I just pushed the changes to our code base. Any guidance on the planned upgrade path would be appreciated. The database upgrade is all automatic.

Thank you @james . Well noted. Best regards

@nebulon Thanks for this - I can confirm that this is an issue with the S3 endpoint and a faulty server app release not accepting upload and throwing HTTP/1.0 400 errors. If I may: The error message about MD5/checksum from Cloudron throw me off for a bit, not directly pointing at a lack of communication with the remote server. Reverting to an earlier release on the S3 endpoint fixed the issue.

@Teiluj yeah, I have noticed that too. We don't want to lock it too much either (app location, footer, usernames, group names, etc - lots of scope to put offensive things).

Hello @nicholasfrank Always happy to help.

Hello @msbt Documentation updated.

The fixed cli version is published now

@tobiasb good catch. I think because it depends on resolvconf, it ends in errored state. I will disable that service explicitly

Solved via support

Hi, please check #5. We had split the LDAP Systems. So we cant get feedback on this. Greetings, Christian

Hello @timconsidine I have posted the announcement here: https://forum.cloudron.io/topic/15442/ubuntu-24.04-kernel-6.8.0-110-regression-affecting-cloudron

Hello @stirchley.coop I also had a look and redacted some content. Also, the content that was not redacted are not critical since Cloudron ensures that non of the Cloudron services are accessible from the internet. But if you still feel more comfortable to delete the whole topic, I can do that.

@davejgreen said: I tried again with a fresh install of Ubuntu 24.04 @davejgreen said: Maybe different versions of Ubuntu do it differently? I think the only time I've had issues with migrations was when the provider of my VPS (I think it was Netcup) began using stripped down versions of Ubuntu that had stuff Cloudron needs missing. But I'm guessing you're pulling Ubuntu directly from Ubuntu?

Hello @orezbodajoy The dashboard issue is related to the latest ubuntu kernel having a regression. If you are running 110 which has a bug . See https://forum.cloudron.io/topic/15265/unusable-application/39 If you'd like to try, you could apply this patch manually https://git.cloudron.io/platform/box/-/commit/bffc97ab2fedb06100bc507abd0f8b42d343ea6e and then systemctl restart cloudron-firewall. This should solve the issue.