@alpha6

Как подменить UID владельца файлов при монтировании NFS шары?

Доброго времени суток.
Столкнулся тут со следующей проблемой — имеется хост машина на Mac OS 10.8, в ней запущена виртуалка с Ubuntu 12.04. Сеть настроена, все прекрасно работает. Пытаюсь настроить общую папку при помощи NFS.
На хосте настраиваю шару:
/Volumes/share1 -maproot=root:wheel -network 192.168.56.0 -mask 255.255.255.0

на клиенте подключаю шару:
192.168.56.1:/Volumes/share1 /srv/nfs nfs defaults 0 0

На клиенте все работает, но только от рута, т.к. uid пользователя которому принадлежит папка на хост-машине не совпадает с uid пользователя клиента. Менять владельца папки на хост машине не вариант, т.к. с нее тоже нужен доступ к файлам не от рута. Поменять UID пользователя клиента конечно вариант, но наверняка есть какой-то способ решения проблемы более штатными методами?
Гугление решений этой проблемы и чтение манов вчера к успеху не привело :( Опций как транслировать uid пользователя в указанный или примаунтить шару с нужным uid я не нашел. Точнее не нашел работоспособных.
Вариант:
192.168.56.1:/Volumes/share1 /srv/nfs nfs -o uid=1000 0 0
Ругается на ошибку синтаксиса или неправильное название шары (смотря в каком виде это записать)
  • Вопрос задан
  • 15677 просмотров
Пригласить эксперта
Ответы на вопрос 2
jcmvbkbc
@jcmvbkbc
"I'm here to consult you" © Dogbert
Вообще линуксовый NFS-сервер управляется файликом /etc/exports, в котором можно указать опции из man 5 exports:
 User ID Mapping
       nfsd bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she
       would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable.

       Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anony‐
       mous or nobody uid. This mode of operation (called `root squashing') is the default, and can be turned off with no_root_squash.

       By  default,  exportfs  chooses  a uid and gid of 65534 for squashed access. These values can also be overridden by the anonuid and anongid options.  Finally, you can map all user requests to the anonymous uid by
       specifying the all_squash option.

       Here's the complete list of mapping options:

       root_squash
              Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff.

       no_root_squash
              Turn off root squashing. This option is mainly useful for diskless clients.

       all_squash
              Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. The opposite option is no_all_squash, which is the default setting.

       anonuid and anongid
              These options explicitly set the uid and gid of the anonymous account.  This option is primarily useful for PC/NFS clients, where you might want all requests appear to be from one user. As an example, con‐
              sider the export entry for /home/joe in the example section below, which maps all requests to uid 150 (which is supposedly that of user joe).

Т.е. варианты такие: все uid/gid с клиента используются как есть, либо 0/0 мэппится во что укажете, либо всё мэппится во что укажете.
Ответ написан
merlin-vrn
@merlin-vrn
Сервер поддерживает NFSv4? Попробуйте запустить в таком режиме, если да. В NFSv4 по сети uid и gid вообще не передаются, передаются имена, которые idmapом мапятся в uid/gid на конечных точках.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы