@girish yes, I meant this configuration option.

Hi @nebulon, thank you for the information. I already checked one of the apps was using the volume. After deleting the volume from the app. I can delete the old storage volume. Thank you once again.

Thanks for the explanation. In future I will read the release notes before asking questions 🙂

Wonderful. Thank you @Joseph, that change to the endpoint URL did the trick. The configuration saved successfully.

Don't think this is a problem. It's quite normal to use Hyper-V and Proxmox to host Cloudron

@joseph Yes actually is was closed. By default Oracle servers are developed with closed 80, 443 ports.

Now problem is solved

@Wenhardt try Scaleway - not perfect but works generally

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 ^^