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

@gnulab it will start using any free disk space automatically. Maybe try, going to the Repair section of the app. Click Enable Recovery Mode and then Click Disable Recovery Mode. This will recreate the container and maybe it works now. Can you try?

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.

Yes, looks like you are asking for a multi-tenant setup. See https://forum.cloudron.io/topic/9258/request-for-change-rfc

@DualOSWinWiz it was Storage issue which i resolved as it was 100% had to increase VM disk space then did bunch of ubuntu commands but it worked. i would recommend having an auto option to delete unwanted packaged related to Coudron. What's inside Docker 42.08GB OLD Backups [image: 1700103248634-aad5bebe-9f09-458b-83cc-76d090645232-image-resized.png]

@Adhok Don't forget to consider the opposite possibility. Push vs Pull.

The issue here was DNS related. my.domain.com was not pointing to the public IP.

This is fixed with https://git.cloudron.io/cloudron/box/-/commit/fe1c483b7819404d4531fd34323bc2fc18534b85 now

@Kubernetes thanks for reporting!