Вопрос или проблема
На сервере Linux RHEL 5 (обновленном два месяца назад) монтируются два NAS с помощью NFS. В этих общих папках директории принадлежат двум разным пользователям, оба из которых существуют локально на сервере.
Один из них корректно отображается с помощью rpcidmapd, но вторая общая папка показывает nobody:nobody как владельца.
При увеличенной подробности, лог вывода для корректного монтирования (пользователь tomcat):
Jun 1 15:39:19 server_hostname rpc.idmapd[31250]: nfs4_name_to_uid: calling nsswitch->name_to_uid
Jun 1 15:39:19 server_hostname rpc.idmapd[31250]: nss_getpwnam: name '[email protected]' domain 'domain.com': resulting localname 'tomcat'
Jun 1 15:39:19 server_hostname rpc.idmapd[31250]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
Jun 1 15:39:19 server_hostname rpc.idmapd[31250]: nfs4_name_to_uid: final return value is 0
Jun 1 15:39:19 server_hostname rpc.idmapd[31250]: Client 0: (user) name "[email protected]" -> id "667"
Jun 1 15:39:19 server_hostname rpc.idmapd[31250]: nfs4_name_to_gid: calling nsswitch->name_to_gid
Jun 1 15:39:19 server_hostname rpc.idmapd[31250]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
Jun 1 15:39:19 server_hostname rpc.idmapd[31250]: nfs4_name_to_gid: final return value is 0
Jun 1 15:39:19 server_hostname rpc.idmapd[31250]: Client 0: (group) name "[email protected]" -> id "667"
А для пользователя, который не отображается корректно, мы получили код выхода -22 :
Jun 1 15:56:31 server_hostname rpc.idmapd[7128]: nfs4_name_to_uid: calling nsswitch->name_to_uid
Jun 1 15:56:31 server_hostname rpc.idmapd[7128]: nss_getpwnam: name '10701' domain 'domain.com': resulting localname '(null)'
Jun 1 15:56:31 server_hostname rpc.idmapd[7128]: nss_getpwnam: name '10701' does not map into domain 'domain.com'
Jun 1 15:56:31 server_hostname rpc.idmapd[7128]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22
Jun 1 15:56:31 server_hostname rpc.idmapd[7128]: nfs4_name_to_uid: final return value is -22
Jun 1 15:56:31 server_hostname rpc.idmapd[7128]: Client 0: (user) name "10701" -> id "99"
Jun 1 15:56:31 server_hostname rpc.idmapd[7128]: nfs4_name_to_gid: calling nsswitch->name_to_gid
Jun 1 15:56:31 server_hostname rpc.idmapd[7128]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22
Jun 1 15:56:31 server_hostname rpc.idmapd[7128]: nfs4_name_to_gid: final return value is -22
Jun 1 15:56:31 server_hostname rpc.idmapd[7128]: Client 0: (group) name "672" -> id "99"
Те же монтирования работают нормально на сервере RHEL 7.4.
/etc/idmapd.conf
одинаков на обоих серверах.
Оба пользователя и группы существуют локально, команда getent passwd отвечает нормально для обоих пользователей.
Имя пользователя длиннее 8 символов, пытались сократить его до 8, но безуспешно.
Думали о uid, который больше 10000, но не смогли найти документацию, говорящую о таких ограничениях.
Заканчиваюсь идеями, много гуглил, но не смог найти причину, почему это работает для одного пользователя, но не для другого.
NFSv4 имеет метод сопоставления имен пользователей к идентификаторам пользователей. Если вы хотите иметь одни и те же учетные данные на сервере и клиенте, вы можете, например, дать обеим системам одно и то же имя домена.
Если это не сработает на вашей платформе, ищите в документации информацию о том, как настроить nfsv4 домен.
Ответ или решение
Проблема: NFS-монтирование неправильно сопоставляет пользователя
В вашем случае, на сервере RHEL 5 при использовании NFS происходит несоответствие при монтировании общих ресурсов: один пользователь корректно сопоставляется (например, пользователь tomcat), а другой (в вашем примере это пользователь с именем ‘10701’) отображается как nobody:nobody. При этом стоит отметить, что аналогичные монтирования работают без проблем на сервере RHEL 7.4. Давайте проанализируем ваши логи и возможные причины этой проблемы.
Анализ логов
-
Корректное сопоставление для пользователя tomcat:
nfs4_name_to_uid: name '<email protected>' domain 'domain.com': resulting localname 'tomcat'
Здесь видно, что идентификатор пользователя и его группа успешно сопоставлены через nsswitch и отображаются корректно.
-
Некорректное сопоставление для пользователя ‘10701’:
nss_getpwnam: name '10701' domain 'domain.com': resulting localname '(null)' nss_getpwnam: name '10701' does not map into domain 'domain.com'
В данном случае видно, что для пользователя ‘10701’ процесс nsswitch не нашёл соответствующего сопоставления, в результате чего возвращается ошибка
-22
, указывающая на отсутствие маппинга.
Возможные причины и решения
-
Некорректные настройки домена NFSv4:
Убедитесь, что на всех системах (клиент и сервер) настроены одинаковые параметрыDomain
в файле/etc/idmapd.conf
. Доменное имя должно соответствовать на всех системах, чтобы избежать расхождений. Если на сервере настройки в порядке, а на клиенте нет — корректируйте их. -
Идентификаторы пользователей (UID):
Проверьте, что UID пользователя ‘10701’ на сервере соответствует тому же самым значениям на клиенте. Особенно важны UID пользователей выше 10000, так как иногда системы могут иметь определённые ограничения на их использование. Некоторые версии NFSv4 могут по-разному обрабатывать UID, превышающие 10000, особенно в зависимости от версии дистрибутива. -
Символы в имени пользователя:
Несмотря на то что имя пользователя больше 8 символов не должно вызывать проблем в большинстве случаев, некоторые системы могут некорректно обрабатывать более длинные имена; попробуйте префиксировать имя пользователя согласно требованиям системы или используйте имя менее 8 символов для тестирования. -
Проверка загрузки необходимых служб:
Убедитесь, что службаrpc.idmapd
запущена и работает на обеих системах, как на сервере, так и на клиенте. Если служба не работает, маппинг пользователей не будет осуществлён. -
Сравнение систем RHEL 5 и RHEL 7.4:
Обратите внимание на версии NFS и библиотеки, используемые на обоих серверах. Поскольку проблема не возникает на RHEL 7.4, возможно, необходимо обновить пакеты NFS или репозитории на RHEL 5 для обеспечения совместимости.
Заключение
Рекомендуется начать с проверки конфигурационных файлов на обеих системах, убедиться, что домены правильно заданы, а также сопоставление UID находится в соответствии. При возникновении дополнительных трудностей можно рассмотреть варианты логирования и отладки для более глубокого анализа проблем, или обратиться к документации по NFS для вашей версии системы. Если после применения предложений проблема останется, будет целесообразно рассмотреть возможность уровня обновления версии RHEL для обеспечения долгосрочной поддержки.