@neki The misconfiguration warning is for your IP and has no relevance for incoming mails. That warning is being shown because Spamhaus is not reponding correctly to the request from Cloudron and Cloudron is incorrectly interpreting that as your IP being blocklisted. It is nothing more than a display error though and should be fixed in the next release. If you are seeing incoming mails rejected due to Spamhaus listing then this is due to the DNSBL checking. The error may well be with Cloudron and how Spamhaus reports are interpreted, but that will be resolved if you deactivate the checks. @SansGuidon Had you removed Spamhaus from the DNSBL checks? I think the issue is (at least partly) to do with changes in the way Spamhaus processes queries (I noticed a lot of errors in the logs before deactivating Spamhaus altogether) and the way Cloudron interprets the results when errors are thrown. I have two Cloudron servers, both running version 8.3.2, but one on Ubuntu 22.04, the other on Ubuntu 24.04. Interestingly, the server running on 24.04 does not show the (false) email configuration error, but the one on 22.04. regularly does. As already mentioned, however, that is just an icorrect message and has no affect at all on deliverability as that will depend only on the receiving mailserver.

I found the root cause of this one. Fixed in https://git.cloudron.io/platform/box/-/commit/73a56830b05909c0a49def222667ad0902076e31 . Thanks for reporting!

My issue is resolved, adding a --allow-other parameter to the mount solved it, thanks @girish and @joseph

Thanks, that solved it!

Ok we solved this, we managed to install the app we wanted (outline.js) It doesn't send email, opening a different thread. Thanks!

Thanks for reporting. This was bug in the container. I have reduced the verbosity to 0 in the mongod configuration for the next release. For the moment, you can simple delete or truncate the log files.

Glad to hear that you got it working! By the way, have you had any luck logging into the HomeAssistant companion app (iOS in my case) using the proxied domain?

@imc67 thanks for reminding. I have fixed this for next release. https://git.cloudron.io/platform/box/-/commit/f48231e309facd375935a2b13f869f4ba176e2c4

@webliska said in Unable to connect to filemanager: connect ECONNREFUSED: Thank you! It worked. But how did it crash? Like, I gave the permissions to the folders? I'm just wildly guessing here, but I think I read somewhere (yes, here) that there is currently a bug whereby changing permissions via the File Manager isn't currently working, so perhaps trying to do it caused the crash

@girish perfect, I'm back in - thank you!

@Shai said in Is it worth it to upgrade to 24.04 from 22.04?: I might as well get a couple extra years before having to remember how to do this again. Shouldn't that be reason enough? 24.04 is already a year old, time to upgrade from the previous LTS.

oh that is true, I forgot about Cloudron 7 not being supported/tested on Ubuntu 24. So then yes you have to first install Ubuntu 22, then restore Cloudron, then update Cloudron, then follow the guide at https://docs.cloudron.io/guides/upgrade-ubuntu-24/

Right, if you lost control of the domain. Switch the Domain provider in Domains view to manual or noop.

@james I have sent the logs in the private message.

@Shai You would need to edit your local computers /etc/hosts file and add in the old IP address of the previous Cloudron install for the domain name that you’d type in the browser bar. Then you should be able to use the hostname to still access the older Cloudron server.

I found that I was using that domain name as an alias for another app.

@nebulon great, glad it's already fixed! Then a start/stop of the app will resolve it.

@nebulon Very cool upgrade to the API Docs since the last time I looked. Like @BrutalBirdie said, one should be able to copy and paste the examples into n8n, modify parameters and run it!

Hello @Shai The second level domain, also known as @ in most DNS providers e.g cloudron.io has a different propagation time then third level domains aka. example.cloudron.io. This could take up to 24 hours or more, depending on the hosters default TTL for the domain or what you've set. Might even be resolved now when you retry it after 7 hours.

@james make sense! thanks for your thorough explanations