They were only being embedded for the staff on our Nextcloud, not for the public. And we did restrict to our internal domains and had the same issues. Just thought people should know that some apps don't work at all with CSP, causing these apps GUI to stop loading complely making it look like the app no longer works.

@ivan-petro You can download the backup file directly from S3 and try to extract it (on your laptop). Inside it you will find the postgresqldump and other data files. Backup -> Info will give the details of the path (remote path) in S3 . That will help us determine if the backup is corrupt or not.

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

I have a run.sh indeed. Which runs invoked by start.sh, right? I don't think there is anything that overrules the start.sh chown command. #!/bin/bash set -e shopt -s expand_aliases # Alias zur Nutzung innerhalb des Skripts alias swd='sudo -E -u www-data' # Pfade TMPDIR=/app/data/tmp NPM_CACHE=$TMPDIR/npm_cache COMPOSER_CACHE=$TMPDIR/composer_cache NPMRC=$TMPDIR/.npmrc BASHRC=/app/data/.bashrc # Verzeichnisse & Dateien vorbereiten swd mkdir -p "$NPM_CACHE" swd mkdir -p "$COMPOSER_CACHE" swd touch "$NPMRC" # Rechte setzen chown -R www-data:www-data "$TMPDIR" # .bashrc ergänzen (idempotent) ensure_bashrc_entry() { local LINE="$1" grep -qxF "$LINE" "$BASHRC" || printf "%s\n" "$LINE" >> "$BASHRC" } ensure_bashrc_entry "alias swd='sudo -E -u www-data'" ensure_bashrc_entry "alias php='php -d memory_limit=1G'" ensure_bashrc_entry "export NPM_CONFIG_CACHE=$NPM_CACHE" ensure_bashrc_entry "export NPM_CONFIG_USERCONFIG=$NPMRC" ensure_bashrc_entry "export COMPOSER_CACHE_DIR=$COMPOSER_CACHE" # App starten (z. B. Apache im LAMP-Stack) # example: exec /usr/bin/supervisord -c /etc/supervisor/supervisord.conf As far as I can see, start.sh has chown -R www-data:www-data /app/data /run/apache2 /run/app /tmp But still after restoring backup it all belong to yellowtent. When I find the time, I will test this with a vanilla LAMP App...

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.

Hello @supaiku Are you using the @wordpress-managed or @wordpress-developer app?

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

@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.

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)