Cloudron Forum

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

@dynimighti the only issue with the workaround is that you have to reapply it at each reboot of your server … @nebulon would it be possible to add the firewall rule specified in this post (link below) in cloudron to solve this issue with vps providers using dhcpv6 ? https://forum.cloudron.io/post/105840

You are on the right track, the app would inspect the host header to know from which domain the request came in from and then handle it accordingly. On Cloudron you have to set the multiDomain flag in the manifest also https://docs.cloudron.io/packaging/manifest/#multidomain

@mmtrade Not only that! Now I see in your first screenshot from here: https://forum.cloudron.io/post/106182 That in the FIRST line you have added some random chars that also cause errors. [image: 1745563751227-b859b84c-2322-4f6a-aace-c7c88cfcd536-image.png] And now in your latest post: https://forum.cloudron.io/post/106236 You've added even more random char AND the whole docker image string in the first line?! [image: 1745563970716-cb76dd61-cfc8-48c4-82d0-61c4503b4c08-image-resized.png]

Nevermind, I did a rollback and fixed it

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

Hello everyone & @staff , After a few days I can confidently say that the only drawback of my current workaround is that it’s not persistent — I have to reapply it after each reboot. However, once the issue is resolved within Cloudron’s firewall rules, everything should work seamlessly without further intervention.

Yes, I've been doing this for years, you just have to make /app/data friendly enough for apps to find what they need. This generally involves setting a few env variables: HOME PATH (including NODE_PATH avoiding npm i -g) LD_LIBRARY_PATH (less common) other app specific ENVs All of these changes do not affect the running app since it's already running with its own ENVs. So these are great for additional services. Nice work @djxx

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

@basiliolp the forum search is a powerfull tool Welcome to the Cloudron Forum https://forum.cloudron.io/topic/13654/could-not-connect-to-your-mcp-server/

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 .