@girish Is this use case covered in Cloudron 9?

@nostrdev So glad you listened when we chatted about that too! Welcome.

Maybe your system/network from where you were trying to access your server had some long DNS cache pointing to the wrong IP. Glad it worked out in the end though.

Sweet, thanks. I added it to my start script.

@robi I only added the recommended commands: 0 13,23 * * * rm -rf /app/data/public/wp-content/cache/* > /dev/null 2>&1 0 13,23 * * * rm -rf /tmp/magick-* /tmp/imagick* > /dev/null 2>&1

Fixed in https://git.cloudron.io/platform/box/-/commit/e390a56f055a3e71ed324485d7a9ce7e441e1e66

@girish It's a LAMP app with apache configured to point to another directory.

Thank you all! the issue was the unbound service not working and also my email delivery issue too.

@james I could not get it working at all, so I switched to use Sendgrid instead since we have an account and that is working fine. The issue is that I am using Cloudron as a VM inside of Truenas Community 25.04.1 and it is Truenas causing the issue and I would have to make some major changes and I don't want to affect the File Server side by doing this.

Can you SSH and run cloudron-support --troubleshoot on the server? This should give us an idea of DNS issues etc.

Looks like your server has a wrong ipv6 outbound setup. Cloudron does not configure the network interfaces of the server, so this maybe a misconfiguration from your server provider. This happens with some VPS providers sadly still. First step would be to figure out why a plain curl to a ipv6 cannot connect. Your server provider should be able to help you out there. If this can't get to work, you may disable ipv6 in the Cloudron dashboard and also remove the AAAA record again.

@vjvanjungg not 100% sure but we got a similar report on Support and I replied there. The mail server is not responding after the initial SMTP EHLO. Can you check the raw mail server logs - https://docs.cloudron.io/email/#event-log ?

Closing this topic due to inactivity

Yeah, I don't have the original, because I repaired this manually already, but that is basically it - the CNAME was a standard of Porkbun pointing to their server. Well, it's solved quickly, albeit manually.

This was implemented just last week here - https://git.cloudron.io/platform/box/-/commit/0fa281083e4dbf250b400a1e2f1dcc4ec70ae372

Apologies and correction. Cloudron's functionality works just as intended. The problem is in docs in major sites and hence chatGPT as well (which I used to troubleshoot that). All of the docs, except for NameCheap (thanks, guys!) says that the correct way to combine crt files - is just do cat .. > final.crt which lead to one problem: -----END CERTIFICATE----------BEGIN CERTIFICATE----- On the line 37, which, absolutely reasonably, brakes any SSL parser. Correct way to join CRT files is: cat STAR.*.crt > ssl-complete-bundle.crt && echo >> ssl-complete-bundle.crt && cat STAR.*.ca-bundle >> ssl-complete-bundle.crt And you can check if it is valid than with openssl x509 -noout -in ssl-complete-bundle.crt -checkhost test.`basename STAR.*.crt | sed -E 's/^STAR\.([^.]+(\.[^.]+)?)\.crt$/\1/'` Guess, it might make sense to document it.

Closed due to inactivity

Closed due to inactivity

Did anything change @hakunamatata Also, Cloudron 9 might resolve this.

Closed due to inactivity