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.
