Without the DNS entry mail from cloudron ends up with ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@smtpcorp.com header.s=a1-4 header.b=38VpoA5C; dkim=pass header.i=@permamed.org header.s=s1004192 header.b=IvzZvAEF; dkim=permerror (no key for signature) header.i=@permamed.org header.s=cloudron-0d9262 header.b=cSc2yqyX; spf=pass (google.com: domain of bounce.3wqhqixyft3pua6=46muc2596w7f=34l98tc3oj4uzw@em1004192.permamed.org designates 158.120.86.203 as permitted sender) Once I add the entry I get ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@smtpcorp.com header.s=a1-4 header.b=hge5ICDL; dkim=pass header.i=@permamed.org header.s=s1004192 header.b=HnqT1ibh; dkim=pass header.i=@permamed.org header.s=cloudron-0d9262 header.b="bpPl/+t5"; spf=pass (google.com: domain of bounce.w5qkkdyfnaxsxb7=ojoiat7bxbcy=pc4cfvy7huru7n@em1004192.permamed.org designates 158.120.86.203 as permitted sender)

@girish yeah did found a solution, I only did recreate container before updating and it fixed the mysql issue.

I changed nothing, but it is working today. I imagine what is happening is that the upstream storage drops connections occasionally and cloudron simply passes that on to the user instead of having a retry loop in the background. So, I still believe this functionality would benefit from being more robust, as before it would manage 20-50MB per go before drop, and if the thing was in a retry loop it would be able to get the archive out by just resuming downloads. I realise it is annoying having to deal with people who insist on unreliable storage... but it is what we have.

I'd guess this was due to Cloudron's small default part size. I think Scaleway has a limit of 1000 parts per bucket. @cloudron_jf try increasing part size.

@girish said: @sansguidon might be best to wait for the next release which should be out shortly. This bug is only in rsync and not in tgz. With the manual patch it did work . I'm not sure to understand your advice anyway, for me the backups are a very critical part of if not the most important of Cloudron, so they should not be skipped, and my understanding is that with rsync blocked my backups are local and no copy exists outside of my server, if I'm not mistaken? This seems risky enough and a sufficient motivation to take immediate action, or please correct me if I misunderstood.

@robi thank you. Indeed it does allow me to type a command . My bad (I was waiting for the prompt to blink or something) Case solved I guess

Aaaah, thank you for this explanation!

@girish Perfect thank you

Hello @nozy Please be aware that the ext4 volume option mounts the disk itself, so no need for a custom fstab entry. If you want to manage that yourself in fstab, you should use Filesystem (mountpoint).

Hello @davejgreen @davejgreen said: Is migration of users and email boxes only possible by using the "looking to restore" button for restoring full Cloudron backups? Yes. @davejgreen said: And is that button only available when you first install Cloudron? Yes. @davejgreen said: We have a second server up and running with a newer version of Ubuntu and Cloudron and were thinking about importing each app individually (after backing it up from the old Cloudron onto a backup site hosted on the new Cloudron), but I'm not sure if there's a way to import the users and email boxes? If not, I guess this approach will not work for us, we'd have to use a third site for a full backup. This is not recommended. The new server should be installed with the exact Cloudron version you are currently using. Otherwise you wont even be able to restore the system backup. @davejgreen said: Do we need to purchase another one for the new Cloudron instance? No. Once migrated simply write a mail to support@cloudron.io and inform us and we will switch the licence to the new server. To minimize downtime use the dry-run backup restore option: https://docs.cloudron.io/backups#dry-run-restore This way, you can restore the whole system, without changing DNS records and can validate each app / step manually. The old server stays up and running, serving all the apps, mail, chat etc. After a review of the migration, when ready to switch permanently, go to Domains view and click Sync DNS.

Device Authorization Flow is implemented in 9.1.4 (will be released shortly). With this, it won't require cors/callback.

@joseph thanks a lot for your prompt answer. I migrated and after 24 hours I saw this problem. So, right now what other I did: I enabled LAMP recovery mode I disabled LAMP recovery mode I rebooted whole VPS (not only LAMP app) Problem is solved after those further steps. Migration script could be improved to update cron job container ID if any cron job configured in a specific app.

@girish Totally understood logic. Thanks a lot for your answer.

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.

O what a pity was hoping this could be a solution

Alright, investigating the matomo health checker next.

@joseph