@stephane-m-dev understood. My suggestion regarding the different behavior (does not work with disk share, does work with user share) on unraid would be to put this in a "tip" in the documentation section about setting up Remotes.

@stephane-m-dev well, have you tried this on an unraid server with a disk share? if not, you are still missing my point.

@olivierlambert ls -halF - nothing was there

@stephane-m-dev

the disk share (there the error occurs):
"/mnt/disk3" -fsid=87,async,no_subtree_check 192.168.100.0/24(sec=sys,rw,no_root_squash,insecure) *(sec=sys,ro,insecure,anongid=100,anonuid=99,all_squash)

the user share (here it works):
"/mnt/user/backup" -fsid=91,async,no_subtree_check 192.168.100.0/24(sec=sys,rw,no_root_squash,insecure) *(sec=sys,ro,insecure,anongid=100,anonuid=99,all_squash)

please also do not overlook the other problem with the full backup mode when encryption is used: "Trying to add data in unsupported state" (see above)

@stephane-m-dev i checked, there was nothing

@stephane-m-dev the folder was positively empty, I explicitly removed all files before adding it as remote. Have you read what I wrote about different share types in unRAID?

@stephane-m-dev the path exists but it was empty.

@daniel-grimm definitely not related to cloud in my case!

I am now also seeing the "Trying to add data in unsupported state" problem,

see this thread: https://xcp-ng.org/forum/post/84594

That did never occur when the remote used for this backup was not encrypted.

I am seeing this problem on a encrypted NFS remote (server runs unRAID), too. Only one VM out of 6 VMs that get full backup. Always the same VM shows this error. The same schedule for these VMs did not produce this error on an unencrypted NFS remote on the same server. Also, using delta backup instead full backup on the same encrypted remote does not produce this error.

"stack": "Error: Trying to add data in unsupported state\n    at Cipheriv.update (node:internal/crypto/cipher:181:29)\n    at /etc/xen-orchestra/@xen-orchestra/fs/dist/_encryptor.js:52:22\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at async pumpToNode (node:internal/streams/pipeline:135:22)"

Are there any news regarding this issue?

@olivierlambert @julien-f OK I got this figured out and it may be worth putting this as a tipp in the XO documentation:

unRAID offers two kinds NFS exports as shares:

• user (a virtual fs layer across the array of several disks)
• disk (direkt fs access to the disk, not going through the array fs layer)

Normally the disk type share is more compatible and faster. This is where XO remote encryption does not work.

XO remote encryption works fine with the user type of shares.

I am currently running some backups to see if not just the mount works and that it is actually working in operation.

@olivierlambert thanks! I have tried to put the remote on a different filer and there it works with encryption.

unraid: does not work
truenas core: works

This was just for testing purposes. I cannot use the truenas filer, as it does not have enough storage for my XCP backups. The unRAID filer is my only option here. Is there any chance to figure out what goes wrong there?

The part that is irritating is that it works without encryption. The way I understood the implementation of remote encryption is that it is independent of the underlying storage (protocol) and thereby there should be no difference for the NFS daemon whether encryption is used or not. Right?

@olivierlambert I have setup a NFS remote for backup as I did in the XO from source. I get the exact same behavior as already described for the XO instance from source, i.e. the remote works without encryption and fails with encryption key, error is the same as described above.

@olivierlambert Yes sorry, I guess I was not patient enough, the import of the VM was incomplete, now it is running and XOA deployment at 80%. I will wait and let you know the outcome.

@olivierlambert OK i gave this a shot but deployment is stuck at 20%. I had provided valid network parameters. When looking at the XOA VM (using XO), I can see that the VIF is configured incorrectly (at least at this deploymentstage of 20%), although I have provided parameters that will work when they are actually used.

I can also tell you that a friend who wanted to try out XOA had the same problem, installation being stuck at 20%.

I don't think that XOA is the right path for me.

@olivierlambert oh sorry. I don't use XOA. Why would that make a difference? is encryption not working in XO for NFS remotes?

Please note that I am running this just in my homelab and I have no budget for licensing XOA features that I would need.

@olivierlambert yes, same problem with XO commit 78ae1

@olivierlambert XO from sources commit a7d7c

i cannot get the NFS Remotes encryption to work for me. When creating a new remote without encryption it works. When creating the same remote, but with an encryption key (32 characters, also tried hexadecimal format), it fails with:

"message": "ENOENT: no such file or directory, open '/run/xo-server/mounts/e782c43e-2ac7-472c-...etc.../metadata.json'",

(in both cases I have enabled "Store backup as multiple data blocks instead of a whole VHD file.")

Has anyone got this working, and what is the trick here (or my mistake)?