@james that was work export re import done ...

@joseph Thanks. That was it. I had a backup setup and working but even when I told it to skip backup on the upgrade it still gave me an error. Had to check the box for storing automatic backups even though I chose to skip the backup.

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.

@dsp76 said in Backup restore brocken - wrong file owner "yellowtent" instead of "www-data" in /app/data Lamp Stack: Jan 22 20:43:48 ==> Source custom startup script Jan 22 20:43:48 touch: cannot touch '/app/data/tmp/.npmrc': Permission denied Do you have a custom /app/data/run.sh ? It seems that script is causing this error. That script runs as root though, so I am not sure why it gets permission denied.

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.

I am happy to add -x if that helps. I think the intent was to keep results to the filesystem. -x, --one-file-system skip directories on different file systems

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.

Hello @potemkin_ai @potemkin_ai said in Can't connect to NextCloud console: The Cloudron is behind a proxy This is a mayor detail which you should have mentioned earlier since it is outside the default Cloudron spectrum. Is it the whole Cloudron or just Nextcloud? Please explain in detail what you mean with Cloudron is behind a proxy.

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