This is fixed in the new UI for Cloudron 9

Usually, the issue here is that the SFTP service is not running . Services -> SFTP -> Restart maybe?

Looks like Cloudflare is interfering here and changing the data in transit? You would have to contact Cloudflare about this, but I have no high hopes that this would get anywhere.

Thx for the hint. Will see what Hetzner support has to say.

@SamGreenwood I would run the troubleshooting tool for a start - https://docs.cloudron.io/troubleshooting/#troubleshooting-tool

Just recheck... and I can do this. Was 100% it was not possible. Might have been an "between my ears" problem, sry

@wmlutz said in Outbound SMTP (Transactional Email) Stopped Working - Invalid login: 535 Authentication failed: @jdaviescoates got it! It was the IP allowlist. Glad to be of assistance @wmlutz said in Outbound SMTP (Transactional Email) Stopped Working - Invalid login: 535 Authentication failed: mailgun's transactional email cost which is cents/mo. I don't think I've ever paid anything yet as I've not yet gone over the 1000 free messages a month or whatever it is...

@potemkin_ai said in can't install cloudron due to unbound issues: It seems like unbound is only used for SpamHause and during setup. If the setup issue will resorted, only SpamHause issue will remain. It's also used for DNS propagation checks (during app install, change location etc) and also verify validity of DNS records for Let's Encrypt. We cannot rely on caching resolvers because they would cache not found (NXDOMAIN) entries for very long periods of time. The recommendation is to keep all the outbound ports open - https://docs.cloudron.io/security/#outbound-ports .

@Kubernetes Yeah this is specific to the Nginx Ingress Controller which runs on Kubernetes. It won’t be related to Cloudron at all since Cloudron doesn’t use Kubernetes. Cloudron won’t be vulnerable to this.

It did not change earlier, but now hours later it seems to have. All my instances were fine, just the demo server seemed affected like it was possessed by someone

@nebulon I think it's important to highlight how impressive this actually is. A DB upgrade is no small feat for one app, let alone 60-80 apps and multiple DBs that many Cloudrons here run. Then to jump across two DB version upgrades, all while seamlessly restitching everything back up so apps function properly. Traditionally there would be a team of SREs doing this for a week. Yet it happens in a few hours if not minutes. So there will be some red timeout messages and UI glitches while the process is going on (the red messages were waiting for me this AM while the system upgrade happened over night as I left my dashboard tab open), however with some patience and understanding everything comes back up as if by self-healing magic. Sure it could be more polished (how about making a browser refresh after a successful upgrade to clear all the red messages?), but once you know, it's just more important to be in gratitude that it all just works and business continues as usual. I for one appreciate this magic and hence the makers of this wonderful self-hosting system from the time I first met them during a meetup in Silicon Valley, CA. Cloudron gives me TONS of time back, which is also why I can take the time to write about it, run fun experiments, and not have to be stuck troubleshooting standard app deployment woes. Thank you Cloudron & Team for another seamless upgrade and intangibly so much more.

@perelin the docker usage is reported searately (the second line in your screenshot). It's around 20GB. This seems reasonable. The graphs numbers from du are not accurate when it comes to docker . You have to use docker system df . Looks like the space is being used somewhere else. Did you happen to use another backup location previously ? I guess the only way to find out is to run du on each folder starting from root

@joseph You can go ahead and close this thread. Yes, I did install the same version as my backup, but unfortunately, that didn’t help. In the end, I had to reinstall the server completely and upgrade to 8.3.1 again. It’s clear that backups need to be properly saved. Thanks for your help anyway.

Maybe. But I think I'll just take the extra GB into account and see dynamically if and when issues arise. So far, nothing has been missed.

@jdaviescoates said in URGENT: In a post on an originally unrelated thread about IPv6 issues @Gengar posted this link https://www.spamhaus.com/resource-center/successfully-accessing-spamhauss-free-block-lists-using-a-public-dns/ which I think explains what's going on with all these false positive spamhaus issues people are having: The TL;DR seems to be: fill in this form https://www.spamhaus.com/free-trial/sign-up-for-a-free-data-query-service-account/

Setting default_client_limit = 1500 fixes the warning . I have put this for next release.

Turns out the mysql service wasn't starting, not too clear what the root cause was, but rebuilding it made it work again.

Thanks, Looks like IPv6 is not on by default on Hetzner.