@NCKNE added in https://git.cloudron.io/platform/box/-/commit/f78f6634fa29e0ca638f482c8e4f941c885e6301 . It hasn't run through our CI yet, but maybe that works for you already . You can patch server at /home/yellowtent/box/src/externalldap.js .

Thank you for your answer. So I have to figure out how to redirect port 443. As it stands, I can't, but I'll try to find a way, thank you and good luck!

@im-fabian can you reach out at support@cloudron.io ? I think we have debug further with access to the server. thanks!

there are also some posts from @d19dotca a while back about fine tuning spam rules

@joseph thank you - it returns me 127.255.255.254. For all IP addresses I've tried - including 127.0.0.1: host -t A 1.0.0.127.zen.spamhaus.org

@girish said in Ubuntu sub-version not updated?: but be careful of those kernel updates thanks for explaining, I'm on NetCup RS and during the upgrade procedure from 20.04 to 22.04 I remember seeing kernel updates going by and all went fine. I'll think twice before updating especially if it's not really needed.

@RedzzDragon it looks like mongodb is not running . If you click on the logs button, maybe it gives a hint as to why it's not running . There is a very small chance that you are using a server/CPU that does not support mongodb . Modern mongodb requires CPU to have AVX support. If this is the case, the logs will tell you as much. (And to host WP, you don't need mongodb, it's fine if it's not running)

@DualOSWinWiz do you think "Encrypt DNS" in your router mean DNSSEC ? If that is the case, an idea is to just disable DNSSEC in unbound instead of for your domain . https://docs.cloudron.io/networking/#unbound .

fyi: As soon as I have moved platformdata back to the “original” storage, everything works as expected the error disappeared. I also had to move the appsdata & boxdata back to get a fully functional Cloudron instance again.

@humptydumpty said in Email sending broken after updating to 8.2.x (due to IPv6 issues): Hetzner doesn't save the entry? This. Hetzner just says it's invalid.

Do you have the "Enable proxying" flag enabled in the Domains -> Cloudflare configuration ? This whole discussion only applies if you have that flag changed. Cloudron does not touch the proxying flag if that is disabled. When enabled, it will set the proxying flag when adding new cloudflare DNS records. This is set only when adding and in all other situations that flag is left untouched . It does this for both ipv4 and ipv6 records.

@titi49600 thanks for the update. Did you have to run any command to adjust the mtu? If you post it here, it will help future readers.

No need to delete, just mark as solved . Will help future users who might hit the same (even if incorrect or unreproducible) issue.

@girish When we initially changed the default data directory and restarted the entire Cloudron server, something went wrong. As a hotfix, we applied some basic permissions, which probably broke PostgreSQL. However, we don’t know which permissions were wrong, as I didn’t log them at the time. This morning, we tried changing the default data directory again, but instead of restarting the whole Cloudron, we restarted all services individually, and this time we didn’t get any errors.

@IniBudi @nebulon I can confirm that problem is not related to Cloudron, after I did some sending tests.

The number are just some pragmatic values. Empty dirs - 50000 , executables - 20000 and symlinks - 20000 . If it exceeds these, it will error.

@girish I am currently using iDrive E2. Yes, they have lifecycle policy editor. I'll have to take a look and see what baseline or default settings to setup. Thank you!

@JohnBee said in email server broken after update...: snapshots to fall back-on You restored the entire server to a previous working state?