@girish hi, please can you check also Network > IPv6 setting? It seems that is not persistent across instances when migrated. I had IPv6 disabled in source instance, but it was enabled after migration.

Small update from my side. I contacted Spamhaus through their ticket system and after communicating with them it seems everything is now resolved and the IP has been removed from the blacklist. Emails are working normally again. Sorry for the false alarm and thank you for your help and responses. I did notice that occasionally I still see the error that was present in the previous version, so I will keep

@girish thank you

Just to come back to the previously suggested solutions - Would it be a big feature request to add group name parsing into the mailing list input box? E.g. instead of (or in addition to) a list of email addresses it could take something like "group:foo" and then this would dynamically pull in the email addresses of all users in group foo as needed. Is there a way that cloudron user group info could be pulled in @roundcube (or another mail system), so that instead of setting up forwarding rules that go to a list of emails it could go to "group:foo". Is there a way that we could run a cron job (or similar) which could hackily create either of the above functionalities by generating and inserting the lists (rather than these lists being dynamically generated), with the downside that this would only ever be as up-to-date as the frequency with which the cron job runs.

@timconsidine I think probably a better way to implement this was so called Device Authorization Flow . That approach doesn't require callback to localhost. We are looking into implement the cli auth that way instead.

O what a pity was hoping this could be a solution

@nozy did I understand correctly that /dev/sda has the Cloudron install and /dev/sdb is your data disk? you have to re-setup the volume to use /dev/sdb1 instead of /dev/sda1 .

Alright, investigating the matomo health checker next.

@joseph

@dsp76 I think if this happens sporadically it is a bug in the remote service provider. Have you asked their support already if this issue is known?

@girish

OK upgrade wow that looks like it work with me crying do I try to do the domain move now take a snap be for I start just to make sure or do I upgrade to Ubuntu 24.04 1st Nozy

I'm interested to know what you discover because I use Gandi too...

Noted, will wait for the 9.1 release then and revert if there are still issues.

@robi said: @girish Can a migrations check be added to run until none remain, which hopefully evades the stuck condition too? this would actually be a good addition to the CLI toolset... @girish @james

Hello @diego @diego said: However, from a system design perspective, I was wondering if it would be better to: keep the system disk small (OS + Cloudron core) attach a separate disk dedicated to mail storage Yes you can do that. I also do that with my private Hetzner server so I can scale up the CPU/RAM and have the storage seperate. @diego said: Will the Cloudron backup system still include it normally? Yes. If you move e.g.: /home/yellowtent/boxdata/mail to /mnt/sdd1 and create a symlink so /home/yellowtent/boxdata/mail => /mnt/sdd1 this still works. What you can always to is creating a small Cloudron server to test and tinker as much as you like. This way you get a better feeling for everything without risking any damage to production.

Sometimes it breaks almost instantly, at other times it manages to go for a few seconds and get to 20-30MB before crashing.

@joseph omg! thank you so much for pointing in the right direction. i did upgrade our servers on Netcup a while ago, i kept the old ones in case i needed any data, turns out, the VMs had an autostart set and were running again.... Thank you! Case solved (i hope)

fixed - after increasing redis memory it works now (will keep an eye on it from now on). Thank you very much! Good day today as I learned something new