Unfortunately, we cannot reproduce the exact configuration of each user.

"/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)

Thank you.
By reusing the same NFS config that fails on your server, I unfortunately could not reproduce the problem.
The only case where I saw the same error was when the shared directory already contained files, but you told me that was not your case.

We will work on improving error handling to better identify NFS server-specific problems.

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)

It seems the problem happens when the directory shared contains non-hidden files.
Can you try to add a NFS remote with encryption on an new empty directory, and let us know if it works?

This is not specified, but the encrypted remote must not contain encrypted and unencrypted file, as they may conflict.
We should add this information.

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

The problem doesn't happen on our enterprise NFS server with encryption.

But I tested on a freshly installed personal NFS server, and I get the same error as you if I use encryption.

We are investigating and will keep you informed.

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

Hi,

Can you see if the specified path and file exist?

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

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

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.

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?

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.