@humptydumpty said in Nextcloud is very slow on Linode: BTW, look into Syncthing (file sync), Wekan (kanban), Vikunja (kanban), and Matrix/Element (instead of Nextcloud Talk). All available on Cloudron. I certainly agree that Nextcloud can get bloated and even unstable when too many plugins are enabled. I use it heavily for file storage and shared folders, but for almost nothing outside of this. And definitely the other apps are worth exploring.

@girish That sounds great, if there was a way to access the content of what the app was trying to send that would be good enough for me, no specific need for it to be in a mail format, json, or any other specific data structure.

@jjhill Let us know when Cloudron has been installed correctly and is running well please.

@avatar1024 you can send the logs to support@cloudron.io Given that the backups are working fine on the hetzner instances, this indicates an issue during backup with the mountpoint. Maybe the connection to the storage box sees some hiccups. Those issues are generally quite hard to debug since they are often on the lower system levels Maybe you can also reach out to netcup/hetzner if they see any interruption between their networks during the time your backup failed last time.

@nebulon Thanks a lot for your quick support. It works now.

@sangroot this unfortunately means that your server got an IP with a bad reputation ending up in the blocklist. To explain, those IPs are constantly reused and it could just be that either this IP itself was used by a spammer in the past or that some other IPs in that IP block might have been spammer IPs. This is not unusual though and it takes a bit to get IP reputation up and manually removing it from blacklists by appealing is the first step in this case. If you need to deliver emails reliably from the start, you may consider using a mail relay configured through Cloudron for some time until you are off of all those blocklists.

Looks like we have to investigate again, but a similar issue was fixed in that version, apparently didn't fix all the cases.

@girish Belated marking as resolved for anybody looking in future. girish did some remote ssh support magic and solved the problem.

@nebulon great to hear that it was already reported and fixed! I didn't get any suggestions regarding similar topics, so I thought it wasn't reported yet.

@vladimir-d DBeaver Database Dashboard? Or you thinking longer timeframe and more detail?

https://www.maketecheasier.com/zram-zcache-zswap/

I have made a fix here - https://git.cloudron.io/cloudron/box/-/commit/949b2e2530283e1690656c2dd417e00a78b3251d . I am still monitoring @chaitanya's server to see the impact the change has.

@fortytwo we haven't done anything on your setup, since we don't even have access to your system. I suspect from the logs that there might have been some initial docker hickup on your server, which was resolved by the reboot.

@timconsidine said in Moving Cloudron to new server : stop apps?: that I didn't set the PTR record in the new VPS provider until I started the migration I ran into exactly this problem the last time as well

This actually turned out to be a postfix issue, as @youhost already initially suspected. So the mail container would not start, since postfix was running and hogging port 25. The solution in this case is to stop and disable postfix: root@my:~# docker restart mail Error response from daemon: Cannot restart container mail: driver failed programming external connectivity on endpoint mail (80745a182e99c96ca09dcb0a3775c919d7cd6907ba060410d860b2bd5929440e): Error starting userland proxy: listen tcp4 0.0.0.0:25: bind: address already in use root@my:~# systemctl status postfix ● postfix.service - Postfix Mail Transport Agent Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor preset: enabled) Active: active (exited) since Sun 2021-08-29 20:16:02 CEST; 2 days ago Main PID: 1654 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4653) CGroup: /system.slice/postfix.service Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. root@my:~# systemctl stop postfix && systemctl disable postfix Synchronizing state of postfix.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable postfix root@my:~# docker restart mail mail root@my:~#

The tool is a helper we have created to ease migration towards the apps we have packaged for Cloudron, I don't even know IceWarp and it was thus not tested against this. Maybe you can run the command again with: DEBUG=* cloudron-davsync ... to get more information on what might go wrong as I can't reproduce or test this locally.

@nebulon no problem at all. The topic itself is quite large so individual bits are easy to miss. A script could be a nice idea as most users will probably not be comfortable with doing sql updates manually. But such a script can probably turn into something complicated quite easily. The flow that immediately comes to mind would be doing in ldap server on the ldap backend and comparing it with the users that Cloudron already knows. Followed by the possibility to switch auth for any users that are primarily managed on Cloudron, but exist on the ldap side as well. Probably easier to do it in javascript than it would be in e.g. bash.

To conclude this, it was a memory issue. The instance as a whole was a bit overcommited. If the backup task is idle, it won't consume any memory. Also Cloudron does not reserve memory based on the limits set, neither for backup nor for apps. The limit is just to avoid rouge apps or the backup task to bring kill other apps.