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)

@girish Thanks

I agree about using an external SMTP relay. In my case, Postmark has been flawless. Because they separate marketing from transactional messages, their deliverability seems better than their competition. I also set up a sub-account (in Postmark jargon, it's called a Server). By doing that, each domain's reputation is isolated. If someone behaves badly, it is easy to delete their server keeping the rest of your infrastructure intact. By adding a "domain-based" Sender Signature with DKIM and Return-Path, any email sender from that domain is permitted. It works really well!

I remove the user from the group and add the user again to the group.

@girish said in Bug: When adding of a volume fails, docker container creation fails, removal of old volume impossible: nvm, I reproduced it. If you change the path behind Cloudron's back, it doesn't work. I think it's correct to error since that path doesn't exist anymore. But anyway quick fix is: simple create empty /media/SG2TB/M/Calibre on the server and then Retry configure will work. After it comes up, remove the mount from the app, delete the volume, add new volume with correct path, add mount into app... That's what I did, I went behind Cloudron's back ... and didn't think of the obvious solution presented by you! Thank you.