Many thanks, all. I missed that bit of the documentation. I'll definitely backup; I'm running on bare hardware, and didn't even do myself the courtesy of running Cloudron in a VM. I may... use this as an opportunity to change that. Either way, this is all I needed. Thank you!

@girish moreover, the package.json on my WS indicates the version installed as being "version": "5.9.0"so then I still tried from the git directory and I still get: No image found, please run `cloudron build` first or use --image Now, when I try without the git to the repo then I get: App repair error: No CloudronManifest.json found Ho my...

Unfortunately, the browser does not give us DST offset information to display. Only the UTC offset.

@RazielKanos yeah, you will have some down time when migrating. If apps don't change, then you can avoid downtime by restoring using 'dry run' - https://docs.cloudron.io/backups/#dry-run . Once restored on new server, just change the DNS. This way you won't have downtime but with the caveat that you will lose changes that were made to the old server since the backup that was restored on the new server.

@humptydumpty updated ^^

It did turn out to be a DNC issue which Joseph at Clourdon support fixed and then created a backup.

@senthilkumaran https://github.com/TryGhost/Ghost/releases . there were 5 releases just this week. You can change update schedule in the settings -> update

@Beardmancer said in Failed backups and email config issue since 8.0.3 upgrade: I decided to go ahead and try adding this to /etc/systemd/resolved.conf since it's easy enough to comment out. DNS=8.8.8.8 1.1.1.1 After doing that and restarting the service with systemctl restart systemd-resolved, things seem to be working correctly. The file /etc/resolv.conf lists nameservers now and a manually-initiated backup just completed successfully. Thanks for the hlep @nebulon ! In the future, is there anything I should look out for to avoid this? I don't know what caused it. Maybe it was the 8.0.3 upgrade, or maybe it was an Ubuntu update? I think I rebooted Cloudron for the latter recently. If there's a configuration I might have setup wrong, I'd love to correct it.

@cocam123 Cloudron does not support installing external software as such. With that warning, https://docs.cloudron.io/networking/#whitelist-ports will help you expose the port. Cloudron has it's own firewall written on top of iptables and does not use ufw.

Thank you!

@imc67 8.0.3 is needed

@harryz A way to migrate the data is: Create a backup of the app Install a new app instance with Cloudron user management Import the backup into new instance . https://docs.cloudron.io/backups/#import-app-backup Please double, no triple check the user management setup after import. The reason we don't have an easy way to change the SSO is because each app acts very differently when moving auth providers. Especially creation of default accounts, admin accounts, registration etc is all very app specific.

Thanks for the update, I am glad to know it is fixed.

Sorted out on support. This had to do with some efi package blocking apt updates and thus the update stopped mid way.

Fixed in support as outlined in https://forum.cloudron.io/topic/12300/how-to-change-dns-settings-of-my-server/18

This was because the upgade to mysql didn't complete. apt --fix-broken install completes the upgrade. I guess ubuntu upgrade was somewhat midway? I think https://docs.cloudron.io/guides/upgrade-ubuntu-20/#post-upgrade (though the server was already in Ubuntu 22). After that the update worked.

@corevoid I guess this is dup of https://forum.cloudron.io/topic/12327/ldap-not-starting-after-8-0-3-upgrade ?

@ramiroro If you do systemctl restart box, you will something like this in box.log 2024-08-20T19:07:19.792Z box:directoryserver starting server on port 3004 lsof will show the listen # lsof -n -i :3004 | grep LISTEN node 78452 yellowtent 26u IPv6 517617 0t0 TCP *:3004 (LISTEN) check the rediect from 636 to 3004 # iptables -t nat -L | grep 3004 REDIRECT tcp -- anywhere anywhere tcp dpt:ldaps redir ports 3004 test with telnet my.domain.com 636 . Note that if you are behind Cloudflare this won't work.

@girish One thing to note, all stopped apps where not imported through the restore method even tho they had backups retained with them. We are still trying to find and recover those apps atm, but they must be buried in a random 2024-04-08-030000-684 folder. Never the less. Is it possible to recover data from the snapshot folder? what is that for if backups pull from the other folders? I think our stopped apps are in there but Im not sure how to recover them through the front end that way. One thing that would have made this process so much more seamless is just including that restore config file in the snapshot folder, and the corresponding configs for each app backup, would have saved us hours of finding the correct backup id manually for each method, since Im assuming they are slightly different?

The issue was that docker got stuck in removing the Cloudron network during the starting after the update. Not clear why and when this happens but stopping docker then running docker network rm -f cloudron manually (which will start docker due to socket activation) makes it work...