Cannot create NFS SR from QNAP

[nilsan]

Trying to create a new SR (VDI SR or ISO SR) from QNAP NAS NFS in Xen Orchestra fails.

I insert server IP address (withouth share path) in the Server field and click the spyglass icon. I then get a red popup error message "unknown error from the peer" with the following log message: "Cannot read property 'nfs-exports' of null".

This happens regardless of using NFSv3 or NFSv4.

However, I can both list exports (showmount) from the QNAP and mount shares if I do it manually in Linux on the XCP-ng host.

List of versions in use

• xoa: 5.30.0
• xo-server: 5.32.2
• xo-web: 5.32.1
• xcp-ng: 7.6.0
• QNAP TS-873U-RP: 4.3.5.0760

Extended log message from Xen Orchestra

sr.probeNfs
{
  "host": "281bbf63-56c4-405e-b3fb-b48f8fc492b7",
  "server": "172.18.9.34"
}
{
  "message": "Cannot read property 'nfs-exports' of null",
  "stack": "TypeError: Cannot read property 'nfs-exports' of null
    at Xo.<anonymous> (/usr/local/lib/node_modules/xo-server/src/api/sr.js:389:26)
    at throw (native)
    at asyncGeneratorStep (/usr/local/lib/node_modules/xo-server/dist/api/sr.js:40:103)
    at _throw (/usr/local/lib/node_modules/xo-server/dist/api/sr.js:42:291)
    at run (/usr/local/lib/node_modules/xo-server-xoa/node_modules/core-js/modules/es6.promise.js:75:22)
    at /usr/local/lib/node_modules/xo-server-xoa/node_modules/core-js/modules/es6.promise.js:92:30
    at flush (/usr/local/lib/node_modules/xo-server-xoa/node_modules/core-js/modules/_microtask.js:18:9)
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)"
}

xe sr-probe

[root@vm02 ~]# xe sr-probe type=nfs device-config:server=172.18.9.34
Error code: SR_BACKEND_FAILURE_101
Error parameters: , The request is missing the serverpath parameter,

showmount

[root@vm02 ~]# showmount -e 172.18.9.34
Export list for 172.18.9.34:
/vm      
/Public  
/Web     

rpcinfo

[root@vm02 ~]# rpcinfo -t 172.18.9.34 nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting
program 100003 version 4 ready and waiting

manual mount

[root@vm02 ~]# mount -v -t nfs 172.18.9.34:/vm /mnt
mount.nfs: timeout set for Thu Dec 13 12:08:33 2018
mount.nfs: trying text-based options 'vers=4,addr=172.18.9.34,clientaddr=10.187.2.8'

[root@vm02 ~]# df -h /mnt/
Filesystem       Size  Used Avail Use% Mounted on
172.18.9.34:/vm  5.5T   17G  5.5T   1% /mnt

[root@vm02 ~]# mount |grep mnt
172.18.9.34:/vm on /mnt type nfs4 (rw,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.187.2.8,local_lock=none,addr=172.18.9.34)

[olivierlambert]

Note: we can reproduce in NFS v4 only, this fails with xe CLI too, and XCP-ng Center. It seems the issue is the same on XenServer.

[Cory-Watson]

Having the same issue on XCP-ng Center 7.6.1 and 7.6.3.

Can mount NFS locally on the XCP-ng hosts, but XCP-ng Center always errors out:
"Creating SR
SM has thrown a generic python exception
Check your settings and try again."

[olivierlambert]

Do you have the same issue with XO and/or xe CLI?

[jbeangreen]

Error war erroneous. A simple change on the NFS for non root mount allowed and and a chmod 777 allowed xcp-ng to mount the ISO store.

[eelcovb]

Same issue here with XCP-NG 8.1 beta and NFS on QNAP QTS 4.4.1.

[nilsan]

I have some good news regarding this issue. I managed to create both VDI SR and ISO SR via NFS on QNAP units (cli only).

The main problem is that xe sr-probe returns an empty list, which means I get the log message "Cannot read property 'nfs-exports' of null" while trying to create SR in XOA.

sr-probe problem

[virt01] # xe sr-probe type=nfs device-config:server=172.18.250.33 device-config:serverpath=/ device-config:nfsversion=4
\<?xml version="1.0" ?>
\<SRlist/>

full XOA log

sr.probeNfs
{
  "host": "5c753d56-f10d-428a-bffe-9c5f2b80fc27",
  "server": "10.0.0.33"
}
{
  "message": "Cannot read property 'nfs-exports' of null",
  "name": "TypeError",
  "stack": "TypeError: Cannot read property 'nfs-exports' of null
    at Object.probeNfs (/usr/local/lib/node_modules/xo-server/src/api/sr.js:472:26)
    at <anonymous>"
}

manual mount works

[virt01] # showmount -e 10.0.0.33
Export list for 10.0.0.33:
/vm      
/iso     

[virt01] # mount -t nfs 10.0.0.33:/iso /mnt/

[virt01] # df -h /mnt/
Filesystem          Size  Used Avail Use% Mounted on
10.0.0.33:/iso   65T   17G   65T   1% /mnt

Create ISO SR

[virt01] # xe sr-create name=iso type=iso content-type=iso device-config:location=10.0.0.33:/iso name-label=iso device-config:nfsversion=4
>9256c30a-94ed-676c-26ec-7c822d10512f

Create VDI SR

[virt01] # xe sr-create type=nfs device-config:server=10.0.0.33 device-config:serverpath=/vm name-label=vm-storage device-config:nfsversion=4
2936a5fb-0afa-77ad-cc84-c0fb9c29d617

Observations

• NFS share has to be read/write (no read-only ISO SR)
• NFSv4 works, but has to be specified in via xe device-config:nfsversion=4
• I have an old pool which was upgraded from XenServer 6 to XCP-ng 7.6 where existing NFS SR work, but we can not create new ones. I have had this problem with all XCP-ng versions from 7.4 to 8.0.0.

[olivierlambert]

Some news, I have a theory on this issue: xapi-project/sm#511

[ventra007]

Hi,

I stumbled onto this thread, but I was looking for something related to Synology as I'm experiencing the same isssue.

I eventually did it via the cli, but as I'm running a pool with multiple hosts I had to modify the above command:

xe sr-create type=nfs device-config:server=(your server ip) device-config:serverpath=/yourpath name-label=(whatever) shared=true host-uuid=(the master host)

Hope this helps someone else, and perhaps devs can fix the way XO requests this from the web interface to how the cli does it?

Thanks

[olivierlambert]

Please check if there's an issue like this already opened or open a new one on XO bug tracker, linking it to here 👍

[olivierlambert]

Hi @ventra007 @nilsan @eelcovb @Cory-Watson @jbeangreen

Good news: we are about to get our fix merged in upstream! See xapi-project/sm#548

It was exactly what I suspected in xapi-project/sm#511

I don't know why some QNAP devices aren't returning ACLs, but now we handle the case anyway. When it's merged, we'll merge the fix in XCP-ng at some point (eg when we have other updates so it will go with an "update train").

Before that, it would be wonderful if you accept to test again with a package in our testing repo. If you are interested, we'll put that in testing so you can confirm the fix!

[benjamreis]

Hello a fix is available on our testing repo, you can run yum update sm sm-rawhba --enablerepo=xcp-ng-testing on an host, reboot and try again to create the NFS SR.

Please report if it solves your issue or not.

Regards

[stormi]

Hi everyone. Benjamin has made a fix for you 1 month ago, and it would really help to get feedback on it. Without this we won't make it an official update.

[benjamreis]

Hello!

Has anyone been able to test this update?
We really need the community feedback to make a real release of the update.

Thanks

[olivierlambert]

Our fix has been merged upstream: xapi-project/sm#548 🥳

@stormi should we close it here?

[stormi]

We can close. It's already available in current update candidate for sm and I've already got a ticket to track its release.