Монтирование NFS: владельцы — никто:nogroup

Question

Я смонтировал файловую систему NFS из оболочки, используя код:

LINE='nfs.mit.edu:/export/evodesign/beatdb /beatdb nfs tcp,intr,rw 0 0'
grep "$LINE" /etc/fstab >/dev/null || echo $LINE >> /etc/fstab
mkdir /beatdb
mount -a # Remount /etc/fstab Without Reboot in Linux

Я показываю файлы как nobody:nogroup:

Есть идеи, как исправить эту проблему и отобразить правильных владельцев?

Я использую Ubuntu 12.04.

Редактировать:

Клиентская часть (у меня нет доступа к NFS-серверу):

rpcidmapdбежит:

rpcinfo -p:

/etc/idmapd.conf:

Answer 1

Обращение за местной поддержкой или документацией кажется очень хорошей идеей :).

В форме контрольного списка, я думаю, вам нужно

1) требуемый пользователь(и), созданный(ые) в клиентской системе. Это можно сделать вручную, но следует ожидать наличия автоматической "службы каталогов", которую можно настроить. Это может быть LDAP.

2) сопоставление пользователей между клиентом и сервером. В NFS4(подразумевается опцией tcp)это обрабатывается idmapd, как упоминал gareth. Вам просто нужно установить домен, соответствующий тому, что думает сервер. Cross-domain не работает, я думаю, это ограничение Linux.

3) kerberos для аутентификации на сервере (доступно в NFS4). Если вы хотите получить доступ к файлам как кто-то другой, а не "никто", это определенно необходимо. Я предлагаю сначала настроить и протестировать kerberos. Его настройка будет включать в себя установку домена - вы установите тот же домен в idmapd.conf.

или с аутентификацией в стиле NFS3, 3) пропускается и вместо 2) вы просто проверяете, совпадает ли числовой UID пользователя с UID сервера. Это используется только в том случае, если сервер доверяет клиенту :).

Answer 2

Я преследовал похожую проблему. Установка /etc/idmapd.conf Verbosity=3 помогла увидеть некоторые проблемы в Ubuntu, но не все. Вот резюме моих выводов:

Все еще существует вероятность, что ваши файлы /etc/passwd и группы не разделяют тех же пользователей/групп, что и машина, которая предлагает общий доступ. Вот подсказка: ваша локальная машина должна иметь похожее сопоставление имен пользователей/групп через. /etc/nsswitch.conf, иначе операция сопоставления idmapd завершится неудачей. Обратите внимание, что если вы запустите Verbosity=3, вы увидите запись в /var/log/syslog, например:

idmapd[25193]: Клиент 64: (группа) имя "TheGroupNameYouExpected" -> id "65534

Если вы изменяете /etc/nsswitch.conf для сопоставления с чем-то, кроме файлов (например, ldap или nis), то вам также нужно убедиться, что ldap или nis действительно имеют запись какого-либо типа для имени пользователя или имени группы, для которых вы хотите транслировать идентификатор. Если запись не существует, idmapd не сможет успешно сопоставить пользователей/группы.

В связанных проблемах, которые я обнаружил для RHEL v7, служба idmapd.conf больше не требует включения для клиентов NFS:

https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c2

Однако в приведенном выше потоке есть запущенная проблема, заключающаяся в том, что по умолчанию службы, которые выполняют автоматическое сопоставление идентификатора и имени пользователя, имеют очень малое количество идентификаторов, которые остаются сопоставленными в памяти. Вместо того, чтобы регистрировать ошибку, idmapd просто отказывается переводить более 200 пользователей. Вы можете проверить это из текущих настроек ядра:

cat /proc/sys/kernel/keys/root_maxkeys    

Скорее всего, значение по умолчанию — 200. Чтобы точки монтирования NFS могли правильно отображать всех доступных пользователей, вам нужно изменить этот файл:

/etc/sysctl.conf

и добавьте или измените эти строки следующим образом:

# To ensure we can map all the possible NFS users
kernel.keys.root_maxkeys=65000
kernel.keys.root_maxbytes=1300000
kernel.keys.maxkeys=65000
kernel.keys.maxbytes=1300000

Ваша система может не требовать столько сопоставлений ключей user/id, поэтому при необходимости отрегулируйте. Это позволит всем ключам id-name оставаться сопоставленными при использовании монтирования NFS. Вот еще один связанный пост, показывающий текущие настройки ядра:

https://bugzilla.redhat.com/show_bug.cgi?id=876705#c20

для этих значений:

cat /proc/sys/kernel/keys/root_maxkeys
cat /proc/sys/kernel/keys/root_maxbytes
cat /proc/sys/kernel/keys/maxkeys
cat /proc/sys/kernel/keys/maxbytes

Скорее всего, maxbytes и root_maxbytes должны быть достаточно большими для хранения всех ключей:

https://www.kernel.org/doc/Documentation/security/keys.txt

Answer 3

Еще один контрольный список, предполагающий, что вы используете NFSv4 с Kerberos:

• kinit, затем посмотрите на klist. Вы должны увидеть тикет; если нет, сначала поищите ответы о том, как исправить аутентификацию Kerberos.
• запущен rpc.gssd? Возможно, вам захочется запустить службу; кроме того, в некоторых дистрибутивах она не запускается автоматически, если вы не упомянете монтирования NFS с krb5* в их параметрах в вашем /etc/fstab.
• запущено rpc.idmapd? (Опять же, обычно это должно запускаться клиентской службой nfs; ls /etc/init.d/это хорошая отправная точка.
• посмотрите на /etc/idmapd.conf. Соответствует ли часть «Домен» фактическому домену вашего сервера NFS? (... если нет ничего другого, вы можете попробовать использовать область Kerberos.) Я видел дистрибутивы, где это не было нужно, а в некоторых это было нужно; возможно, в некоторых из них есть более разумные значения по умолчанию для полного доменного имени.
• также добавьте GSS_principal_attr = GSSAuthNameв файл. Только домен может исправить некоторые проблемы с владением, но похоже, что это также необходимо для, например, каталогов.
• перезагрузите хотя бы rpc.idmapdодин раз, настроив конфигурацию. Перемонтирование не обязательно после настройки конфигурации, но оно не повредит.
• также! nfsidmap -c. По-видимому, есть кэш, который не очищается даже при перезапуске; это очистит его. (В противном случае вы можете продолжать думать, что исправление не работает, даже если оно работает.)