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

Ok - Here is the reply I got from deSEC: This is caused by the fact that hundreds of clients send updates at xx:xx:x0 00:00. We only accept about 60 simultaneously processed updates, so most of them get this error. To prevent this, we recommend randomizing the update time, or at least set it to some non-special time manually. Looking more closely at the cloudron logs and despite the somewhat random nature of the change of public IP when not having a fixed IP address, it looks like Cloudron triggers DNS checks/update almost exclusively on xx:xx:x0 [image: 1778517452854-5487c5c9-d317-47c8-aff3-5b33b4cd7b13-image.jpeg] Could it be possible to randomize this further ?

Hello @cylon Always happy to help.

So Cloudron will always require a backup for auto-updates, there is no way to skip that unless you update manually.

@necrevistonnezr said: Also: [FAIL] Could not load dashboard domain. Hairpin NAT is not working. Please check if your router supports it https://docs.cloudron.io/installation/home-server#nat-loopback My PVE physical host is in a datacenter and all access to the apps are either public or private over VPN from my home site. I use split DNS where it matters which is preferable to NAT reflection in my use cases. Cheers Leigh

@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?