@d43m0n1k_sek said in Unable to load dashboard - fresh install: I know this post looks more like a blog And that is totally fine, even more, it is very much welcome. Sharing your experience and walkthrough while having the problem is very beneficial to other users. So please, keep going! I do the same e.g. https://forum.cloudron.io/post/43733

@mouse77 you should be able to just use the domain as it is shown in your screenshot, if you own that domain and can change the DNS records for it at your nameserver provider. For wildcard usage, you need to setup 2 DNS A records as a minimum. One for cloudron.indesigner.net and another one (the wildcard) for *.cloudron.indesigner.net . Both are A records and should point to your server's public IPv4 address.

I finally got to understand IPV6, and now I spoke with Comcast business to set reverse DNS my IPV6 to my.richardapplegate.io then mail will start working again.

@d19dotca said in Shouldn't we get an alert when a service container fails / is unhealthy?: checking so that it ignores any entries of the current Docker networking ranges such as 172.18.xxx.xxx addresses For the moment, I have added validation to not accept such addresses . Ignoring this properly is more complicated (since we have to filter it at apply time) but atleast it won't let you save the blocklist easily .

@robi Thanks—yes, I uninstalled it.

Sure, I was using Orion.

That's it - it was the browser! Thanks for your help, no bug then!

@mrhakash said in Outbound Emails Queued — NXDOMAIN Error and Local DNS Resolution Issue: dig @127.0.0.1 gmail.com mx returns: connection refused You have to check host -t MX gmail.com 127.0.0.150 . Can you also run cloudron-support --troubleshoot for hints?

Thank you, that has resolved the issue!

Perfect @BrutalBirdie .. Thanks a lot Man! What's this error? And how can we prevent this moving forward. Thanks!

It seems to be indeed the long volume names. This also explains the strange connection between setting up a backup and the changing view. Thanks for the explanation. I have not seen this connection...

@flaxxain RainLoop app is long deprecated . Consider using SnappyMail , Roundcube or SOGo

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!

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