Cloudron Forum

Hi there,
the community of Mautic users is having a "Community Sprint" in Berlin in June.
If you are interested to join - find out more about the agenda and participants here:
https://mautic.org/blog/join-us-in-berlin-help-build-the-future-of-mautic/

I will be there as well on the first day

Hi there,
I read in https://forum.cloudron.io/post/124569 that Cloudron 9.2 is required. Is this already available? As beta?

Thanks!

Actually just fyi... IONOS now starts offering VPS with Ubuntu 26.04.

... ah great! So also the LAMP stack has mysql 8.4 then?

Regarding Ubuntu - I only checked the availability. Didn't check with Hetzner yet. True - they need to support it in the first place.

@girish Ubuntu 26.04 LTS seems to be available now. Is there already support for it with cloudron? How would the upgrade look like?

Hi there James,
yes it is ... again today.

I asked AI for an idea about the potential reason:

Summary of Backup Issue

A backup was created and uploaded successfully to an IONOS S3 bucket. The archive size was about 46 GB containing 13,069 files, and the upload completed without errors. The corresponding .backupinfo integrity file was also uploaded successfully.

Immediately after the upload, the system attempted to rotate the backup by copying the snapshot object to its final timestamped location using an S3 multipart copy operation.

During this step the copy process failed with:

NoSuchKey: UnknownError

The application reported this as:

Old backup not found: snapshot/app_<uuid>.tar.gz.enc

This is inconsistent with the previous log entry indicating that the upload had just finished successfully.

Observed behavior

• Upload of the snapshot completed successfully.
• Integrity metadata upload succeeded.
• Multipart copy started.
• The copy operation was aborted and S3 returned NoSuchKey.
• The backup task was marked as failed, even though the snapshot object appears to have been uploaded.

Likely causes

• The system attempts to copy the object immediately after upload and the object is temporarily not readable (possible S3 consistency timing issue).
• A mismatch between the key/bucket/endpoint used during upload and the one used during the copy operation.
• A bug in the multipart copy implementation used by the backup system.

In summary, the backup upload itself succeeded, but the post-upload rotation (copy) step failed because the source object could not be found by the S3 copy operation.

Here is the log again. Please have a look at the time stamps. Also strange is the percentage for the copy process. Always the same...

Mar 08 05:27:51 box:storage/s3 Upload progress: {"loaded":46025049716,"part":343,"Key":"snapshot/app_<uuid>.tar.gz.enc","Bucket":"<bucket>"}
Mar 08 05:48:32 box:storage/s3 Upload finished. {"Location":"s3.eu-central-3.ionoscloud.com/<bucket>/snapshot/app_<uuid>.tar.gz.enc","Bucket":"<bucket>","Key":"snapshot/app_<uuid>.tar.gz.enc","ETag":"\"\"","$metadata":{"httpStatusCode":200,"requestId":"tx0000017c8a2550b10c59d-0069acffa0-767801809-eu-central-3","attempts":3,"totalRetryDelay":40000}}
Mar 08 05:48:32 box:backuptask upload: path snapshot/app_<uuid>.tar.gz.enc site <uuid> uploaded: {"fileCount":13069,"size":46025049716,"transferred":46025049716}
Mar 08 05:48:32 box:tasks updating task 9150 with: {"percent":76.36231884057979,"message":"Uploading integrity information to snapshot/app_<uuid>.tar.gz.enc.backupinfo (<app-domain>)"}
Mar 08 05:48:32 box:storage/s3 Upload progress: {"loaded":146,"total":146,"part":1,"Key":"snapshot/app_<uuid>.tar.gz.enc.backupinfo","Bucket":"<bucket>"}
Mar 08 05:48:32 box:storage/s3 Upload finished. {"ETag":"\"c3b40730b7df7334109478d49c4fc7c6\"","$metadata":{"httpStatusCode":200,"requestId":"tx0000009b25a1e91abf3e9-0069acffa0-767802089-eu-central-3","attempts":1,"totalRetryDelay":0},"Bucket":"<bucket>","Key":"snapshot/app_<uuid>.tar.gz.enc.backupinfo","Location":"https://<bucket>.s3.eu-central-3.ionoscloud.com/snapshot/app_<uuid>.tar.gz.enc.backupinfo"}
Mar 08 05:48:32 box:backupupload upload completed. error: null
Mar 08 05:48:32 box:backuptask runBackupUpload: result - {"result":{"stats":{"fileCount":13069,"size":46025049716,"transferred":46025049716},"integrity":{"signature":"c2a556116f2b4a143f8a22796ea4d64751a9e71677c16a2e9c1dcef80e218ed7bcd65fa797fc480b1f69437e14242f35c78e5cc96ad77b1179b8b570b98cbd01"}}}
Mar 08 05:48:32 box:backuptask uploadAppSnapshot: <app-domain> uploaded to snapshot/app_<uuid>.tar.gz.enc. 4338.546 seconds
Mar 08 05:48:32 box:backuptask backupAppWithTag: rotating <app-domain> snapshot of <uuid> to path 2026-03-08-030001-701/app_<app-domain>_v1.13.0.tar.gz.enc
Mar 08 05:48:32 box:tasks updating task 9150 with: {"percent":76.36231884057979,"message":"Copying (multipart) snapshot/app_<uuid>.tar.gz.enc"}
Mar 08 05:48:32 box:tasks updating task 9150 with: {"percent":76.36231884057979,"message":"Copying part 1 - <bucket>/snapshot/app_<uuid>.tar.gz.enc bytes=0-1073741823"}
Mar 08 05:48:32 box:tasks updating task 9150 with: {"percent":76.36231884057979,"message":"Copying part 2 - <bucket>/snapshot/app_<uuid>.tar.gz.enc bytes=1073741824-2147483647"}
Mar 08 05:48:32 box:tasks updating task 9150 with: {"percent":76.36231884057979,"message":"Copying part 3 - <bucket>/snapshot/app_<uuid>.tar.gz.enc bytes=2147483648-3221225471"}
Mar 08 05:48:32 box:tasks updating task 9150 with: {"percent":76.36231884057979,"message":"Aborting multipart copy of snapshot/app_<uuid>.tar.gz.enc"}
Mar 08 05:48:32 box:storage/s3 copy: s3 copy error when copying snapshot/app_<uuid>.tar.gz.enc: NoSuchKey: UnknownError
Mar 08 05:48:32 box:backuptask copy: copy to 2026-03-08-030001-701/app_<app-domain>_v1.13.0.tar.gz.enc errored. error: Old backup not found: snapshot/app_<uuid>.tar.gz.enc
Mar 08 05:48:32 box:backuptask fullBackup: app <app-domain> backup finished. Took 4338.955 seconds
Mar 08 05:48:32 box:locks write: current locks: {"full_backup_task_<uuid>":null}
Mar 08 05:48:32 box:locks release: app_backup_<uuid>
Mar 08 05:48:32 box:tasks setCompleted - 9150: {"result":null,"error":{"message":"Old backup not found: snapshot/app_<uuid>.tar.gz.enc","reason":"Not found"},"percent":100}
Mar 08 05:48:32 box:tasks updating task 9150 with: {"completed":true,"result":null,"error":{"message":"Old backup not found: snapshot/app_<uuid>.tar.gz.enc","reason":"Not found"},"percent":100}
Mar 08 05:48:32 box:taskworker Task took 6510.865 seconds
Mar 08 05:48:32 BoxError: Old backup not found: snapshot/app_<uuid>.tar.gz.enc
Mar 08 05:48:32 at throwError (file:///home/yellowtent/box/src/storage/s3.js:540:49)
Mar 08 05:48:32 at copyInternal (file:///home/yellowtent/box/src/storage/s3.js:607:16)
Mar 08 05:48:32 at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
Mar 08 05:48:32 at async Object.copy (file:///home/yellowtent/box/src/storage/s3.js:641:12)
Mar 08 05:48:32 at async Object.copy (file:///home/yellowtent/box/src/backupformat/tgz.js:284:5)
Mar 08 05:48:32 Exiting with code 0

Based on the S3 storage timestamps the file was already there at 05:48 - also in the correct path:

Sorry - camp will be postponed. New dates will be announced as soon as we know them.

@james need to test backup and restore again to find out... will do.

DNS propagation is an asynchronous process. I have no way of knowing exactly when the DNS record has changed globally.

My assumption was: as soon as the domain starts resolving to the Cloudron server (i.e., the first external requests hit the new IP), Cloudron could automatically begin issuing the certificate and complete the app setup.

Is there a technical reason why this approach would not be feasible?

And what needs to be done on WordPress (Developer)?

Hi,
I didn't have a chance to make a backup yet, after cloning from beta. I also don't have this DNS managed by Cloudron - "Manual Setup". Thus I decided to now uninstall and copy again from beta. Unfortunately this way I have some downtime. Yes I could have restored first to a different domain managed by Cloudron - and then move there.

So how would I prepare an installation, when the DNS is about to be updated in some time later - maybe after timeout? Shouldn't the DNS setup be retried repeatedly for a while?

Can I uninstall and then reinstall from the backup? Can I update the backup of the App via some cli command, as the UI won't let me do it?

@girish could you please explain? is a broken 3.11.3 more insecure than an insecure older version? Wouldn't it be better to switch to app based authorisation meanwhile and deactivate the plugin?

When checking with dnschecker.org I can see its already updated in all checked regions. The domain already resolves to our cloudron instance and its also responding as expected (Website). Also the certificate (LE) has been issued correctly. So why does the app still stay in error state?

Error - DNS A Record of example.com is not synced yet: ETRYAGAIN

Will this resolve automatically after some time?
DNS is now pointing to Cloudron and the app is running fine. However, Cloudron still shows the error and blocks all menu options.

Restarting the app is not available in the main UI, only in the Terminal view. We restarted it from there, but the issue persists.

What triggers a re-check so that the error state is cleared?

@humptydumpty said in Urgent Security update for OIDC plugin Wordpress:

@girish do we need to do anything on the user end?

Same question here. Is it something we should manually set? What do we set correctly to work with cloudron?

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

OK - managed to enter the terminal with recovery modus and changed ownership of the files. App is now running again. But still - whats the issue with the backup restore?

Description

I had some no related issues in an application installed in the LAMP stack. When I tried to restore an earlier manual and automatic backup from today, the app failed to start after the restore. I found out, that all restored files are owned by "yellowtent" instead of "www-data". Unfortunately the shell doesn't start so I can't manually fix it recursively.

Steps to reproduce

• restore LAMP App from backup
• files are owned by "yellowtent"

Logs

Jan 22 20:43:48 ==> Do not override existing index file
Jan 22 20:43:48 ==> PHP version set to 8.3
Jan 22 20:43:48 ==> Source custom startup script
Jan 22 20:43:48 touch: cannot touch '/app/data/tmp/.npmrc': Permission denied

Troubleshooting Already Performed

• tried to enter terminal to change owner of the files

System Details

Generate Diagnostics Data

Cloudron Version

Cloudron version - 9.0.17

Ubuntu Version

Ubuntu version - Ubuntu 24.04 LTS Linux 6.8.0-90-generic

Cloudron installation method

Options:

• Manual with ./cloudron-setup

Output of cloudron-support --troubleshoot

Vendor: Hetzner Product: vServer
Linux: 6.8.0-90-generic
Ubuntu: noble 24.04
Execution environment: kvm
Processor: AMD EPYC-Milan Processor
BIOS NotSpecified  CPU @ 2.0GHz x 8
RAM: 32087112KB
Disk: /dev/sda1        21G
[OK]	node version is correct
[OK]	IPv6 is enabled and public IPv6 address is working
[OK]	docker is running
[OK]	docker version is correct
[OK]	MySQL is running
[OK]	netplan is good
[OK]	DNS is resolving via systemd-resolved
[OK]	unbound is running
[OK]	nginx is running
[OK]	dashboard cert is valid
[OK]	dashboard is reachable via loopback
[OK]	No pending database migrations
[OK]	Service 'mysql' is running and healthy
[OK]	Service 'postgresql' is running and healthy
[OK]	Service 'mongodb' is running and healthy
[OK]	Service 'mail' is running and healthy
[OK]	Service 'graphite' is running and healthy
[OK]	Service 'sftp' is running and healthy
[OK]	box v9.0.17 is running
[OK]	Dashboard is reachable via domain name