Thanks @Gengar . I have put it in the code - https://git.cloudron.io/platform/box/-/commit/7f87af5a0827af431a3ecb8bfca4bc693c3707b0

Everything seems okay at the moment... If i have any more queries I will surely come back again @BrutalBirdie

Cloudron will call the app locally by the URL http://${app.containerIp}:${manifest.httpPort}${manifest.healthCheckPath} so by local container IP at the specified httpPort and healthCheckPath specified in the CloudronManifest.json. Any response with a 200 status code will be accepted.

@daixiwen Even better, they HAVE already allowed for specific backup persistence: [image: 1745912539127-704862fe-911a-4719-960b-94f162df1e64-image.png] I'm going to go try that out. The wording definitely makes it sound like at least one backup, "the latest backup", should be available, but my point still stands. As perfect as Cloudron is, I've bumped into hiccups with backups myself, too. And so I pay close attention to them. In the situation you mentioned, you can either let your stopped app backups keep disappearing while you wait for a solution, or you can realize it needs a bit of your help. EDIT: I see you wrote " I'll now try having at least one manual backup set up as persistent and see in two says if it's still there, but ideally this should occur automatically." so good on you for taking it into your own hands. Let us know what happens!

I had this issue for a long time with Cloudron, with both Hostinger and Hetzner as DNS/NS managers. I just check everytime those issues occur of course but I tend to just not trust anymore any Cloudron notifications for Emails config

Think of each as a SaaS, I think the "correct" approach is to upload files in one app. That app exposes an API. Other apps then consume the photos API to do whatever . The whole sharing files approach is a relic of times when files were hosted on the same server and no sandboxing. But modern deployment/orchestration tech uses sandboxing, containers, docker compose, multiple servers . In such situations, sharing files assuming it's all code runs in same file system doesn't work well. app permissions/owner issues aside, most apps also have a database to track files and store extra metadata . If you remove and delete files from the filesystem without the app's knowledge, it all breaks. apps have to be written with all this in mind and most apps aren't written this way . lychee/nextcloud etc all have their own db and cannot share fs with others.

I changed the mail server here. The DNS was updated and no SSL errors.

Is this happening midway and has there already been some data restored at /home/yellowtent/boxdata/mail/... or is this the first file which fails there? Also what are the permissions and owner for /home/yellowtent/boxdata/ ?

Nevermind, I did a rollback and fixed it

@msbt Great, already got it running. Thank you!!

Seems like a few issues intermixed here. For a start userland proxy in docker should be false. This set however in /etc/systemd/system/docker.service.d/cloudron.conf by the cloudron startup script. On port 172.18.0.1:3003 the Cloudron docker proxy addon would listen, so this also hints at docker having an issue with the network bridge it supposed to have created. Otherwise most likely if you had a disk being 100% full situation, all bets are off, unfortunately. This is not so much related to Cloudron code but other linux services we use like mysql and docker

@nebulon I’m wondering… since Cloudron depends entirely on Docker networking to function… is there maybe room to improve the IP blocklist checking so that it ignores any entries of the current Docker networking ranges such as 172.18.xxx.xxx addresses? It feels to me like there would never be a use-case to block those, and while we certainly need to use reliable IP lists (lesson learned, haha), I also wonder if this feature should be improved in the future to ignore any private IPs or at least any Docker IPs.

Thanks to everyone for the responses. I fully understand the backups now and have reported to my board that it's indeed production ready for our organization.

That worked @girish cloudron-support --troubleshoot found a certificate which does not exist and so removed a conf file nginx started promptly After which the Cloudron apps could be restarted just fine Thank you once again for your help

Could you please convert that thread into a request to remove 'Cloudron' from the mail templates as well as from translation files, please?

@nebulon I appreciate your advice. The backup server is not on the same location as the cloudron server. It isn't even on the same country (like I do with all my backups). Maybe I wasn't clear: the server has an OS disk (nvme) and a HDD for backups. The mount I showed is the HDD disk mount. It was just to check if any filesystem mount options were needed to improve performance. Thank you all.

We finally got down to this issue. Problem was that particular instance had a lot of backups in the db and we only took the first 1k backups into account for purging. Fix is coming with next release. If you hit this issue, send us a mail to support@cloudron.io so we can apply a temporary fix.

It was not fail2ban - it was IPv6 connection which is failing, as IPv6 disabled (to ensure mail works well). Hetzner's supported provided a very quick and efficient verification / troubleshooting step: ssh -vvv -p 23 user@server - hope that will be of use for anyone else in the future.

I will close this for now since it's not meant to be run directly . We can continue in the other thread or we can open a new thread .