Sorry for the frustrating experience but I have to say in several years of using Cloud infrastructure, this is the first time I hear of someone providing a server on non-port 22. This is why such a special case has not made it to the docs. May I ask what VPS provider this is? We test installation over 30 providers, all use port 22 by default.

@nebulon test, as in previous testing proxying across cloudrons, and to other search engines worked just fine, and these tools sites, didn't.

@girish I couldn’t do that. The task wasn’t canceling and buttons greyed out. When i opened the terminal, it didn’t load the page (edit: it didn’t load the content within the black frame, the menu was there) so i couldn’t type in any commands and the restart button in the terminal and log pages didn’t trigger a restart once clicked. A full vps restart did the trick though.

You should see it in the app logs around that timeframe what happened

yes, we will update the image. You can also install 7.5 though and then manually check for updates, we are slowly rolling this out for autoupdate now.

@supashot said in [Noob]Access denied: OVH DNS error 403 This call has not been granted: @girish ls -al /home/yellowtent/appsdata total 8 drwxr-xr-x 2 yellowtent yellowtent 4096 Nov 29 14:02 . drwxr-xr-x 6 yellowtent yellowtent 4096 Nov 29 14:02 .. I think I understand. Hastebin probably has not finished installation / has error installing ? This is why that directory is empty . If so, that's normal.

Great! Thanks for your speed

@robi I think the user put zone restrictions on his existing API keys. The Cloudron zone was not part of the API key.

OK, I'll try. Thanks for your suggestions.

OK. This was very exciting. I read some documentation. Specifically, https://docs.opnsense.org/manual/how-tos/nat_reflection.html. Once I slowed down, undid all the weird thrashing I did with various DNS shortcuts for route domains internally/directly (e.g. changing my unbound config, or creating aliases for my domain), and instead read the documentation for both reflection and hairpin NAT in OpnSense, I was good to go. Thank you for joining me on this journey where I create noise on the forum and discover that, by reading the manual, I can solve my own problems.

probably via https://forum.cloudron.io/post/71420

This is fixed in https://git.cloudron.io/cloudron/box/-/commit/e64182d79134e8828c2fa953c676a8f6b08247b7 Haraka also needed an upstream fix which I have submitted in https://github.com/haraka/haraka-plugin-limit/pull/52

@girish I have mine in France. I've been able to install Cloudron since, I guess the problem was with the OS they provided, but I still don't understand why apt update only worked after 1 day.

@foliovision you can also try docker system prune -a --volumes but generally I have never succeeded in making that reclaimable space be less than 2GB in any server using docker (even without Cloudron).

@girish said in Information in docs changed regarding branding: @andreasdueren passwordreset.html and setupaccount.html already use app branding. notfound.html and appstatus.html are really more backend things . They have to be usable even when Cloudron is down and thus the API cannot be accessed to get the branding information. Of course, one can statically generate them each time branding is changed... I see, makes sense!

Yeah, thanks. I thought thats posible, but i will do it like our adivise

@skeats do you need help patching it?

At least they can copy/paste from the log file!!

@bloops are you saying you created a Domain called mail.domain.tld ? This is not needed. I think the certificate issue could simply be a matter of DNS propagation. Especially, with manual DNS, depending on your provider, this can take a while and Cloudron has no way to check . In such cases, it will start using a self signed certificate initially. There is a nightly cron job to renew certs and that would kick in and get a certificate eventually.