I would be surprised if the default configs do not regulate the fan already. As you mention mostly the Paperless issue with CPU simply heats up the CPU continuously, so we have to first get down to that issue.

The process is essentially the same as normal updates: fetching new release tarball extracting and replace old release run the upgrade script We have an internal hotfix tool for development which performs those steps, if run from within a git tree with the target release tag checked out. Mostly this is not provided automatically to those Cloudrons is, that we haven't tested the release jump much, so we don't want to risk users being offline until we have time to potentially fix some edge case on that server.

You guys rock! Thank you.

Fixed in https://git.cloudron.io/cloudron/box/-/commit/abf445e96949ab952c07b457610a1a890cf4e339 for next release.

Thanks, that worked!

@Jantheman do you have any updates on this? Is it resolved or does this need further debugging?

So, the mounting is handled by the kernel and Cloudron as such has nothing to do with stability of the mount. Cloudron is really just a user space program. You can find the mount systemd file in one of the mount files in /etc/systemd/system/*.mount . Maybe you can look for hints in dmesg (but often unmount information logs is not there)

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.