3

Note, this is a cross posting question in the QNAP NAS community here: http://forum.qnap.com/viewtopic.php?f=35&t=96526&p=427018#p427018

Any comments and suggestions, as well as pointers to relevant information pieces are very appreciated.


I cannot NFS mount from my NFS client running Ubuntu 14.04.1 (LTS) against my NFS server (QNAP NAS). My environment is:

  • NFS Server: QNAP TS-669 Pro running firmware 4.1.0 (dated: 2014/06/12)
  • NFS Client: ECS LIVA (a small barebone PC) running Ubuntu 14.04.1 LTS Desktop.
  • The two systems are connected via 1000Base-T Ethernet and IP reacheable.
  • Name resolution is done by local registry (/etc/hosts) and getent hosts host-name command returns the correct and consistent IP address on both nodes.
  • NFS service is enabled on the NFS server and NO_LIMIT access right is given on the specific share folder, namely "/nfs", on the "NFS host access" tab of the "Shared Folders" configuration app: in fact, I can confirm it is world NFS exported via issueing the "exportfs -rva" command on NAS.
  • Because Ubuntu (the NFS client) does not install NFS client packages by default, I explicitly installed the nfs-common package as described in here: Setting Up NFS HOW-TO ( https://help.ubuntu.com/community/SettingUpNFSHowTo#NFS_Client ); The rpcbind package seems to be installed by default.

On the NFS client, If I run the command "mount -t nfs nas:/nfs /mnt", it gives the output "mount.nfs: Connection timed out" after five or 10 minutes later. The same result is returned even if I specify NFS version 3 protocol with -overs=3 option while trying to NFS mount. Also the command "showmount -e" lists up the exported NFS shared folder (directory) names eventually, but it also takes five or 10minutes to complete.

On the NFS server, the "exportfs -rva" command returns the following warning message, but I do believe the message does not relate with the problem (I am accessing the NAS via SSH in this code exmple):

[~] # exportfs -rva
exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/share/MD0_DATA/Public".
Assuming default behaviour ('no_subtree_check').   NOTE: this default has changed since nfs-utils version 1.0.x

exportfs: /etc/exports [2]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/share/MD0_DATA/nfs".
Assuming default behaviour ('no_subtree_check').   NOTE: this default has changed since nfs-utils version 1.0.x

exporting *:/share/MD0_DATA/nfs exporting *:/share/MD0_DATA/Public

On the NFS client, the mount command takes long time (more than five minutes) to complete. I specified the vers=3 option, because I understand QNAP does not support NFS V4 by default and NFS V3 suffices my requirement. It does not matter whether or not specifying the tcp and/or nolock options (same behavior).

root@livak5:~# mount -t nfs -vvv -overs=3,tcp,nolock nas:/share/MD0_DATA/nfs /mnt
mount: fstab path: "/etc/fstab"
mount: mtab path:  "/etc/mtab"
mount: lock path:  "/etc/mtab~"
mount: temp path:  "/etc/mtab.tmp"
mount: UID:        0
mount: eUID:       0
mount: spec:  "nas:/share/MD0_DATA/nfs"
mount: node:  "/mnt"
mount: types: "nfs"
mount: opts:  "vers=3,tcp,nolock"
mount: external mount: argv[0] = "/sbin/mount.nfs"
mount: external mount: argv[1] = "nas:/share/MD0_DATA/nfs"
mount: external mount: argv[2] = "/mnt"
mount: external mount: argv[3] = "-v"
mount: external mount: argv[4] = "-o"
mount: external mount: argv[5] = "rw,vers=3,tcp,nolock"
mount.nfs: timeout set for Sun Aug 24 11:24:44 2014
mount.nfs: trying text-based options 'vers=3,tcp,nolock,addr=192.168.11.50'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100005 vers 3 prot TCP port 41687
mount.nfs: mount(2): Connection timed out
mount.nfs: trying text-based options 'vers=3,tcp,nolock,addr=192.168.11.50'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100005 vers 3 prot TCP port 41687
mount.nfs: mount(2): Connection timed out
mount.nfs: trying text-based options 'vers=3,tcp,nolock,addr=192.168.11.50'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100005 vers 3 prot TCP port 41687
mount.nfs: mount(2): Connection timed out
mount.nfs: Connection timed out

On the NFS client, portmapper seeems working just fine against NFS version 2, 3, and 4:

root@livak5:~# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  57148  status
    100024    1   tcp  52831  status

On the NFS server, I tried to check if the pormapper is runing on it from the NFS client, since it does not have the rpcinfo command installed:

root@livak5:~# nc -zv nas 111
Connection to nas 111 port [tcp/sunrpc] succeeded!
root@livak5:~# rpcinfo -s nas
   program version(s) netid(s)                         service     owner
    100000  2,3,4     local,udp,tcp                    portmapper  superuser
    100011  2,1       tcp,udp                          rquotad     superuser
    100005  3,2,1     tcp,udp                          mountd      superuser
    100003  3,2       udp,tcp                          nfs         superuser
    100227  3,2       udp,tcp                          -           superuser
    100021  4,3,1     tcp,udp                          nlockmgr    superuser
    100024  1         tcp,udp                          status      superuser

The later command (rpcinfo) takes long time (more than five minutes) to complete which replicates the problem root cause, I believe. Please note that on both the TCP ports, 2049 and 41687, appropriate daemon processes are listening on NAS. I can confirm this fact since the nc command returns instantly on the NFS client against NAS as shown in the following output:

root@livak5:~# nc -zv nas 2049
Connection to nas 2049 port [tcp/nfs] succeeded!
root@livak5:~# nc -zv nas 41687
Connection to nas 41687 port [tcp/*] succeeded!

Strangely enough, I can NFS version 3 mount on NAS itself as shown in the following output (I am accessing the NAS via SSH in this code exmple):

[~] # mkdir /mnt2
[~] # mount -overs=3 nas:/share/MD0_DATA/public /mnt2
[~] # df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/ram0               154691    137854     16837  89% /
devtmpfs               1531580         4   1531576   0% /dev
tmpfs                    65536       160     65376   0% /tmp
/dev/md9                521684    126312    395372  24% /mnt/HDA_ROOT
/dev/md0             11622485880 410664920 11211296672   4% /share/MD0_DATA
/dev/md13               379888    259868    120020  68% /mnt/ext
tmpfs                    32768         0     32768   0% /.eaccelerator.tmp
nas:/share/MD0_DATA/public/11622485888 411189216 11211296672   4% /mnt2

Although it looks as if I have some sort of blocked ports problem on NFS Client, but it seems Ubuntu 14.04.1 does not enable ufw (uncomplicated firewall, it is actually a front-end to iptables) by default as shown in the following wiki document: Uncomplicated Firewall (somehow, I cannot put the wiki URL in here). I can confirm nothing blocked on it by running command on the NFS client:

root@livak5:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
0

2 Answers 2

0

It turns out the problem root cause is the firmware bug of Ethernet Switch I am using (NetGEAR GS116Ev2). After updating the firmware to 2.0.1.17 from 2.0.0.23, the problem is gone.

1
  • 1
    That looks like a downgrade. Are you sure you moved from 2.0.1.17 to 2.0.0.23?
    – user68186
    Aug 28, 2014 at 14:22
-1

I spent recent nights searching for the reason of troubles, common to Yours (long time to reply on showmount or rpcinfo). It ends by turning off the DoS-prevention feature of two different MANAGED SWITCHES, that blocked nfs portmap (silently, no log). nfs unworkable using new managed switch - no idea why - DoS of two ZyXel switches breaks portmap

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .