Ok weird, this worked, I backed up apps and updated to Cloudron 8 but it's not working again. that file didn't change. I set it to google's public DNS and it was fine - I reinstalled tailscale and set override DNS to true which I think should fix it and let me keep using TS

@bennyv53 I recommend using ssh then (SSL support for internal postgres will break Cloudron's setup). Is the concern security related?

@b2breporter you can contact us on support@cloudron.io and we can fix it up

The apps itself run with minimal permissions but the Web Terminal gives you "root" access (this is a limited root and not server root) so that you can creates files as any user since some apps use multiple users. It's also required in situations where you restore/import the app and those files have different permissions than the one app uses. But tl;dr this is intended. Use su like @murgero said or you can use gosu <username> <cmd> as well

Good catch, we have to fixup the docs here. The OpenID provider session logout, triggered by the app used to be there, but we found that no app supports this properly so it got removed. For nextcloud, we have some changes to soon enable OIDC login by default in the package, so may not be worth it to investigate just now in your case.

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