Somehow, this issue resolved itself overnight. I mean yea nice, it solved itself, but I wanted to understand whhhyyyyyy. Anyway. #SOLVED

@ccfu yeah, I tend to agree. But I think some people simply don't like looking at such things (similar to why they do fail2ban for repeated ssh attempts). So, I think blocking the IP mostly helps if the raw logs are annoying Note that we don't put this in the eventlog precisely because people get annoyed when looking at it in the UI...

@potemkin_ai here - https://contact-center.spamhaus.org/ . Might be worth asking them why it thinks your server IP is an open resolver .

Oh, maybe you mean https://developers.cloudflare.com/dns/nameservers/custom-nameservers/zone-custom-nameservers/ i.e vanity name server names ? I thought you were hosting your DNS server locally.

For the future generations: better do ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf to avoid messing with system's and cloudron settings Or use netplan's WireGuard capabilities.

Extra analysis. Did this issue really just come up after the upgrade to 22/24? System Upgrade timers: 2025-02-19 14:33:55 Linux version 6.8.0-53-generic (buildd@lcy02-amd64-046) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #55-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 17 15:37:52 UTC 2025 2025-02-19 12:33:55 Linux version 5.15.0-131-generic (buildd@lcy02-amd64-057) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #141-Ubuntu SMP Fri Jan 10 21:18:28 UTC 2025 2025-02-19 00:33:55 Linux version 5.4.0-205-generic (buildd@lcy02-amd64-055) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.2)) #225-Ubuntu SMP Fri Jan 10 22:23:35 UTC 2025 [image: 1740653073505-317cc732-dca2-4b64-a71f-7724cd861fa7-image-resized.png] View of the whole month of February 2025. Zoom to 2025-02-17: [image: 1740653226664-63aafc17-2eb7-4361-9f55-80e7991030cc-image-resized.png] Yep, this looks very conclusive to me. This issue is only apparent in Ubuntu 22/24 with the non-fixed syslog.js

@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

@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.