nfs монтирует общий ресурс rw 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, поэтому сейчас я немного растерялся. TIA!
ОК. Догадаться. Во-первых, я использую версию 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 соответственно.
на стороне клиента: create user:
# 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'. Если установлено значение true, это свойство распространяется на существующие подпапки. Обратите внимание, что анонимный доступ для чтения / записи не наследуется - анонимный доступ к будущим подпапкам не будет разрешен до тех пор, пока не будет запрошен явным образом. Имя анонимного пользователя - 'nfs' ».
Мой shared_user в конечном итоге стал «nfs», что по-прежнему не удалось (см. OP). Я решил, потому что считал это маловероятным, сделать мой UID на стороне клиента таким же, как у UID для nfs на устройстве. Мне пришлось войти в систему, запустить оболочку bash, а затем выполнить команду id , чтобы получить UID, который в моем случае был 60001.
На клиенте я изменил ] nfs пользователь, чтобы сопоставить UID на устройстве. Очевидно, устройству действительно требуется, чтобы UID / GID соответствовал его собственному, чтобы это работало. Я полагал, что сервер NFS проигнорирует это. Очевидно, в этом и заключалась суть проблемы.
Теперь устройство использует nfs: nobody для user: group. никто на стороне клиента (Linux) - это другой UID, и изменение UID никого не потребует больше усилий, и я не знаю, на что я мог бы непреднамеренно повлиять, изменив этот groupid, поэтому я не трогал. Пользователь nfs на клиентской машине не существовал до того, как я начал копаться, поэтому не было риска что-либо сломать. На стороне клиента есть nfsnobody . Я не тестировал его использование, и я почти уверен, что это не сработало бы, поскольку документация конкретно касается идентификатора пользователя.
Я также должен указать здесь, что устройство было специально настроено на использование sysauth для аутентификации. Использование auth = none не было вариантом, поскольку NFSv3, похоже, не нравится. :)
вот и все.