@d43m0n1k_sek yes, let us know

Thanks guys - I did see that other thread but wasn't sure if it was the same thing. Appreciate the workaround and the fix, and all your hard work always!

Ah, thanks! I was already running 8.0.5, but the upgrade to 8.0.6 got stuck. /home/yellowtent/box/setup/start.sh came up with an unbound error. I was able to start box manually and start all apps, but the backup volume did not mount. After installing unbound-anchor, I was able to run /home/yellowtent/box/setup/start.sh without errors, and now the backup is working again.

This doesn't affect Cloudron as such but the upcoming mail addon update contains the fix.

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