NFS монтирует общий ресурс Nexenta для всех пользователей на Linux-клиенте - не удалось
Ситуация:
Мы используем устройство Nexenta для обслуживания файлов NFS (nfs v3). Мы разделяем путь для анонимного доступа для чтения / записи.
У нас есть хост Linux, к которому мы хотели бы подключить этот экспортированный общий ресурс для чтения / записи, а также разрешить анонимный доступ для чтения / записи к этому подключенному общему ресурсу на этом клиентском компьютере. К сожалению, в конечном итоге root может писать в общий ресурс, а непривилегированные пользователи - нет.
Используя следующие методы для монтирования общего ресурса:
# mount -t nfs -o rw 10:10:xx:xx:/path/to/share /mnt/mounted_path
# mount -t nfs -o rw,users 10:10:xx:xx:/path/to/share /mnt/mounted_path
# mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -o rw
У нас есть конкретный пользователь, которого мы намерены использовать для анонимного использования на общем ресурсе. Поэтому я попытался смонтировать том под этим пользователем:
# su - shared_user
$ sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw
mount.nfs: an incorrect mount option was specified
Пошел и немного почитал: http://nfs.sourceforge.net/nfs-howto/ar01s06.html.
Решил дать следующую попытку, которая выдает исходящие ошибки при попытке монтирования:
# mount -t nfs -orw,no_root_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path
mount.nfs: an incorrect mount option was specified
# mount -t nfs -orw,nroot_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path # for grins and giggles.
mount.nfs: an incorrect mount option was specified
$ sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw,no_root_squash
mount.nfs: an incorrect mount option was specified
Я просто SOL или мне здесь чего-то не хватает? Это Святой Грааль, который я пытаюсь найти? Я никогда интенсивно не использовал NFS, поэтому сейчас я немного растерялся. ТИА!
1 ответ
ХОРОШО. Догадаться. Во-первых, я использую версию Nexenta 3.1.3.5. Nexenta - это устройство на основе OpenSolaris, которое реализует блочное хранилище через CIFS, NFS, Rsync, WebDAV и FTP. В нашем случае мы используем его исключительно для NFS (v3 по умолчанию. V4 недоступен для этой версии).
Итак, TL; Dr; на стороне Nexenta:
Войдите в Nexenta как root:
$ ssh root@xx.xx.xx.xx
Password:
Last login: Wed Aug 24 11:17:33 2016 from xx.xx.xx.xx
nmc@nex01:/$ option expert_mode = 1
nmc@nex01:/$ !bash
You are about to enter the Unix ("raw") shell and execute low-level Unix command(s). Warning: using low-level Unix commands is not recommended! Execute? Yes
root@nex01:/volumes#
root@nex01:/volumes# grep nfs /etc/passwd
nfs:x:60001:60001:NFS Anonymous Access User:/:/bin/sh
Обратите внимание на цифры после первого x:#####:##### - это соответственно uid и gid.
на стороне клиента: создать пользователя:
# groupadd nfs -g 60001 && useradd nfs -g 60001 ## untested. I did it the long way through natural process of elimination, so be careful here.
Все хорошо сейчас.
Смонтируйте том и убедитесь, что ваш вновь созданный пользователь nfs может выполнять запись на том NFS.
Длинная версия:
Насколько я могу судить, сторона NFS была настроена правильно. Документация была полезной, но в некотором смысле это только деление хлебных крошек.
"Разрешить анонимный доступ к этому общему ресурсу. Для общего каталога верхнего уровня будет предоставлен доступ на чтение и запись для анонимного пользователя" nfs ". Если для рекурсивного режима общего доступа установлено значение" истина ", это свойство распространяется на существующие подпапки. Обратите внимание, что анонимное чтение Доступ / write не наследуется - анонимный доступ к будущим подпапкам не будет разрешен, пока не будет запрошен явный запрос. Имя анонимного пользователя - "nfs"."
мой shared_user в конце концов стал "NFS", который все еще не удалось (см. OP). Я решил, потому что я думал, что это длинный путь, чтобы мой UID на стороне клиента совпадал с UID для 'nfs' на устройстве. Я должен был войти в устройство, запустить оболочку Bash, а затем запустить id Команда для получения UID, который в моем случае был 60001.
На клиенте я изменил nfs пользователь, чтобы соответствовать UID на устройстве. Очевидно, что для работы устройства требуется UID/GID, соответствующий его собственному. Я полагал, что сервер NFS проигнорирует это. Это было очевидно суть проблемы.
Теперь устройство использует nfs:nobody для пользователя: группа. nobody на стороне клиента (Linux) другой UID, и изменение UID ни для кого не будет более сложным, и я не знаю, на что я мог бы случайно повлиять, изменив этот groupid, поэтому я не трогал его. nfs Пользователь на клиентском компьютере не существовал до того, как я начал копаться, поэтому не было никакого риска что-либо сломать. Есть nfsnobody на стороне клиента. Я не тестировал его использование, и я почти уверен, что это не сработало бы, так как документация конкретно касается идентификатора пользователя.
Я также должен заявить, что устройство специально настроено на использование sysauth для аутентификации. Использовать auth=none было невозможно, поскольку NFSv3, похоже, не нравится.:)
это все.