На коробке, недавно обновленной с SLES 9.3 до 10.2, я вижу следующую проблему:
Перед обновлением монтирование NFS (определенное через yast, т.е. появившееся в /etc/fstab) работал правильно. Однако после обновления он не работает. Сетевая трассировка показывает, что он устанавливает начальное соединение с сервером NFS через TCP (для RPC сопоставителя портов), но затем переключается на UDP для последующего вызова MOUNT; поскольку сервер NFS не разрешает UDP (по уважительной причине из-за возможных проблем с повреждением данных, как в nfs(5)) соединение не будет установлено.
Добавление параметра TCP (в fstab, в командной строке и т. Д.) Не имеет никакого эффекта.
В ходе устранения неполадок я обнаружил, что / var / adm / messages сообщает о следующих событиях во время загрузки:
Failed services in runlevel 3: network
(Я должен отметить, что, несмотря на это сообщение об ошибке, очевидно, по крайней мере, некоторые сетевые службы запущены, поскольку ящик доступен через SSH.)
Тогда мои вопросы:
Редактирование, чтобы добавить некоторую информацию, относящуюся к ответам ниже.
Оказывается, сетевая служба дает сбой при загрузке, потому что один из интерфейсов (на этом поле их два) использует DHCP, а он пока недоступен. Итак, я отключил его на данный момент, остановил / перезапустил сетевую службу и клиентские службы NFS, но все равно получил те же результаты.
На стороне клиента нет брандмауэра. Кроме того, iptables -L на стороне клиента показывает, что все принято; и нет записей в /etc/hosts.allow или /etc/hosts.deny.
На стороне сервера NFS ничего не изменилось. Удаленный сервер nfsserver действительно сообщает, что разрешает использование TCP и UDP для всех служб NFS (хотя существует правило iptables, блокирующее UDP).
Запись в / etc / fstab довольно проста - что вы получите, настроив ее в yast:
x.x.x.x:/volume /localdir nfs defaults 0 0
rpcinfo -p для окна клиента показывает только работающий portmapper v2, объявляющий и TCP, и UDP. Для сервера он показывает все обычные службы:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 4047 status
100024 1 tcp 4047 status
100011 1 udp 4049 rquotad
100021 1 udp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100021 4 udp 4045 nlockmgr
100021 1 tcp 4045 nlockmgr
100021 3 tcp 4045 nlockmgr
100021 4 tcp 4045 nlockmgr
100005 1 udp 4046 mountd
100005 1 tcp 4046 mountd
100005 2 udp 4046 mountd
100005 2 tcp 4046 mountd
100005 3 udp 4046 mountd
100005 3 tcp 4046 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
Вызов mount с записью / etc / fstab выше выглядит просто:
mount /localdir
хотя я также пробовал это с различными параметрами, такими как tcp, v3 и т. д.
И запись / etc / fstab (отсюда монтирование), и вызов rpcinfo -p используют IP-адрес, поэтому проблем с разрешением DNS не возникает.
Пара вещей. Во-первых, вы с самого начала заявляете, что since the NFS server doesn't allow UDP, а затем в вашем редактировании упомянуть The remote nfsserver is indeed advertising that it allows both TCP and UDP for all of the NFS services. Это кажется немного странным. Почему сервер рекламирует то, что не позволяет?
Во-вторых, вы пытаетесь использовать NFS версии 2 или 3? Версия 2 поддерживает только UDP, тогда как вам нужна версия 3 для TCP. Возможно, поможет указание версии 3 в параметрах монтирования вручную? (vers = 3) Если по умолчанию установлено значение 2, то даже указание TCP не принесет вам никакой пользы.
У меня также были проблемы с новыми клиентами, пытающимися использовать версию 4, когда сервер не совсем ее поддерживал. Ваше обновление SLES могло привести к другой версии по умолчанию. Это еще одна причина указать это явно.
Почему бы вам тоже не разместить запись в / etc / fstab?
насколько я понимаю ваш вопрос, вы можете сделать следующее:
rpcinfo от клиента к серверуно вы не можете смонтировать файловую систему с сервера nfs на клиенте nfs и не получите никаких сообщений об ошибках.
в чем разница между вашим rpcinfo и mount звонки? вы используете ip-адрес в одном и fqdn в другом? не могли бы вы опубликовать обе команды с выводом и кодом возврата?
Убедитесь, что /etc/hosts.deny не содержит записи для mountd, и проверьте hosts.allow, по схожим причинам. Как бы то ни было, я обычно убираю hosts.deny и использовать iptables для контроля доступа.
Использовать rpcinfo -p nfsserver чтобы гарантировать, что mountd действительно рекламирует TCP - есть вариант -n для отключения TCP-прослушивания, которое (IIRC на SuSE), вероятно, будет установлено в /etc/sysconfig/nfs или около того.
service network restart и посмотрите, какие сообщения вы получите. Там должна быть какая-то информация.Попробуйте установить вещи явно и посмотрите, к чему это приведет. Например, в / etc / fstab:
x.x.x.x:/vol /local nfs proto=tcp,port=2049,mountport=4046,nfsvers=3 0 0
Это должно как минимум обойти portmapper и явно попытаться подключиться к TCP-портам, которые вы перечислили выше, и упростить tcpdump трассировку каждого канала во время отладки.
Для справки, если кто-то еще сталкивается с этим вопросом и хочет получить ответ:
Я наконец открыл заявку на это с Novell. Оказывается, это известная ошибка в SLES 10.2 (491140: mount игнорирует "proto =" для "nfs"), и для нее есть патч (util-linux-2.12r-35.35.2.x86_64.rpm) . После установки монтирование работает должным образом, и все запросы выполняются через TCP. (Служба поддержки Novell также сообщила мне, что это объединено в SLES 10.3.)