Использование клиента NFS в Windows 10 редакции Professional

Администрируя серверы на базе ОС Linux в среде, где в качестве основной клиентской ОС используется Windows, время от времени приходится сталкиваться с необходимостью что-либо скопировать с клиентской Windows на Linux-систему или наоборот, с Linux-системы на Windows. Чаще всего для этого используются возможности протоколов SSH/SCP с помощью таких инструментов, как например, утилита pscp.exe. Но когда приходится сталкиваться с файловыми Linux-серверами, позволяющими использовать возможности протокола NFS, мы можем задаться вопросами типа "может ли клиентская ОС Windows выступать в качестве NFS-клиента?", "есть ли в клиентской ОС Windows какая-то встроенная реализация клиента NFS?". Именно такие вопросы у меня возникли в период времени, который совпал с периодом, когда мы перебирались с Windows 8.1 на первый релиз Windows 10. Информация, которую в тот момент удалось найти по этому вопросу, заключалась в том, что функциональность NFS-клиента имеют только "старшие" редакции клиентских ОС Windows, такие как Windows 7 Ultimate/Enterprise, Windows 8/8.1 Enterprise и Windows 10 Enterprise. Однако в нашем случае использовалась ОС Windows 10 редакции Professional, поэтому пришлось отбросить эти мысли.

Недавно, читая обсуждения на форумах TechNet, я столкнулся с информацией о том, что с какого-то момента времени в ОС Windows 10 редакции Professional появилась возможность использовать функционал NFS-клиента. По информации из некоторых источников такая возможность появилась в Windows 10 версии 1607 (10.0.14393 / Anniversary Update).

Решив проверить эту информацию на имеющейся у меня под руками Windows 10 1803 (10.0.17134 / April 2018 Update) редакции Professional, я обнаружил, что теперь у нас действительно имеется возможность использования этого функционала.

Чтобы включить NFS-клиента, можем воспользоваться оснасткой управления программами и компонентами appwiz.cpl. Здесь в перечне "компонентов Windows" можно найти доступные к включению "Службы для NFS".

После завершения установки компонент в Панели управления в разделе "Администрирование" появится оснастка "Службы для NFS" (nfsmgmt.msc), в которой мы сможем управлять некоторым параметрами работы NFS-клиента.

Предполагаем, что на стороне NFS сервера уже настроены разрешения для доступа с клиентской системы, например, явно разрешён доступ по IP адресу клиента. Простейший пример установки и настройки NFS-сервера на стороне CentOS Linux можно найти в статье Вики "Установка и настройка сервера и клиента NFS в CentOS Linux 7.2".

После настройки прав доступа на стороне NFS-сервера переходим на Windows 10 и выполняем подключение сетевого каталога с помощью утилиты "mount". Простейший пример анонимного подключения к сетевому каталогу выглядит так:

mount -o anon \\KOM-FS01\mnt\vdo-vd1\ovirt-iso-domain I:

где:

• "-o anon" - подключаться с правами анонимного пользователя;
• "KOM-FS01" - имя NFS-сервера;
• "mnt\vdo-vd1\ovirt-iso-domain" - локальный путь к каталогу на NFS-сервере;
• "I" - буква диска Windows

Другие доступные параметры и ключи утилиты, можно посмотреть командой "mount /?". Например, при подключении мы явно можем указать имя пользователь и пароль на NFS-сервере.

При открытии свойств каталогов и файлов в подключённом NFS-каталоге мы увидим специальную вкладку "Атрибуты NFS" с соответствующими атрибутами, в том числе и информацию о текущих разрешениях на каталог/файл, которыми, в случае достаточных прав, мы можем управлять.

При повторном выполнении команды mount без указания параметров, мы получим сведения о текущий подключениях NFS-клиента и свойствах этих подключений:

Здесь мы сможем увидеть то, с какими UID и GUID, выполнено подключение. Для анонимных подключений это по умолчанию -2/-2. Если по какой-то причине у нас возникнет необходимость изменить эти идентификаторы для всех анонимных клиентских подключений, то мы можем добавить пару отсутствующих по умолчанию параметров реестра типа DWORD (32-бита):

• AnonymousUid
• AnonymousGid

в ключ реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default

В значениях созданных параметров можно записать нужные UID и GUID, которые будут использоваться при всех анонимных подключениях. На скриншоте ниже используется пример со значениями 1000:1000 (десятичное).

Если мы хотим, чтобы все анонимные подключения использовали root-овые идентификаторы, то в соответствующих параметрах реестра нужно указать AnonymousUid = 0 и AnonymousGid = 0. Указание root-овых идентификаторов может быть полезно в случае, если, например, нам требуется не только чтение, но запись в подключенном NFS-каталоге, а удалённый NFS-сервер разрешает запись только root-пользователю и/или членам группы root.

Для вступления изменений в силу потребуется выполнить остановку и повторный запуск службы клиента NFS из ранее упомянутой оснастки "Службы для NFS" (nfsmgmt.msc).

Либо, если перезапуск компьютера не составляет проблемы, то для вступления изменений в силу можно выполнить и перезагрузку клиентского компьютера.

Здесь хочу сделать маленькое отступление относительно перезапуска службы клиента NFS и поделиться своими наблюдениями.

Мои попытки перезапускать системную службу "Клиент для NFS" (NfsClnt) через стандартные механизмы, такие как оснастку управления службами services.msc или утилиту "net", показали, что это по какой-то причине приводит к невозможности запуска службы после её остановки. Поэтому для перезапуска NFS-клиента лучше использовать именно "родную" оснастку. Хотя, опять же, замечено, что многократные остановки/запуски службы в оснастке "Службы для NFS" также могут привести к неадекватной работе NFS-клиента. В результате чего, например, утилита "mount" может перестать подключать NFS-каталоги, выдавая ошибку сети:

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

После того, как нужные нам изменения внесены в реестр и служба клиента NFS успешно перезапущена, снова попытаемся подключить NFS-каталог и посмотрим командой "mount" сведения о подключениях.

Как видим, теперь в качестве идентификаторов безопасности выступают именно те, что были ранее нами указаны в реестре.

Отключение подключенных по протоколу NFS сетевых ресурсов выполняется также просто, как и подключение, только с помощью другой утилиты – "umount"

В общем это хорошо, что теперь у пользователей ОС Windows 10 редакции Professional есть штатная возможность работать с сетевыми файловыми ресурсами по протоколу NFS. Будем использовать это в работе.