Right so we have a bunch of similar topics referencing the same problem. https://forum.cloudron.io/topic/13162/unable-to-send-emails-to-gmail https://forum.cloudron.io/topic/13145/problems-with-sending-mail https://forum.cloudron.io/topic/13122/email-sending-broken-after-updating-to-8-2-x-due-to-ipv6-issues https://forum.cloudron.io/topic/13072/gmail-ipv6-anyone-else-with-this-experience Should they all be merged and/or marked as solved? The solution is provided by @girish (here) and @jdaviescoates (here) which I'll compile and summarise here again: Activate IPv6 on Cloudron via going to Network > IPv6 > Configure > Public IP Check your IPv6 address either via reading the IPv6 address detected by Cloudron when doing 1. or via running curl https://ipv6.api.cloudron.io/api/v1/helper/public_ip on your server (via ssh). Set an IPv6 PTR record on your VPS/server provider (not your domain provider) for the above IPv6 address. The next Cloudron release will implement a check on IPv6 PTR record like it currently does for IPv4. If using Wildcard DNS then create a * AAAA record for the above IPv6 address. If things still don't work, you can go to Cloudron -> Domains -> hit Sync DNS If your VPS provider does not allow you to set IPv6 PTR, then disable IPv6 that way: disable IPv6 in Cloudron (Network -> IPv6 -> Disable) on your server via ssh run sysctl -w net.ipv6.conf.ens18.disable_ipv6=1 (replacing ens18 for your specific network interface, in my case eth0) make it persistent by adding net.ipv6.conf.ens18.disable_ipv6=1 to /etc/sysctl.conf (replacing ens18 for your specific network interface, in my case eth0) Update: I personally still faced issues with Gmail using IPv6 so I ended up disabling it persistently.

I followed the instructions, now the child sites work but the main network site isn't,

You have to install nginx and put those configs on the server where you deployed odoo . That is the correct place for putting those multiple port configs. Then nginx will then answer to a single port 80 which you can then put into cloudron.

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.