☰

NFSv4 с idmap

tag-icon • tag-icon nfs
NFSv4 с idmap

На сервере NFS появляются следующие ошибки. Не могли бы вы подсказать, как их исправить?

Подробности:

Система: CentOS версии 6.4, NFS: nfs-utils-1.2.3-36

# cat /etc/idmapd.conf

[General]
Domain = domain.com

[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

[Translation]
Method = nsswitch

Sep  3 08:25:28 snode1 rpc.idmapd[1382]: nss_getpwnam: name '0' does not map into domain 'domain.com'
Sep  3 08:25:29 snode1 rpc.idmapd[1382]: nss_getpwnam: name '500' does not map into domain 'domain.com'

EDIT: 03 сен 2013 10:41

Обратите внимание, что я использую NFSv4, и эти ошибки появляются только на сервере NFS (не на клиентах NFS).

Сервер:

# cat /etc/sysconfig/nfs

MOUNTD_NFS_V2="no"
MOUNTD_NFS_V3="no"
...
RPCNFSDARGS="-N 2 -N 3"

Клиенты:

# cat /etc/fstab

server:/     /data  nfs4    defaults,hard,intr,timeo=15,_netdev,noatime,nodiratime,nosuid    0 0

Редактировать: Ср Июн 11 14:52:50 BST 2014

# getent passwd "0" | cut -d: -f1
root
# getent passwd "500" | cut -d: -f1
user1

-

# grep "^passwd" /etc/nsswitch.conf 
passwd:     files

решение1

Я собираюсь сделать небольшое предположение. Если вы разрешаете UID '0' или '500' на вашем NFS-сервере, что вы получаете? Это случайно не локальные учетные записи?

Причина, по которой я это предполагаю, заключается в том, что NFSv4 по своей конструкции ссылается на имена учетных записей в пределах домена и пытается избежать «локальной аутентификации» из предыдущих версий NFS. Поэтому он использует idmapd, который транслирует имена учетных записей — передаваемые в пакетах NFS — для трансляции имени пользователя в UID/GID.

Как вы правильно определили, похоже, именно это здесь и сломалось. Поэтому мой вопрос: какой домен аутентификации вы используете и когда вы запрашиваете его, получаете ли вы ответ для UID 0 и 500?

Я видел подобное, когда, например, сервер смотрел на неправильную ветку каталога LDAP (ну, Active Directory) по сравнению с клиентом. Поскольку он не мог разрешить связь UID/имя пользователя, он сломался и в результате перевел этих пользователей в 'nobody'.

У вас настроено разрешение через nsswitch — что говорит nsswitch для «passwd»? (В первую очередь на сервере, поскольку именно там, по-видимому, и существует проблема).

Редактировать: Хорошо, так что согласно вашему 'passwd' у вас есть 'files' в качестве вашей локальной базы данных - например /etc/passwd. Это означает, что вы сопоставляете UID/GID через локальные учетные записи. Выне следуетникогда не используйте UID с NFSv4 — это должны быть имена пользователей.

Однако, немного погуглив, я нашел: http://www.spinics.net/lists/linux-nfs/msg38598.html

Поэтому следующий вопрос - используете ли вы аутентификацию 'sys'? Я предполагаю на основе вашего fstab, что вы используете, и в этот момент - это, по-видимому, ожидаемое поведение - ваши клиенты используют 'sys' и, следовательно, передают UID/GID. idmapd жалуется, потому что они не являются допустимыми пользователями (они являются UID).

Если на вашем клиенте вы «касаетесь» файла как UID 500 или 0, как это будет выглядеть на клиенте и сервере (ls -l для получения имени пользователя, ls -ln для получения uid)? Если это работает правильно, то это, по-видимому, артефакт обратной совместимости между NFSv3 Auth sys и NFSv4, и сообщения безвредны.

Вы можете рассмотреть возможность обновления до аутентификации Kerberos или чего-то подобного, но по опыту это нетривиальное упражнение. (Хотя и с некоторыми довольно удобными преимуществами). Это сообщение (след), на которое я ссылался, подразумевает, что это сообщение об ошибке перестает появляться в более поздних версиях ядра.

решение2

Похоже, вы используете NFSv3, который отправляет по сети только числовые идентификаторы пользователей и групп.

Чтобы idmapd заработал, вам нужно будет использовать NFSv4, который отправляет идентификаторы user@domain, понятные idmapper и сопоставленные с локальными учетными записями (поэтому вам не нужны одинаковые uid/gid на сервере и клиенте).

Попробуйте смонтировать этот ресурс с опцией -t:

mount -t nfs4 server:/path /mountpoint

решение3

пожалуйста, проверьте, получены ли следующие решения изфорум gentooпомочь тебе:

 1. On the NFS server, /etc/hostname did not contain the FQDN, just the local hostname.
 2. This particular client had an unconfigured /etc/idmapd.conf. It had Domain = localdomain instead of Domain = FQDN-minus-hostname.

Для вашей установки это выглядит как второй вариант.

Поиск в Google точного сообщения об ошибке «nss_getpwnam: имя '0' не соответствует домену» даст вам множество результатов, которые также могут вам помочь (просто указал самые многообещающие)

Связанный контент