Подкаталоги NFS, предлагаемые Ubuntu, не могут быть считаны
ФАКТЫ
Ранее рабочему/etc/exports файлу, работая отлично на Debian, не удается работать как ожидалось над Ubuntu. Я могу экспортировать каталог верхнего уровня; клиенты могут смонтировать его и видеть, что один каталог уравнивает; но они не могут видеть другие подкаталоги, и они не могут смонтировать подкаталоги.
ОБСУЖДЕНИЕ
Во-первых, что-то, что работает просто немного:
/archive 192.168.0.0/255.255.255.0(fsid=root,crossmnt,rw,sync,no_root_squash,no_subtree_check)
fsid=root обязателен, по-видимому - не так на Debian - и crossmnt есть ли для тестирования.
Я могу смонтировать архив / на клиенте. Я могу убывать к/archive/dir1. Однако, когда клиенты пытаются прочитать каталог/archive/dir1, шоу каталога как пустой.
Затем я пробую версию с двумя строками/etc/exports:
/archive 192.168.0.0/255.255.255.0(fsid=root,crossmnt,rw,sync,no_root_squash,no_subtree_check)
/archive/dir1/dir2/dir3 192.168.0.0/255.255.255.0(rw,sync,no_root_squash,no_subtree_check)
Первая строка совпадает с ранее, и 2-я строка экспортирует подкаталог как отдельный объект. Снова, это работает просто великолепно при экспорте из Debian.
На данном этапе любая попытка смонтировать сбои/archive/dir1/dir2/dir3. На клиенте Debian клиент пытается использовать версию 4.2 NFS, жалобы на устаревший дескриптор файла, отступает к версии 3 и циклам на версии 3 бесконечно.
На клиенте Ubuntu, попытка смонтировать сбои с "Устаревшим дескриптором файла" использование версии 4 NFS; отступает к версии 3 и циклам между протоколами 6 и 17; и в конечном счете сбои.
Пожалуйста, примите во внимание: * Все клиенты находятся позади того же брандмауэра *, Никакая машина не выполняет внутренний брандмауэр (например, ufw отключен или прочь),
rpcinfo на сервере:
# 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
100005 1 udp 51505 mountd
100005 1 tcp 33248 mountd
100005 2 udp 59490 mountd
100005 2 tcp 46113 mountd
100005 3 udp 59750 mountd
100005 3 tcp 38367 mountd
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049
100227 3 tcp 2049
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 55501 nlockmgr
100021 3 udp 55501 nlockmgr
100021 4 udp 55501 nlockmgr
100021 1 tcp 37597 nlockmgr
100021 3 tcp 37597 nlockmgr
100021 4 tcp 37597 nlockmgr
rpcinfo на клиенте:
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
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049
100227 3 tcp 2049
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 56523 nlockmgr
100021 3 udp 56523 nlockmgr
100021 4 udp 56523 nlockmgr
100021 1 tcp 37425 nlockmgr
100021 3 tcp 37425 nlockmgr
100021 4 tcp 37425 nlockmgr
100024 1 udp 39290 status
100024 1 tcp 37851 status
100005 1 udp 52528 mountd
100005 1 tcp 43547 mountd
100005 2 udp 36593 mountd
100005 2 tcp 34609 mountd
100005 3 udp 42349 mountd
100005 3 tcp 45613 mountd
Наконец,
RPCMOUNTDOPTS="--manage-gids"
в/etc/default/nfs-kernel-server
Править
Возможный признак - то, что/var/lib/nfs/rmtab не актуален. Я ожидаю, когда сервер ядра nfs будет остановлен, rmtab был бы обновлен; или когда я неэкспортирую файловые системы (exportfs-ua); или когда я размонтировался в клиенте. Вместо этого rmtab продолжает поддерживать устаревшую информацию.
ДЕЙСТВИЯ
Я хотел бы предложения о том, как отладить эту проблему.
РЕДАКТИРОВАНИЕ 2
Еще несколько точек:
- Я проверил ACLs (ни один набор) и полномочия файла, и они, кажется, корректны.
- Даже после холодного завершения работы обоих клиентов и серверов, сделанных по другим причинам, я все еще получаю "устаревший дескриптор файла" ошибки.
Если я позволяю rpcdebug искать NFS proc, я вижу жалобу на
никакой путь обратного вызова к клиенту Linux NFSv4.2
но та ошибка не появляется для, например, MacOS или клиенты Ubuntu.
Я экспериментировал с абсолютно минималистским/etc/exports, но ни один не работает. Например,
/ что-то * (синхронизация, no_subtree_check)
не работает.
Сводка: эта проблема остается тяжелой, и IMO, это не простая проблема полномочий - если я не пропускаю установку где-нибудь, или даже всю программу или конфигурационный файл.
1 ответ
После обширного метода проб и ошибок я обнаружил то, что, кажется, причина отказа. Взгляд на /archive, Я заметил, что у меня был подкаталог того же имени, то есть, был a /archive/arhive.
Когда я удалил /archive/archive мои проблемы останавливаются по большей части. На основе содержания и полномочий того, из чего я видел, экспорт /archive на самом деле экспортировал /archive/archive.
Движение немного далее: я заметил это, когда я экспортирую /archive клиент монтируется как версия 4 NFS. Когда я монтирую подкаталог, а именно, /archive/dir1/dir2/dir3, тот подкаталог (тот же диск и для этого та же файловая система) монтируется как версия 3! Я все еще упорно ищу это, но тем временем я в порядке.
Если этот "подкаталог с тем же именем вызывает, плохо монтируются", требует отчета об ошибках, я могу воспроизвести это по желанию и описать то.