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

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.

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

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.

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

Ok, I understand that. The case which you're saying is different. If anyhow the user doesn't have access to the Admin and just the user account is compromised then he can send emails from that account only and if admin has setup limits over that then the spammer can't go beyond the limits. Limits should be setup in any case and should be controlled by Admin. This is a very important and good feature that needs to be implemented. I hope you understand. Thanks!

@joseph said in server seems to be going to sleep and becomes inaccessible: The browser is local timezone and the server is UTC. You might have to translate the tz . I'm in the UK so I believe at this time of year UTC = local time? @joseph said in server seems to be going to sleep and becomes inaccessible: I recommend uninstall gnome and friends altogether. I have never done this but I expect this won't happen easily since uninstalling a DE is probably not supported . Easiest way is to set up a new server and migrate using cloudron backups. Yes starting from fresh seems the most sensible...but I really cannot understand what has happened (like I am 100% positive I haven't installed packages manually). I wonder if this was something to do with Netcup. Also since this morning, the server seems kinda stable...a bit worrying though. Many thanks for your help. Update: I was able to track the date as to when those packages were installed...and it was when I upgrade to ubuntu 24.04 on 1st Jan 2025. I did that on three other servers without installing a DE so I guess something must have gone wrong when doing this one. But it means the issue I encountered yesterday was somehow due to something else. Maybe with the DNS changes meant the server had somehow network issues and was kept with no activities for a while which sent it to sleep...I don't know.

So it turns out DNSSEC is the problem. Unbeknownst to me, the previous registrar had enabled DNSSEC by default, when I transferred the domain some time ago, the records were not removed when the new registrar updated the nameservers. As they don't have DNSSEC management and my DNS resolver doesn't validate DNSSEC, I didn't notice anything was amiss. Thank you for your help with this!