Сервер NFS с клиентом OS X и непревзойденным UID/GID

Question

Я настроил NFS-сервер на Arch Linux в моей локальной сети. Один из клиентов - это компьютер Mac OS X 10.6 с поддержкой NFS4.0Alpha. Идентификаторы пользователя / группы на машине OS X - 501/20 и соответствующего пользователя на маршрутизаторе 1001/1001. GID 20 уже занят на арочной машине.

Каков наилучший способ, без ручной синхронизации идентификаторов и сжатия всех идентификаторов, чтобы правильно выполнить сопоставление идентификаторов? Желательно, не касаясь клиента. Или я должен перейти на SAMBA? Есть ли в этом какие-либо преимущества? (В настоящее время даже при сжатии идентификатора NFS несколько нестабильна, что приводит к зависанию при копировании нескольких фрагментов больших данных одновременно ...)

Существует ли какое-либо современное руководство по правильной настройке этой системы NFS Server/Client для клиентов OS X?

---

Что касается Samba: я много читаю о том, что он не так хорошо работает по сравнению с NFS. В моей сети Wi-Fi скорость составляет 8-9 МБ / с (макс. 75Mbit / с). Это достаточно медленно, чтобы я не почувствовал разницу в производительности Samba? Хотя, возможно, его сложнее настроить, похоже, он предоставляет гораздо больше функций и лучше поддерживает OS X / Windows.

Answer 1

с поддержкой NFS4.0 Alpha

Может в этом причина нестабильности? :)

Каков наилучший способ, без ручной синхронизации идентификаторов и сжатия всех идентификаторов, чтобы правильно выполнить сопоставление идентификаторов? Желательно, не касаясь клиента.

RPC, используемый NFS, обычно поддерживает два механизма аутентификации: AUTH_UNIX (sec = sys, по идентификатору пользователя) и AUTH_GSS (sec = krb5/krb5i, по билету Kerberos).

Если используется AUTH_UNIX, в настоящее время невозможно перевести UID. Несмотря на то, что NFSv4 rpc.idmapd может переводить имена пользователей, отображаемые в списках файлов, это не влияет на идентификаторы UID, отправляемые в заголовках RPC AUTH_UNIX.

Вам придется синхронизировать UID клиента и сервера, или настроить Kerberos, или переключиться на другую файловую систему.

Что касается Samba: я много читаю о том, что он не так хорошо работает по сравнению с NFS.

Это в некоторой степени зависит от реализации клиента и сервера.

Я слышал слухи о том, что Samba может превзойти NFSv4, особенно если и клиент, и сервер поддерживают протокол SMBv2 (который имеет много улучшений по сравнению со старым SMBv1/CIFS). Вам может потребоваться установить max protocol в вашем файле smb.conf. Клиентское программное обеспечение также имеет большое значение - например, модуль Linux cifs.ko показал значительное увеличение производительности между ядрами 3.2 и 3.6 ... Как ни странно, smbclient пользовательского пространства может быть еще быстрее.

Помимо производительности, основным отличием от NFS является то, что SMB никогда не использует идентификаторы Unix для аутентификации - для этого требуется либо пароль для входа, либо Kerberos (снова). Это означает, что его может быть сложнее настроить как общесистемное монтирование - клиентам OS X, вероятно, потребуется подключиться к общему ресурсу с помощью графического интерфейса, пользователи BSD будут ограничены smbclient стиле FTP. Linux 3.3 поддерживает mount -o multiuser даже для входа в систему с паролем, но каждый пользователь должен войти в систему, используя cifscreds add прежде чем он сможет получить доступ к общему ресурсу.