Looks like this part does fix it (instructions for root server): [image: 1737492462373-9fbbe904-6e2e-4deb-8d7d-5d2812a54c83-image.png] Thanks to you both for the pointers!

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.

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.

@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

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

OK, I finally worked on this AGAIN and remembered how messed up this is conceptually. username: groupname@domain password: (any one of the passwords of the people that have access) This is also makes Freescout work for me https://forum.cloudron.io/topic/12976/connection-could-not-be-established-with-host-mail-domain-com-connection-timed-out-110/43 A single "username" having multiple passwords is what messes me up every time.

@jdaviescoates said in Issue with volumes since updating to 8.2.3: @staff I really need to be able to listen to music and this is now driving me mad and so I've just enabled ssh support (actually had forgotten to disable it from last time ages ago ) and emailed support@ asking for help Hah! I figured "perhaps I should try a reboot, see if that helps" at it did! Now it's mounted fine! Phew. Finally! Unless you did something very quickly! (which is unlikely given how quickly after emailing support@ I tried the reboot)