Thank you @james Increasing the part size has fixed the issue.

Thanks for you help

Right, the haraka log can be ignored. I think the IP and cert name don't match and thus the warning. It's not a problem since such mails don't leave the server.

I have this running too I thanks I have ork this out will update this post so if someone need to do it but thanks for the help sure I got it now I have found he keys ssl_certificate /home/yellowtent/platformdata/nginx/cert/_.XXXXX.cert; ssl_certificate_key /home/yellowtent/platformdata/nginx/cert/_.XX.key; just need to make a scp for on changes and to send a copy to the 2nd server..... Nozy

Once the DB gets busy, big or the storage gets slow, consider to copy the .db file first then dump from a DB file that isn't changing.

Created an issue. https://github.com/haraka/Haraka/issues/3516

@dleidert thanks for reporting. I have added a check now to check for package name match instead of the previous docker version match. This way the docker package will update when (the next) cloudon update happens.

Hello @estudios507 Thank you for the detailed report. I will try to assist you to my best capabilities. @estudios507 said in Cloudron rejects iCloud forwarding only when “Delete after forwarding” is enabled (SMTP 550 on MAIL FROM): Identify which Cloudron restriction/policy is triggering “Mail from domain ‘X’ is not allowed from your host” in this scenario. Regarding why this is happening. When iCloud forwards messages in delete mode, iCloud uses the original sender’s MAIL FROM (envelope-from) unchanged instead of rewriting it. If that original sender domain is hosted on the same Cloudron server, Cloudron sees an external connection (from iCloud’s outbound IP) claiming to send mail from its own domain. Cloudron treats that as spoofing and rejects it. @estudios507 said in Cloudron rejects iCloud forwarding only when “Delete after forwarding” is enabled (SMTP 550 on MAIL FROM): Confirm whether there is a supported and safe way in Cloudron to allow this specific flow (forwarding from iCloud with delete enabled) without broadly weakening anti-spoofing protections. There is also another topic regarding this issue with iCloud, see: https://forum.cloudron.io/topic/1998/mail-error-after-sending-message-mail-from-domain-example-com-is-not-allowed-from-your-host A fix is to add the iCloud servers to the domain A's SPF record. Your current SPF record is: dig TXT estudios507.com +short "v=spf1 a:mail.estudios507.com include:_spf.safewebservices.com ~all" You can edit that to include apple: "v=spf1 a:mail.estudios507.com include:_spf.safewebservices.com include:_spf.apple.com ~all" after that edit it can take some time to propagate, but this should resolve your issue.

There was a bug in Cloudron when backing up directories where the contents keep changing very quickly. This is fixed in https://git.cloudron.io/platform/box/-/commit/42cefd56eb9f89cfb6c7e35d6410dd5b7dbfa45d . Other than the above, the slowness is because of the usage of a cache plugin and this cache plugin's data is being backed up. Since it keeps changing all the time, there is a lot of stuff to clean up and reupload each time. A solution is to configure the cache plugin to use /run/xx path instead of /app/data . This should make things considerably faster.

Also, to speed up your auto updates you could change your auto updates to every hour and then just wait a couple of days for it to get through them all

@girish Running. Problem solved.

Its IONOS Object Storage. Storage: ionos-objectstorage (tgz) Berlin (eu-central-3)

Thank you @james I could not get it to work. After several attempts, I ultimately deleted the backup files and started with a new configuration. As advised, I also set the retention period to "unlimited" (it was previously set to two days). Everything is working well now, and I was able to back up and clone the app without any issues. Thanks again, and keep up the good work!

Hello @sebastienserre App Archives are not the same as backups. App Archives is when you go to an app, to the uninstallation section and archive the app. This uninstalls the app but keeps the latest backup as an archive so it can be restored. This archive is stored and kept outside the backup retention policy. See https://docs.cloudron.io/apps#archive [image: 1768426785759-3ca46733-ecad-4ae3-8980-65d96397645c-image-resized.png] [image: 1768426835825-f592674b-3485-4155-b11d-048fd845ac60-image-resized.png] Your system backups are viewable under Backups> Sites.

@oskarardolo 9.0.16 will be out possibly end of this week or early next week.

@tecbox I sent a reply from support. I debugged this further . The 502 is returned from deSEC . I have added some logs on your server to see if we can get the full error to report to deSEC. So far, it's been running for the last one hour without reporting any error from deSEC .

Hello @canadaduane Thanks for the report, this will be fixed with the next Cloudron update. https://git.cloudron.io/platform/box/-/merge_requests/26

Closed in favor of https://forum.cloudron.io/topic/14871/failed-to-open-stream-permission-denied

Fixed in support. Not clear what the issue is, but it could be possibly because spamcop dnsbl was not responding. I removed it from the mail acl - https://docs.cloudron.io/email/#dnsbl.