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!

Thanks @girish for the changes in the docs and letting me know. I will take a look as soon as the time allows and may get back to this topic at a later date.

My bad. Sorry

I use uBlock Origin and have never had a problem.

@IniBudi there's many threads in their forum if you speak german. Like https://forum.netcup.de/administration-of-a-server-vserver/vserver-server-kvm-server/9565-ipv6-einrichten/ https://forum.netcup.de/administration-of-a-server-vserver/vserver-server-kvm-server/17978-verbindung-über-ipv6-nicht-möglich/ . Since, I don't speak german, I am quite lost in that forum.

Seems like a connectivity issue. I assume you can connect via the browser. Is your system using a http proxy or anything like that? Does curl https://my.domain.com work ?

@scooke I wanted to clarify my concern about this issue. Previously, after a system reboot was completed, the "reboot" button in notification would automatically fade to grey and disable the reboot button. This functionality appears to have changed (button remains clickable and red). The color difference you mentioned wasn't actually my concern. At this point, I understand this is the new expected behavior, so I consider this matter resolved.

Well, apparently the only way to "fix" this, is to docker stop the yellow services Mail / Mongo / Postgres / MySQL and then restart them in the dashboard and they start up succesfully, and then you can start other apps that have been stopped.

Thank you the problem is solved.

@MiddleEndian said in How to set-up Firewall and/or Proxy to protect my Cloudron instance?: What worries me is that, while having great respect for the Cloudron project and product, maybe just deploying Cloudron "as-is" in a VPS We have plenty of docs and technical notes around this - https://docs.cloudron.io/security/ . If you have specific concerns, please open separate threads and we can discuss.

Glad it worked in the end. Otherwise for reference please follow the instructions at https://docs.cloudron.io/troubleshooting/ to troubleshoot this.

@jayonrails sounds good. Otherwise, if both commands work and things are still failing, please send a mail to support@cloudron.io to debug this further. Can't see how it fails.

My problem is solved now using this command: sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv Thank you DeepSeek hehe