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

@murgero thank you!

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

@onlybro must be some caching somewhere Are you running Linux? If so could simply edit your hosts file

@nebulon said in SSHFS Backup Mount again not working with version 6.3.6: @amahr sorry the command to restart/remount would be: systemctl restart mnt-cloudronbackup.mount It would be nice to have this exposed in the storage UI

@girish said in Client user locked out of SFTP?: explicity - Services -> SFTP ahhh ok thanks!

@comtop1 Did you get this sorted out? Usually, I have seen disabling and re-enabling cloudflare proxy fixes things. Seems to be some in Cloudflare SSL proxy caching.

@humptydumpty thanks, good to know. We don't automate Mailgun relay yet, so we are not affected.

@marcusquinn well spotted, this was a translation quote escaping issue and is fixed now in our dataset in weblate.

@sock_check_foo hard to say what might be the root cause here. If you want us to take a direct look at it, please enable remote SSH support and send us a mail with your dashboard domain to support@cloudron.io

If you like you can send us your domain name to support@cloudron.io and we can check if it's something on your side (i.e. some browser caching issue) or if we see it as well.

@girish ah alright, that sent me down the right path. needed to switch from encoded body to raw JSON and that cleared it up. thank you!

️ PERSONAL OPINION ️ Don't use Strato. At first glance they seem like a good hoster, but they are not. Even if their pricing model seems competitive. For basic stuff like a single Wordpress or something it might be fine, but I would not entrust them my systems. I had so many customers throwing Strato out of the window in a fit of rage. Just my personal opinion based on what I have witnessed.

If you have a VPS elsewhere, you can open an ssh tunnel to it pointing a public port on the VPS to the internal cloudron install to get to the interface. That will cause other problems since it's not reachable on port 80/443.