Impossible d'installer NFS à partir d'Ubuntu 14.04.1 LTS sur QNAP NAS

Question

Notez qu'il s'agit d'une question de publication croisée dans la communauté QNAP NAS ici: http://forum.qnap.com/viewtopic.php?f=35&t=96526&p=427018#p427018 =

Tous les commentaires et suggestions, ainsi que les pointeurs d'informations pertinentes sont très appréciés.

Je ne peux pas monter NFS à partir de mon client NFS exécutant Ubuntu 14.04.1 (LTS) sur mon serveur NFS (QNAP NAS). Mon environnement est:

Serveur NFS: QNAP TS-669 Pro exécutant le microprogramme 4.1.0 (daté du 2014/06/12)
Client NFS: ECS LIVA (un petit ordinateur barebone) exécutant Ubuntu 14.04.1 LTS Desktop.
Les deux systèmes sont connectés via Ethernet 1000Base-T et sont accessibles via IP.
La résolution de nom est effectuée par le registre local (/ etc/hosts) et la commande getent hosts Host-name renvoie l'adresse IP correcte et cohérente sur les deux nœuds.
Le service NFS est activé sur le serveur NFS et le droit d'accès NO_LIMIT est attribué au dossier de partage spécifique, à savoir "/ nfs", à l'onglet "Accès à l'hôte NFS" de l'application de configuration "Dossiers partagés": en fait, je peux le confirmer. Le monde NFS est-il exporté via la commande "exportfs -rva" sur le NAS?.
Ubuntu (le client NFS) n’installant pas les packages du client NFS par défaut, j’ai explicitement installé le package nfs-common comme décrit dans la section suivante: Configuration de NFS HOW-TO ( https://help.ubuntu.com/ community/SettingUpNFSHowTo # NFS_Client ); Le paquetage rpcbind semble être installé par défaut.

Sur le client NFS, si je lance la commande "mount -t nfs nas:/nfs/mnt" , le résultat est "mount.nfs: La connexion a expiré "après cinq ou dix minutes plus tard. Le même résultat est renvoyé même si je spécifie le protocole NFS version 3 avec l'option -overs = 3 lors de la tentative de montage NFS. De plus, la commande " showmount -e " répertorie les noms de dossier partagé (répertoire) NFS exportés, mais il faut également cinq ou 10 minutes pour le terminer.

Sur le serveur NFS, la commande "exportfs -rva" renvoie le message d'avertissement suivant, mais j'estime que le message ne concerne pas le problème (I accède au NAS via SSH dans cet exemple de code):

[~] # 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

Sur le client NFS, la commande de montage mount est longue (plus de cinq minutes). J'ai spécifié l'option vers = 3, car je comprends que QNAP ne prend pas en charge NFS V4 par défaut et que NFS V3 suffit à mon besoin. Peu importe que vous spécifiiez ou non les options tcp et/ou nolock (même comportement).

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

Sur le client NFS, portmapper fonctionne parfaitement avec NFS version 2, 3 et 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

Sur le serveur NFS, j’ai essayé de vérifier si le pormapper s’exécute à partir du client NFS, car il n’a pas la valeur Commande rpcinfo installée:

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

La dernière commande ( rpcinfo ) prend beaucoup de temps (plus de cinq minutes) pour terminer ce qui reproduit la cause fondamentale du problème, je crois. Veuillez noter que sur les deux ports TCP, 2049 et 41687, les processus démons appropriés écoutent sur le NAS. Je peux confirmer ce fait puisque la commande nc retourne instantanément sur le client NFS contre NAS, comme indiqué dans le résultat suivant:

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!

Curieusement, je peux monter NFS version 3 sur NAS lui-même, comme indiqué dans la sortie suivante (j'accède au NAS via SSH dans cet exemple de code):

[~] # 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

Bien qu'il semble que j'ai un problème de ports bloqués sur le client NFS, mais il semble que Ubuntu 14.04.1 n'active pas ufw (pare-feu simple, il s'agit en fait d'une interface frontale pour iptables) par défaut, comme le montre le wiki suivant. document: Pare-feu simple (en quelque sorte, je ne peux pas mettre l'URL du wiki ici). Je ne peux rien confirmer qui soit bloqué en exécutant la commande sur le client NFS:

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

suekichi5 · Accepted Answer

Il s’avère que le problème est dû au micrologiciel du commutateur Ethernet que j’utilise (NetGEAR GS116Ev2). Après la mise à jour du firmware 2.0.1.17 à partir de la version 2.0.0.23, le problème a disparu.