NFS Remote encryption problem
-
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 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.
-
Okay pinging julien-f about the encryption seems broken.
-
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: worksThis 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 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.
-
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.
-
djingo said in NFS Remote encryption problem:
"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?
-
stephane-m-dev the path exists but it was empty.
-
djingo said in NFS Remote encryption problem:
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.
-
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 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?
-
djingo Do you have any error logs on the unraid server side?
-
stephane-m-dev i checked, there was nothing
-
djingo Can you share your NFS config file (/etc/exports) ?
-
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)
-
djingo said in NFS Remote encryption problem:
"/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.
-
Maybe some hidden files? (eg be sure to display all files even hidden ones)
-
olivierlambert No, in the code we only check for non-hidden files, and djingo checked that the directory was totally empty.
-
olivierlambert ls -halF - nothing was there
-
stephane-m-dev well, have you tried this on an unraid server with a disk share? if not, you are still missing my point.
