При обновлении с mount-2.12p-alt1 до mount-2.12p-alt2 начались зависания при выполнении mount -a -t nfs. При этом некоторые сетевые разделы монтируются, но после этого попытка их размонтировать приводит к тому же вечному зависанию, в т.ч. в режиме lazy unmount. Некоторые разделы не монтируются вообще. Откат к alt1 устранил все эти проблемы. Steps to Reproduce: 1. rpm -i mount-2.12p-alt2.i586.rpm 2. mount -a -t nfs Actual Results: Зависание. Expected Results: Монтирование разделов и продолжение нормального выполнения команд.
Перенаправляю по совету майнтейнера пакета.
Более того, mount-2.12p-alt1 легко размонтировал те nfs, на которых mount-2.12p-alt2 зависал.
а подробнее ? версии ядра на обоих концах, настройки резолвера, опции монтирования, вывод rpcinfo -p и exportfs -v на сервере, пожалуйста.
$ uname -r 2.4.27-std-up-alt3 Строки из /etc/fstab: basalt:/raid /raid nfs rsize=8192,wsize=8192,timeo=14,intr altair:/user /user nfs rsize=8192,wsize=8192,timeo=14,intr $ cat /etc/resolv.conf search office.altlinux.ru nameserver 10.1.0.3 nameserver 10.1.0.4 Далее привожу данные с basalt: $ uname -r 2.4.28-std-smp-alt2 $ /usr/sbin/rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100011 1 udp 993 rquotad 100011 2 udp 993 rquotad 100011 1 tcp 996 rquotad 100011 2 tcp 996 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100021 1 udp 32770 nlockmgr 100021 3 udp 32770 nlockmgr 100021 4 udp 32770 nlockmgr 100021 1 tcp 32768 nlockmgr 100021 3 tcp 32768 nlockmgr 100021 4 tcp 32768 nlockmgr 100005 1 udp 601 mountd 100005 1 tcp 604 mountd 100005 2 udp 601 mountd 100005 2 tcp 604 mountd 100005 3 udp 601 mountd 100005 3 tcp 604 mountd $ /usr/sbin/exportfs -v /raid 10.1.0.0/23(ro,wdelay,root_squash,all_squash)
прошу убедиться в достижимости клиентом 111/tcp сервера.
Да, файрвол не пропускает обращения на tcp/111 с непривилегированных портов.
invalid -- блокировать portmapper плохая идея. То, что это работало раньше, прошу считать недоразумением.
Не согласен с такой аргументацией. Если возможность работать таким образом была в ALT Linux всегда, то объявлять её недоразумением нельзя, для этого должны быть гораздо более веские доводы.
ok. какая нужда в блокировании доступа к 111/tcp с верхних портов, принимая во внимание, что portmapper есть общее средство работы с sun rpc, связанное с nfs поскольку-постольку ? бишь, я вполне могу представить некий программный комплекс, компоненты которого совершенно не обязаны обладать правами на открытие нижних портов. Затем, я могу указать, что такое ограничение ломает работу qemu в части работы с nfs за пределами localhost. Наконец, я не помню утверждений в документации к дистрибутивам ALT Linux, гласящих, что "работать таким образом возможно". Напротив, любое руководство по nfs подразумевает либо явно указывает: portmap просто должен быть period. Более приземлённо, в mount обсуждаемой сборки добавлена возможность "предварительного" опроса сервера на предмет предоставляемых им версий программ (в смысле rpc) и работающей поверх tcp. Я нахожу эту возможность весьма полезной, и полагаю более ценной, чем возможность работы в старом (и как минимум не рекомендованном) режиме. Посему, снижаю до FR.
Оказывается, новый mount по умолчанию пробует монтировать nfs сначала по tcp, а потом уже по udp. После привязки rpc.mountd к фиксированному порту и пропускания оного через firewall монтирование заработало.
