Hello @difficult222 Thanks for reporting. Can you please check the file size and report that here?

Same problem for me but i don't have a Backup set up at all. "Skip Backup" does nothing and does not let me update. Can you please fix that? And i don't need a backup since i use Proxmox Backup Server.

actually after looking closer in the code, the RRSet record api should also work as ich even for more records. It only would hit an issue, if one record has more than 25 values.

Hi @joseph . Thanks! Yes, the issue was with the encryption password. I successfully created a new app from the backup. However, one question remains: how can I restore a backup to NocoDB without recreating the app? The original restore (to the existing app) kept failing with the role already exists PostgreSQL error. Could this be related to memory limits? I checked and there seemed to be enough memory available everywhere. For context: my NocoDB has many records plus connections to external databases.

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.

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

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.