Hello @imc67 Sounds like an interesting project you got there, and I would be interested to have a look. @imc67 said: To make it even a community app is totally out of my knowledge and comfort zone, moreover updating the app and being (feeling) responsible for others is too much. That good part about community apps is that they come with zero responsibility. It is up to the maintainer of a community app to maintain, support or improve it. I know that this statement might not do much about your feelings which I can fully understand. Since your project is security related, having this burden on your mind for others that might use it, is much. But, I would be happy to have a look and give my feedback.

Great catch! This is fixed for the next release with https://git.cloudron.io/platform/box/-/commit/5e2b531d9bc4fc180395b58c704b1ee083b0aa5f

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

Hello @robomod Your Ubuntu: focal 20.04 and Cloudron 9.0.17 are severly outdated! Ubuntu 20 EOL was May 2025 so almost one full year of no security updates. The issue you describe stems from not beeing not up to date. Similar to the topic https://forum.cloudron.io/topic/15533/skip-older-cal-packages The linked topic also has instructions how to update Ubuntu and Cloudron.

Hello @anthony-tran Can you restart the uptimeKuma app and provide us the logs from the web log viewer pasted to https://paste.cloudron.io/ ?

Hello @flexplore Can you please post the output of systemctl status docker.service and journalctl -xeu docker.service so I can take a look at the log to understand why the docker.service is not starting correctly?

@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

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