Я пытаюсь использовать монтирование NFSv4 в двух системах, которые не имеют общих UID / GID. Это для миграции системы, когда старая среда использовала любые доступные UID / GID, и теперь они конфликтуют в новой среде. Я дал всем пользователям новые неконфликтующие идентификаторы в новой среде.
Моя проблема - монтирование NFS. Я пытаюсь использовать NFSv4, поскольку он передает идентификаторы в виде строк, а не чисел (что должно помочь при сопоставлении). Я могу смонтировать файловую систему в старой среде, и когда я ls -l, Я вижу правильные имена с обеих сторон (значит, отображение работает).
Когда я пытаюсь коснуться файла как пользователь (пользователь, который существует в обеих системах с разными UID), мне отказывают в разрешении. Пользователь является членом соответствующей группы в обеих системах (группа имеет разные GID в обеих средах, но пользователь является правильным членом с обеих сторон).
Есть и другие варианты решения моей проблемы (использование NFSv3 и повторное сопоставление UID / GID), но я не хочу этого делать, если могу этого избежать.
Вот моя конфигурация и некоторые тесты, чтобы показать вам, что я вижу ...
Конфигурация сервера:
# chnfsdom
Current local domain: red.act.ed
# cat /etc/exports
/usr/sap/trans -vers=4,sec=sys,rw,root=172.29.4.56:172.29.4.55:172.29.4.65
# ls -ld /usr/sap/trans/data
drwxrwxr-x 2 d01adm sapsys 118784 Apr 23 08:25 /usr/sap/trans/data
# ls -nld /usr/sap/trans/data
drwxrwxr-x 2 300 300 118784 Apr 23 08:25 /usr/sap/trans/data
Конфигурация клиента:
# chnfsdom
Current local domain: red.act.ed
# mount | grep trans
devbox /usr/sap/trans /usr/sap/trans nfs4 Apr 23 09:01 vers=4
qabox:/ # ls -ld /usr/sap/trans/data
drwxrwxr-x 2 d01adm sapsys 118784 Apr 23 09:25 /usr/sap/trans/data
qabox:/ # ls -nld /usr/sap/trans/data
drwxrwxr-x 2 8 14 118784 Apr 23 09:25 /usr/sap/trans/data
Основываясь на этой информации, похоже, что перевод UID / GID работает правильно. Вот загвоздка (на клиентской коробке) ...
qabox:q01adm> pwd
/usr/sap/trans
qabox:q01adm> ls -ld .
drwxrwxr-x 14 d01adm sapsys 4096 Apr 23 09:56 .
qabox:q01adm> id
uid=12(q01adm) gid=14(sapsys) groups=0(system),7(security),4294967294(nobody),15(oper),16(dba)
qabox:q01adm> touch file
touch: 0652-046 Cannot create file.
Вот что я могу сделать с root на том же клиентском компьютере:
qabox:/usr/sap/trans # pwd
/usr/sap/trans
qabox:/usr/sap/trans # id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp),14(sapsys)
qabox:/usr/sap/trans # touch file
qabox:/usr/sap/trans # chown q01adm:sapsys file
qabox:/usr/sap/trans # ls -l file
-rw-r--r-- 1 q01adm sapsys 0 Apr 23 09:59 file
qabox:/usr/sap/trans # ls -nl file
-rw-r--r-- 1 12 14 0 Apr 23 09:59 file
А на серверном ящике я вижу это:
# ls -l /usr/sap/trans/file
-rw-r--r-- 1 q01adm sapsys 0 Apr 23 08:59 /usr/sap/trans/file
# ls -nl /usr/sap/trans/file
-rw-r--r-- 1 302 300 0 Apr 23 08:59 /usr/sap/trans/file
Итак, из всего, что я вижу ... перевод UID / GID работает правильно, я просто не могу писать файлы на клиенте как пользователь без полномочий root.
Насколько мне известно, сопоставление идентификаторов NFSv4 применяется только к результатам stat () и другой информации, отправляемой через саму NFS, то есть к владельцам файлов, отправленных chown, возвращенный ls или stat, и т.д.
Однако аутентификация выполняется на более низком уровне - SunRPC - который по-прежнему использует ваш числовой UID в протоколе AUTH_UNIX по умолчанию. Так что, если вы являетесь пользователем №12 локально, это также получит сервер.
Чтобы этого избежать, вам понадобится механизм аутентификации, поддерживающий имена пользователей; Kerberos (AUTH_GSS) может быть здесь единственным выбором.