@williamuk16 have you seen https://docs.cloudron.io/installation/home-server/ already ? See also https://docs.cloudron.io/installation/intranet/ for a setup not accessible outside your network.

From error message it looks like Cloudflare ... @asatyr maybe the Cloudflare keys expired or don't work anymore ? If you go to Domains -> Edit and click save, does it work? Most likely it gives the same error. Either fix the keys or if you don't want that domain anymore, change the dns provider to manual and then delete the app and the domain.

For anyone else out there that is having trouble, I was able to fix this issue by disabling ipv6 within ubuntu. First I did the curl test as mentioned by @nebulon - it worked as expected, but when adding the --ipv6 option it failed. When running "ip a" I could see an ipv6 address was present. Using the link that @playsia supplied, I carried out the steps described in section 1: Disable IPv6 using Sysctl. I didn't need to modify the /etc/rc.local file. Running "ip a" again, there was no more ipv6 addresses shown. I only had these issues after upgrading to V8.0.3 and Ubuntu 24.04.1.

@mpeterson0418 I found that the root file system was either corrupt or "reset" . I don't know and unable to guess what happened to the disk (maybe power outage?), but I can explain what I did to recover. I found host MySQL to be empty. The box database had tables but was empty. The fact that it had tables meant that migration scripts were run on this . Maybe /home/yellowtent/box/setup/start.sh was run at some point on an empty (i.e no tables even) database. Usually, the last well known mysql dump is located /home/yellowtent/boxdata/box/box.mysqldump . One can also find the same inside the latest backup (inside the box.tar.gz) . To "restore", mysql -uroot -ppassword < /home/yellowtent/boxdata/box/box.mysqldump Then I found, docker won't start. In Cloudron, containers are throw away infrastructure since data is stored outside the containers. I tried cloudron-support --recreate-docker but this did not work. On investigating further, it seems /var/lib/containerd was also corrupt . Corrupt here means no docker commands work. So, I removed that directory as well. After that, cloudron-support --recreate-docker worked. The best way to migrate in Cloudron is not to do the above but instead just restore from backups. See https://docs.cloudron.io/backups/#move-cloudron-to-another-server .

@girish Ok, great! Thank you very much for the information. I really appreciate your time. Thanks again!

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.