XO Remote mount.nfs: access denied by server while mounting
-
Hello. I hope this is the correct place to post.
I have an NFS share (OpenMediaVault) which I can see when I use showmount -e 192.168.11.60 and indeed I can seemingly mount it.
However when I try to add it as a remote it fails with error :
remote.test { "id": "729c5b06-a016-4beb-8189-763aec47c2dd" } { "shortMessage": "Command failed with exit code 32: mount -o -t nfs 192.168.11.60:/Backups /run/xo-server/mounts/729c5b06-a016-4beb-8189-763aec47c2dd", "command": "mount -o -t nfs 192.168.11.60:/export/Backups /run/xo-server/mounts/729c5b06-a016-4beb-8189-763aec47c2dd", "escapedCommand": "mount -o \"\" -t nfs \"192.168.11.60:/Backups\" \"/run/xo-server/mounts/729c5b06-a016-4beb-8189-763aec47c2dd\"", "exitCode": 32, "stdout": "", "stderr": "mount.nfs: access denied by server while mounting 192.168.11.60:/Backups", "failed": true, "timedOut": false, "isCanceled": false, "killed": false, "message": "Command failed with exit code 32: mount -o -t nfs 192.168.11.60:/Backups /run/xo-server/mounts/729c5b06-a016-4beb-8189-763aec47c2dd mount.nfs: access denied by server while mounting 192.168.11.60:/Backups", "name": "Error", "stack": "Error: Command failed with exit code 32: mount -o -t nfs 192.168.11.60:/Backups /run/xo-server/mounts/729c5b06-a016-4beb-8189-763aec47c2dd mount.nfs: access denied by server while mounting 192.168.11.60:/Backups at makeError (/home/node/xen-orchestra/node_modules/execa/lib/error.js:60:11) at handlePromise (/home/node/xen-orchestra/node_modules/execa/index.js:118:26) at NfsHandler._sync (/home/node/xen-orchestra/@xen-orchestra/fs/src/_mount.js:64:7)" }
Does a remote mount NFS differently to say an ISO SR?
-
@daninmanchester said in XO Remote mount.nfs: access denied by server while mounting:
"stderr": "mount.nfs: access denied by server while mounting 192.168.11.60:/Backups",
Would appear to be a rights issue to me.
-
@Danp I thought as much and have been playing with the settings without success. I don't know a lot about NFS.
I'm using the following options at present, but have tried with various users and groups, etc.
rw,all_squash,insecure,async,no_subtree_check,anongid=100,crossmnt
-
@daninmanchester Run the "showmount" comand against your NFS server to see if you have access permissions. https://www.thegeekdiary.com/showmount-command-examples-in-linux/
-
@tjkreidl verified they can be seen :
Export list for 192.168.11.60:
/export/Backups 192.168.11.0/24
/export/Everyone 192.168.11.0/24
/export 192.168.11.0/24 -
@daninmanchester What does showmount list for the server exports? Is the local 192.168.X.X subnet properly exported from the NFS server? Check the /etc/exports files on the NFS server and make sure that directory is listed. BTW, do you have any sort of multipathing implemented?
-
I don't touch things manually, it's done through OMV. This is the exports file. I don't have any multipathing as far as I know. It's not something I've set up.
# This file is auto-generated by openmediavault (https://www.openmediavault.org) # WARNING: Do not edit this file, your changes will get lost. # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). /export/Everyone 192.168.11.0/24(fsid=94a977de-432c-4653-9870-a1cd0a83110d,ro,subtree_check,insecure,crossmnt) /export/Backups 192.168.11.0/24(fsid=bb941285-c5d8-492d-9b49-43a2dc30557c,rw,all_squash,insecure,async,no_subtree_check,anongid=100,crossmnt) # NFSv4 - pseudo filesystem root /export 192.168.11.0/24(ro,fsid=0,root_squash,no_subtree_check,hide) /export 192.168.11.70(ro,fsid=0,root_squash,no_subtree_check,hide)
-
@daninmanchester Hmmm...maybe an NFS V3 vs. V4 support issue? Could you provide the full output of "showmount -e 192.168.11.60" ?
-
@tjkreidl what version should I be using or can I force XO to use a particular version?
It doesn't output any more than I shared last time :
bash-5.1# showmount -e 192.168.11.60
Export list for 192.168.11.60:
/export/Backups 192.168.11.0/24
/export/Everyone 192.168.11.0/24
/export 192.168.11.0/24
bash-5.1#It just occurred to me, I'm running XO in a docker not direct on the host. Do I need some network config to enable NFS?
-
@daninmanchester Have you read this info?
-
@Danp said in XO Remote mount.nfs: access denied by server while mounting:
@daninmanchester said in XO Remote mount.nfs: access denied by server while mounting:
"stderr": "mount.nfs: access denied by server while mounting 192.168.11.60:/Backups",
Would appear to be a rights issue to me.
@tjkreidl verified they can be seen :
Export list for 192.168.11.60:
/export/Backups 192.168.11.0/24
/export/Everyone 192.168.11.0/24
/export 192.168.11.0/24do you need to add "/export" (/export/Backups ) to be able to find the right path?
-
@HeMaN Yes, if I recall correctly, in the /etc/exports file. the full path should be specified and then "exportfs -a" should be issued to refresh the export list.
I just noticed your error message doesn't include the /export directory in front:
mount.nfs: access denied by server while mounting 192.168.11.60:/Backups -
@Danp no, I hadn't seen that. but I think I have now done this without any change to my issue. One thing that wasn't 100% clear is where sudoers should be on docker.
/etc/sudoers?
-
@tjkreidl I have tried various flavors.
-
Well .... I'm totally baffled.
I've tried reapplying permissions.
forcing the server UID/GID
forcing the client UID/GID.
NOACLs
Squashing.One thing I can say, is that it is working on my host so it must be something about my XO setup trying to talk to it. which may well still be permissions.
-
okay, so I further narrowed it down. on the host machine I can mount. it is only within the docker container it is the issue. either at the command line or at XO. This leads me to believe this is a docker related problem not XO.
Sorry to have taken up your time, but thanks very much for your help!
At least i have a clear direction to google now. -
What is the IP address of the host that is running XO?
The docker container will need the SYS_ADMIN capability to do NFS mounts.
-
@daninmanchester I would think Docker is involved, as well. I was going to suggest to create a "standard" test VM ans see if you can connect storage to it. If so, that would put the blame on something specific to the VM that has that Docker container.
-
@mjtbrady That seems right, because the Docker instanceis independent and internal to the VM that otherwise is part of the XCP-ng networking structure and wouldn't have the necessary access permissions on it's own.
-
Could this be due to a missing package (nfs-common)?