Cloudron Forum

Worth verifying directly whether the issue is on Exoscale's end or something in the Cloudron configuration. The "code: undefined message: HTTP: undefined" error pattern specifically means the HTTP request to S3 is not completing at all - it's not getting a 4xx/5xx response from the server, it's getting no response or a connection-level failure.

A quick test from the Cloudron host itself would help clarify. Install s3cmd and test bucket listing directly:

s3cmd --host=sos-ch-gva-2.exo.io --host-bucket="%(bucket)s.sos-ch-gva-2.exo.io" ls s3://<your-bucket>/

If that also fails with a connection error, it confirms the issue is network-level between your Cloudron server and the Exoscale endpoint. Possible causes:

• DNS resolution failure for the S3 endpoint hostname
• A firewall change on your host or at Exoscale
• Their S3 service still not fully recovered in your region

Check if the hostname resolves: dig sos-ch-gva-2.exo.io

And test basic TCP connectivity: nc -zv sos-ch-gva-2.exo.io 443

If both resolve and connect fine, the problem is likely still at the API level on Exoscale's side. In that case, triggering a manual backup from the Cloudron dashboard and watching the logs in real-time will give you the full error chain: journalctl -fu box.service

If you need backups running today and Exoscale isn't cooperating, you can temporarily point the backup endpoint at a different S3-compatible service (Backblaze B2, Wasabi, etc.) to confirm your Cloudron setup itself is fine. That also rules out whether the issue is specifically with Exoscale or something in the Cloudron backup configuration.

To be fair, the SSH remote copy failing is almost certainly a ZFS hardlink limitation rather than a permissions issue. Cloudron's backup system uses "cp -aRl" on the remote host to create a hardlink copy of the snapshot directory into a dated backup directory. This is the fast path that avoids re-uploading data between backup runs.

The problem with TrueNAS is that ZFS hardlinks only work within the same dataset. If your snapshot directory and your dated backup directories are on different ZFS datasets, or if the copy crosses a dataset boundary at any point, cp -aRl will fail silently (or with a "cross-device link" error) and Cloudron falls back to sshfs and uploads everything again.

A few things to check:

First, look at your TrueNAS dataset layout. If your Cloudron backup target is something like /mnt/pool/cloudron and the backup creates subdirectories inside it, everything needs to be within the same ZFS dataset. Run "zfs list" on TrueNAS and confirm that snapshot and the dated directories are under the same mount point.

Second, run the cp command manually to see the actual error. SSH in to TrueNAS as your backup user and try:
cp -aRl /path/to/snapshot /path/to/test-copy

If you see "cp: cannot create hard link: Invalid cross-device link" or similar, the dataset boundary is your problem.

Third, if you cannot fix the dataset layout, you can work around it by enabling Zstandard compression on the dataset and accepting the sshfs path, or by restructuring your TrueNAS datasets so the entire backup target is a single flat dataset with no child datasets underneath.

What does the log show right after the cp command fails? There should be an error message before it falls back to sshfs.