@mdc773 the directory is /app/data/public in Web Terminal

After a reboot, it seems fine for now. Let’s see if it persists

Thanks, then I know it's going to return to normal. No, not using name.com. Some domains are with a Swedish provider (Loopia) and some with Cloudflare.

For anyone else, the wonderful team at Cloudron assisted further and identified the issue is that my internet service (and router) did not have ipv6 but the server was trying to use ipv6 to connect for appstore auth. Adding ipv6 with my isp and enabling in router "resolved" the issue. It is not currently known why my server was insisting on using ipv6 or how to stop that if I was unable to add it.

@girish yeah, I understand there is nothing about Cloudron here - just wanted to check your experience / understanding here. Thanks for sharing!

Happens a LOT I don't mind at all.

Ah yes, you were quicker than me, all green again, so I guess that was just a temporary minor glitch Thanks for checking though!

Yeah, this is just a bug. Operators should be able to update apps. I have fixed this in https://git.cloudron.io/cloudron/box/-/commit/a932a5251a7e5909945210d3c27f46ea3b937650 . We will be making a patch release 8.0.5 shortly with various fixes.

Ok so the show must go on: "Sep 13 10:12:10 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.250:80 Sep 13 10:12:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.250:80 Sep 13 10:12:30 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.250:80 Sep 13 10:12:40 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.250:80 Sep 13 10:12:50 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.250:80 Sep 13 10:13:00 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.250:80 Sep 13 10:13:10 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.250:80 Sep 13 10:13:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.250:80" on a fresh installation of Nextcloud. Also the system is extremely slow.

@lucifer1004 thanks for the correction , will fix the original post!

@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.