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