У меня есть экспорт NFSv3 с файлового сервера Linux, который раньше нормально монтировался. Файловый сервер был отключен для обслуживания оборудования. После восстановления сервера клиент Linux больше не может монтировать экспорт nfs.
На сервере или клиенте конфигурация не изменилась. Я сделал обновление программного обеспечения и перезагрузил клиент после неудачного первого монтирования, но это не помогло.
[root@client ~]# showmount -e ark
Export list for ark:
/mnt/bigraid *
[root@client ~]# mount -t nfs ark:/mnt/bigraid raid
Он просто зависает на этом месте. В другом терминале ...
[root@client ~]# dmesg | tail
[ 2526.676437] nfs: server ark not responding, timed out
[ 2529.183107] nfs: server ark not responding, timed out
[ 2531.689778] nfs: server ark not responding, timed out
[ 2538.196432] nfs: server ark not responding, timed out
[ 2540.703107] nfs: server ark not responding, timed out
[ 2543.209767] nfs: server ark not responding, timed out
[ 2545.716436] nfs: server ark not responding, timed out
[ 2548.223098] nfs: server ark not responding, timed out
[ 2550.729775] nfs: server ark not responding, timed out
[ 2557.236435] nfs: server ark not responding, timed out
... Хорошо, но я мог видеть экспорт с помощью showmount ...
[root@client ~]# ping ark
PING ark.homebase (10.10.10.2) 56(84) bytes of data.
64 bytes from ark.homebase (10.10.10.2): icmp_seq=1 ttl=64 time=0.067 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=3 ttl=64 time=0.048 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=4 ttl=64 time=0.042 ms
^C
--- ark.homebase ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
Так что я не понимаю.
На сервере работает OpenSUSE. Я удостоверился, что брандмауэр выключен (не то, чтобы он когда-либо был включен) и что сетевое соединение кажется нормальным.
ark:/etc # cat exports
/mnt/bigraid *(rw,root_squash,insecure,no_subtree_check,sync)
Изменить: вот список используемых портов RPC
ark:/etc/init.d # rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100005 1 udp 37599 mountd
100005 1 tcp 33880 mountd
100005 2 udp 37599 mountd
100005 2 tcp 33880 mountd
100005 3 udp 37599 mountd
100005 3 tcp 33880 mountd
100024 1 udp 49522 status
100024 1 tcp 41314 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 51887 nlockmgr
100021 3 udp 51887 nlockmgr
100021 4 udp 51887 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 tcp 49804 nlockmgr
100021 3 tcp 49804 nlockmgr
100021 4 tcp 49804 nlockmgr
100000 2 udp 111 portmapper
Изменить 2: Получил некоторую информацию о tcpdump
(Редактировать 3: удален вывод tcpdump, поскольку он может быть неактуальным.)
Я совершенно не знаком с тем, как выглядят настоящие переговоры по nfs. Я также скинул файл pcap, если вы хотите посмотреть на сегменты данных. Это в пипетка
Изменить 3: я могу ударить Эта проблема
Я последовал приведенному ниже совету @CIA и сделал следующее:
ark:/etc/init.d # ./nfsserver stop
Shutting down kernel based NFS server: nfsd statd mountd idmapd done
ark:/etc/init.d # ./portmap stop
Shutting down RPC portmap daemon done
ark:/etc/init.d # ./portmap start
Starting RPC portmap daemon done
ark:/etc/init.d # ./nfsserver start
Starting kernel based NFS server: idmapdexportfs: Warning: /mnt/bigraid does not support NFS export.
mountd statd nfsd sm-notify done
Несмотря на предупреждение, экспорт теперь кажется монтируемым.
Итак, NFS странно, потому что полагается на работающий portmapper, поэтому он может сопоставить определенный порт с портом RPC. (Думаю, в этом нет ничего странного. Просто это работает.) Если NFS работает раньше, чем portmapper, NFS не знает, как маршрутизировать запросы, потому что проверяет portmapper на это в начале процесса. Если portmapper не запущен до NFS, NFS не знает, как сопоставить порт с rpc.
Вот еще документация об этом процессе (хотя она и для CentOS, она все еще актуальна): http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s2-nfs-methodology-portmap.html
Что касается вашего нового сообщения об ошибке, перезагрузите блок, с которым вы монтируете, и перемонтируйте, чтобы увидеть, вернется ли ошибка.
tcpdump -i $LAN_IF -n host 10.10.10.2
должен показать вам, какой из компонентов NFS не работает.
Чтобы обобщить решение на основе данных ответов, следуя этим шагам, я направлю меня в правильном направлении к исправлению NFS, чтобы он успешно смонтировал без повторной установки коробки.
запустите tcpdump на клиентском сервере на IP-адрес сервера NFS (при условии, что это 1.2.3.4)
tcpdump -i <replace-with-correct-INTERFACE_name -n host 1.2.3.4
продолжайте запускать tcpdump и попробуйте смонтировать путь NFS.
сделать telnet для IP-адреса сервера NFS и все порты, которые вы получили из вывода tcpdump на шаге 3, и убедитесь, что у вас есть telnet на всех портах (в вашем случае только 2 порта ниже).
telnet 1.2.3.4 880
telnet 1.2.3.4 2049
если у вас нет telnet ни на одном из этих портов, захваченных на шаге 3, вам необходимо открыть эти порты на уровне netwrok (и брандмауэре, если он есть)
Ну, я получал ту же ошибку. Я понял, что единственная причина тайм-аута заключается в том, что соединение не было установлено должным образом. Углубившись в проблему, я проверил свой брандмауэр, и черт побери, служба NFS4 была заблокирована !!
Решение: - Используйте команду ниже, чтобы настроить параметры брандмауэра, и добавьте * рядом со службой NFS4, чтобы включить ее.
$ sudo system-config-firewall-tui
Включите следующие порты TCP и UDP для клиентов, чтобы получить доступ к общей папке nfs на сервере.
Для NFS3 tcp: 111,662,875,892,2020,2049,32803
UDP: 111,2049,32769
Для NFS4
TCP: 111,2049 UDP: 111,2049
Изменить: попробуйте telnet вышеуказанные порты от клиента nfs
Если у вас есть брандмауэр на основе хоста и вы используете nfs, проверьте:
http://wiki.debian.org/SecuringNFS
Вы могли указать, какие порты используют ваши демоны, чтобы они не назначались случайным образом.
В моем случае проблема заключалась в том, что сервер был перенумерован, но клиент все еще пытался подключиться к старому IP-адресу.
Это помогло определить проблему на клиентском хосте NFS:
mount | grep addr=