I have added the provider by now https://git.cloudron.io/platform/box/-/blob/master/dashboard/public/js/setup.js?ref_type=heads#L71

Thanks for the information

A homemade problem. We have refactored our Ansible role. It has installed an MTA that was previously started as Cloudron's mail service. After uninstalling the MTA, everything works as expected.

Sorry, i should have checked that first. Downgrading CF proxy to DNS only does seem to fix the issue for me. Thanks @nebulon.

@luckow give postgresql more memory

Apologies, I continued investigating and going through logs with some Claude help and managed to work out that it was simply down to me adding a Private Docker Registry. It hadn't occurred to me that that would then override existing apps. This is now resolved.

Not sure which nameserver provider you are using, but I remember that back in the day it was possible to screw up the zonefile, rendering all DNS records broken. But generally try to put the TXT record back and then just try to resolve the dashboard domain using your nameserver explicitly (to avoid caching). This should work, if not, please contact your nameserver provider about that.

@firmansi said in Issue with New Installation with Cloudron 8.0.0: @girish I don't activate IPV 6, i have bad experience with this Just to say, it seems going forward you'll likely hit email deliverability issues without IPv6 stuff being configured (especially to M$/ Gmail accounts). See e.g. https://forum.cloudron.io/topic/13145/problems-with-sending-mail

working now. thx

@bosstom Wich password are you using? The one of my.cloudron.instance or the one of cloudron.io web portal? To login in app store you have to use credential of cloudron.io web portal. Also, be careful to add 2FA Token (if enabled)

@IniBudi did that on various occasions, no problem lol. Did you maybe check the „encrypt file name“ option?

@stevespaw said in Question: Moving apps to volume: How does this affect backup? All apps backed up as normal? I guess you mean you symlinked appdata (atleast, from your post history) ? If so, yes all apps are backed up as normal . And if I restore - I assume that the same mount points need to be in place -, but will the restore work normally then? Yes, correct.

omg....just checked the DNS again.... the "webmail" record wasn't by cloudron.... it's directing to the hoster's web mailer (same that cloudron uses).... So for me: without installing a webmail app from the cloudron appstore this doesn't work, right? As I'm on free (at least with that instance) I've no free app anymore. Sorry...my mistake

@nebulon That link worked great. Thanks!

@simon said in Since v8.2.3: "Backup failed: Too many executable files.": As an idea: wouldn't it perhaps make sense to check this independently of the backups? Yeah, I think it's possible. Right now, we haven't focused on it because we have to then give feedback to the user in different ways when multiple apps fails but some succeed etc.

hey, sorry for the late response. nah, i had a different issue with that. i wanted to migrate to a new server. Don't know the exact server versions right now. But in general it was like that: My old server was on something like 8.1.x. The fresh installed server was on 8.2.1. (or similar) So, to make a backup and import it, it says i have to match the server version. So i tried to update to old server, but i got only the option to update to a NEWER version then the fresh installed one, i think 8.2.3, which also was a "beta". so no chance, to only update to the matching stable version to the new server... i ended up re-installing the fresh server to an older version, and enabled auto-update. i understand to not make the effort for subscribing to beta releases, but at least let us select to which version to update... would be nice Otherweise, the migration worked pretty nice. i would point out a few things (DNS stuff), but in general - good work!

Thank you for taking the time to investigate. It seems like there are several tools that have successfully implemented DNS-based Let's Encrypt challenges and DNS-based automation for deSEC. If the higher TTLs really are a problem, could it be possible to just restrict the usage of deSEC to wildcard DNS + Certificate usage (wildcard A/AAAA record + DNS challenge for Let's Encrypt)? These records only need to be updated very infrequently if at all. I personally run my cloudron instance behind a VPN, which is why I am unable to use the HTTP based verification. deSEC is a very special provider that I think is worth putting the effort into supporting. AFAIK It's the only donation-run/free, European provider with DNSSEC support currently included in Cloudron. Hetzner doesn't support DNSSEC. It's also (likely) one of the most privacy respecting providers available. I have also made a post on their forum. Maybe some creative ideas will come about.

@joseph said in Two annoying issues after updating to 8.2.3 - seemingly both solved by rebooting my server: The second one is more confusing because the volume in use comes from db afaik (not sure how a reboot sorts db constraints!). The volume was in use. The problem was another volume just wouldn't mount. But as both the working in use mount and the not working mount were actually both mounts of the exact same Storage Box I thought perhaps removing the in use mount would help. It didn't. But after a reboot the non working mount mounted fine again. (although I guess it's conceivable this also had something to do with the other mount no longer existing - but I doubt it given both mounts seem to happily exist together pre update to 8.2)