Bug 6293 - Не монтируется NFS после обновления
: Не монтируется NFS после обновления
Status: CLOSED WORKSFORME
: Sisyphus
(All bugs in Sisyphus/mount)
: unstable
: all Linux
: P2 enhancement
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2005-03-21 15:18 by
Modified: 2005-08-30 13:37 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-03-21 15:18:42
При обновлении с 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:  
Монтирование разделов и продолжение нормального выполнения команд.
------- Comment #1 From 2005-03-21 15:21:20 -------
Перенаправляю по совету майнтейнера пакета.
------- Comment #2 From 2005-03-21 15:25:13 -------
Более того, mount-2.12p-alt1 легко размонтировал те nfs, на которых
mount-2.12p-alt2 зависал.
------- Comment #3 From 2005-03-21 16:03:56 -------
а подробнее ? версии ядра на обоих концах, настройки резолвера, опции
монтирования, вывод rpcinfo -p и exportfs -v на сервере, пожалуйста.
------- Comment #4 From 2005-03-21 16:16:16 -------
$ 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)
------- Comment #5 From 2005-03-21 16:56:34 -------
прошу убедиться в достижимости клиентом 111/tcp сервера.
------- Comment #6 From 2005-03-21 17:05:35 -------
Да, файрвол не пропускает обращения на tcp/111 с непривилегированных портов.
------- Comment #7 From 2005-03-21 17:26:33 -------
invalid -- блокировать portmapper плохая идея.
То, что это работало раньше, прошу считать недоразумением.
------- Comment #8 From 2005-03-21 17:50:19 -------
Не согласен с такой аргументацией.
Если возможность работать таким образом была в ALT Linux всегда, то объявлять её
недоразумением нельзя, для этого должны быть гораздо более веские доводы.
------- Comment #9 From 2005-03-21 18:59:39 -------
ok. какая нужда в блокировании доступа к 111/tcp с верхних портов,
принимая во внимание, что portmapper есть общее средство работы
с sun rpc, связанное с nfs поскольку-постольку ? бишь, я вполне
могу представить некий программный комплекс, компоненты которого
совершенно не обязаны обладать правами на открытие нижних портов.
Затем, я могу указать, что такое ограничение ломает работу qemu
в части работы с nfs за пределами localhost. Наконец, я не помню
утверждений в документации к дистрибутивам ALT Linux, гласящих,
что "работать таким образом возможно". Напротив, любое руководство
по nfs подразумевает либо явно указывает: portmap просто должен быть
period. 

Более приземлённо, в mount обсуждаемой сборки добавлена возможность
"предварительного" опроса сервера на предмет предоставляемых им
версий программ (в смысле rpc) и работающей поверх tcp.
Я нахожу эту возможность весьма полезной, и полагаю более ценной,
чем возможность работы в старом (и как минимум не рекомендованном)
режиме. Посему, снижаю до FR.
------- Comment #10 From 2005-04-08 16:16:58 -------
Оказывается, новый mount по умолчанию пробует монтировать nfs сначала по tcp, а
потом уже по udp.
После привязки rpc.mountd к фиксированному порту и пропускания оного через
firewall монтирование заработало.