I rebooted the whole system, and it seems to have solved the problem.

Hi, I finally got it working on Strato storage via SSHFS. Here are the specifications: OS: Ubuntu 24 Cloudron 8 SSH key: RSA I have disabled hard links. [image: 1725653970393-0f6f30c7-0b4f-4950-8928-5680b69c2a11-schermafbeelding-2024-08-31-221452.png]

@Dreamcatch22 said in Disconnected: No supported authentication methods available (server sent: publickey): But here was the error I was getting from the unresponsive wordpress app: Inactive - Error getting IP of redis-3e2e5aad-1513-4b65-bb24-5eaafc998daa service Services -> Redis -> Restart . Then, try the repair. Think it should work after that.

@Kinzi said in Problem recieving emails when using AWS SES: The questions was: I thought I need that MX for the DMAR/DKIM to work? No MX is not needed for DMARC or DKIM. They are separate concepts.

as @jdaviescoates notes, the SSO setting generally is only during install time, as changing auth backends later causes usually issues within the app and user mapping.

@nebulon Thank you for your response. I correctly configured the repositories, and the installation is now working without any issues.

@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

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)