Обратите внимание, что это вопрос о перекрестном размещении в сообществе NAS QNAP: http://forum.qnap.com/viewtopic.php?f=35&t=96526&p=427018#p427018
Любые комментарии и предложения, а также указатели на соответствующие информационные элементы очень оценены.
Я не могу подключить NFS из моего клиента NFS, работающего под Ubuntu 14.04.1 (LTS), против мой сервер NFS (NAS QNAP). Моя среда:
Сервер NFS: QNAP TS-669 Pro с прошивкой 4.1.0 (от: 2014/06/12) Клиент NFS: ECS LIVA (маленький barebone-компьютер) с Ubuntu 14.04.1 LTS Desktop. Эти две системы подключаются через 1000Base-T Ethernet и IP. Разрешение имен выполняется локальным реестром (/ etc / hosts), а команда host-name getent hosts возвращает правильный и согласованный IP-адрес на обоих узлах. Служба NFS включена на сервере NFS, а право доступа NO_LIMIT указывается в отдельной папке общего доступа, а именно «/ nfs», на вкладке «Доступ к узлу NFS» в приложении конфигурации «Общие папки»: на самом деле, я могу подтвердить это является мировым NFS, экспортированным путем выпуска команды «exportfs -rva» на NAS. Поскольку Ubuntu (клиент NFS) не устанавливает клиентские пакеты NFS по умолчанию, я явно установил общий пакет nfs, как описано здесь: Настройка NFS HOW-TO (https://help.ubuntu.com/community/SettingUpNFSHowTo# NFS_Client); По-видимому, пакет rpcbind устанавливается по умолчанию.На клиенте NFS, если я запустил команду «mount -t nfs nas: / nfs / mnt», после 5 или 10 минут выдает вывод «mount.nfs: Connection timed out». Тот же результат возвращается, даже если я укажу протокол NFS версии 3 с параметром -overs = 3 при попытке монтирования NFS. Кроме того, команда «showmount -e» в конечном итоге перечисляет имена экспортированных NFS-общих папок (каталогов), но она также занимает пять или 10 минут.
На сервере NFS [mount] Команда t nfs nas: / nfs / mnt " возвращает следующее предупреждающее сообщение, но я уверен, что сообщение не связано с проблемой (я обращаюсь к NAS через SSH в этом коде):
[~] # 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
На клиенте NFS команда mount занимает много времени (более пяти минут). Я определил вариант vers = 3, потому что я понимаю, что QNAP по умолчанию не поддерживает NFS V4, а NFS V3 - мое требование. Не имеет значения, указали ли параметры tcp и / или nolock (такое же поведение).
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
На клиенте NFS mount видит, что отлично работает с версией NFS 2, 3 и 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
На сервере NFS я попытался проверить, запущен ли pormapper на нем от клиента NFS, так как у него нет showmount -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
Более поздняя команда ( pormapper ) занимает много времени (более пяти минут) для завершения, которая реплицирует основную причину проблемы, я считаю , Обратите внимание, что на обоих портах TCP, 2049 и 41687, соответствующие процессы демонов прослушиваются на NAS. Я могу подтвердить этот факт, так как команда nc мгновенно возвращает клиента NFS на NAS, как показано на следующем выходе:
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!
Как ни странно, я могу монтировать NFS версии 3 на самом NAS, как показано в следующий вывод (я обращаюсь к NAS через SSH в этом коде 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
Хотя похоже, что у меня есть проблема с заблокированными портами в NFS Client, но, похоже, Ubuntu 14.04.1 не разрешает ufw (несложный брандмауэр, на самом деле это интерфейс для iptables) по умолчанию, как показано в следующем документе wiki: Uncomplicated Firewall (так или иначе, я не могу поместить здесь URL-адрес вики). Я ничего не могу подтвердить, заблокировав его, выполнив команду на клиенте 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
Я провел последние ночи в поисках причины неприятностей, общих для вас (долгое время ответа на showmount или rpcinfo). Он заканчивается отключением функции DoS-предотвращения двух разных MANAGED SWITCHES, которые блокировали nfs portmap (тихо, без журнала). nfs не работает с помощью нового управляемого коммутатора - не знаю, почему - DoS двух переключателей ZyXel ломает portmap