Hi,
The issue is fixed now.
I backed up /etc/docker/daemon.json, deleted it, then ran:
systemctl daemon-reload
systemctl restart docker
Docker is now running again and Cloudron/apps are accessible.
Thanks for your help!
@joseph thank you so much! What a wild ride this was - I found the smoking gun by checking package manager logs:
On 2026-03-29 21:23:20 I installed prometheus-node-exporter to ship metrics to my Grafana monitoring stack - apparently the workflow also installed iptables-persistent which installed netfilter-persistent as a dependency. why, I don't know - but lesson learned.
Hello @tyren_bm
That is great to read!
On another cautious note from me, Ubuntu 22 will be EOL May 2027.
I know this is still one year into the future, but time is fleeting.
You might want to upgrade your Ubuntu 22 to 24.
Since Cloudron version 10 will also come with support for Ubuntu 26 this would mean that you'd only have to upgrade from 24 to 26 and not 2x versions when the time comes.
@sponch it's possible to slow down but we have to know what the rate limit is. I cannot find anything in our docs about this. Do you have happen to be in touch with their support?
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
@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.
@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).
