Nfs клиент для windows 10 скачать

Администрируя серверы на базе ОС 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-FS01mntvdo-vd1ovirt-iso-domain I:

где:

• «-o anon» — подключаться с правами анонимного пользователя;
• «KOM-FS01» — имя NFS-сервера;
• «mntvdo-vd1ovirt-iso-domain» — локальный путь к каталогу на NFS-сервере;
• «I» — буква диска Windows

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

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

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

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

• AnonymousUid
• AnonymousGid

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

HKEY_LOCAL_MACHINESOFTWAREMicrosoftClientForNFSCurrentVersionDefault

В значениях созданных параметров можно записать нужные 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. Будем использовать это в работе.

В Unix-подобных операционных системах подключить каталога NFS (Network File System) довольно просто, однако если вам понадобится использовать NFS шару в Windows, придется выполнить ряд дополнительных действий. В этой статье мы покажем, как в Windows 10 подключить NFS каталог, который находинся на UNIX системе. Все описанные инструкции будут работать в Windows 10 Pro (версия 10.0.14393 и выше).

Содержание:

• Установка клиента NFS (службы для NFS)
• Как разрешить запись в NFS каталог анонимному пользователю
• Как подключить NFS каталог в Windows 10

Установка клиента NFS (службы для NFS)

В первую очередь в Windows 10 нужно установить клиент NFS. Для установки необходимо выполнить следующие шаги:

1. Откройте раздел «Programs and Features».
   
2. Щелкните по пункту «Turn Windows features on or off».
   
3. В появившемся списке в разделе Services for NFS включите NFS клиента (Client for NFS), а затем нажмите «ОК».
   
4. После установки нажмите кнопку «Close» и вернитесь на рабочий стол.

Как разрешить запись в NFS каталог анонимному пользователю

По умолчанию при подключении NFS каталога с UNIX системы, анонимному пользователю (anonymous) предоставляются права только на чтение. Чтобы предоставить анонимным пользователям право записи, необходимо изменить значения UID и GID, которые используются для монтирования NFS каталога в Windows. Пример стандартных настроек представлен на рисунке ниже.

Чтобы изменить значение полей UID и GID, нам потребуется внести изменения в реестр Windows.

1. Откройте редактор реестра regedit.
2. Перейдите в ветку реестра — HKEY_LOCAL_MACHINESOFTWAREMicrosoftClientForNFSCurrentVersionDefault.
3. В каталоге «Default» создайте новый параметр типа DWORD (32бит) с именем AnonymousUid и назначьте UID, назначенный на каталог в UNIX, к которому открыт доступ через NFS.
4. В ветке Default создайте ещё один параметр DWORD (32-бит) с именем AnonymousGid и назначьте GID, назначенный данному каталогу в UNIX.

   

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

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

Результат работы команды mount теперь должен выглядеть следующим образом:

Local Remote Properties
-------------------------------------------------------------------------------
Z: \10.1.1.211mntvms UID=0, GID=0
rsize=1078756, wsize=1078756
mount=soft, timeout=1.6
retry=1, locking=yes
fileaccess=755, lang=ANSI
casesensitive=no
sec=sys

Обратите внимание на значение полей UID и GID, которое равно 0. UID=0, GID=0 — означает, что общий ресурс монтируется под пользователем root.

Как подключить NFS каталог в Windows 10

Смонтировать NFS каталог в Windows 10 можно с помощью команды mount. Например, смонтируем NFS каталог и назначим ему букву диска Z:. Предположим, что ваше NAS устройство находится в той же сети, что и ваш компьютер с установленной операционной системы Windows, а IP-адрес устройства — 10.1.1.211. С помощью следующей команды можно смонтировать общий ресурс NFS в /mnt/vms.

Mount –o anon \10.1.1.211mntvms Z:

Z: is now successfully connected to \10.1.1.211mntvms
The command completed successfully.

Теперь общий ресурс создан, и мы можем получить доступ к данным. В нашем примере сетевой ресурс (диск) обозначается буквой «Z».

На этом настройка NFS завершена и вы сможете сохранять данные на свое NAS устройство через смонтированный NFS каталог. Обратите внимание, что при в первый раз открытие этого каталога выполняется довольно долго.

15 Aug 2021 — tsp
Last update 16 Aug 2021
5 mins

TL;DR: Install NFS client feature (either from features menu or via DISM in
an elevated command prompt), use the mount and umount command to mount
and unmount via NFS in case anonymous user mapping is used.

• Introduction
• Installing the NFS client
• Mounting
  • Anonymous
  • Unauthenticated, with user mapping, no AD, no Kerberos
  • With Kerberos

Introduction

Sometimes one just encounters Windows machines even if one tries to avoid this
as good as possible. Then sometimes one wants to allow them to access network
shares on a local network — Windows users are usually using the SMB protocol using
WINS to locate the machines. It’s entirely possible to support these protocols
using samba (and even possible running the LDAP / Kerberos suite that’s
called active directory by Microsoft even though that’s a little bit of work).
On the other hand it’s most of the time simpler to support NFS on the clients
instead of rolling out a second file sharing protocol in parallel. Fortunately
Microsoft now supports NFS even on more consumer side versions (professional edition)
of Windows and not only on the enterprise versions as before — though up to my
knowledge there is no way to mount NFS shares on home editions (but since they also
do not support different users for SMB, etc. they’re pretty much useless as soon
as one runs a network anyways). This blog post gives a short summary on how to
mount NFS shares on Windows machines (basically a note to myself how to do this
stuff).

Installing the NFS client

First of the NFS client is only supported since Windows 10 professional in the
professional versions, older versions (though they should not be in operating networked
anywhere anyways) one would require the enterprise versions.

One can either just use both Client for NFS and Administrative Tools
from the Services for NFS in Windows features dialog to install the NFS
client of use DISM from an elevated command prompt:

dism /online /Enable-Feature /FeatureName:ServicesForNFS-ClientOnly
dism /online /Enable-Feature /FeatureName:ClientForNFS-infrastructure
dism /online /Enable-Feature /FeatureName:NFS-administration

Mounting

Anonymous

If one has exported a share with a typical anonymous mapall mount (i.e. one
that has a -mapall=username value set in the /etc/exports on the server)
one can simply mount from a command prompt using

mount -o anon \serverpathtodirectory DRIVE:

In case one wants to mount

• The share /nfs/testdata
• On nas.example.com
• Onto drive x on the windows machine

this would be

mount -o anon \nas.example.comnfstestdata x:

One can control the UID and GID that Windows is using for anonymous mounts using
the registry keys HKEY_LOCAL_MACHINESOFTWAREMicrosoftClientForNFSCurrentVersionDefaultAnonymousUID
and HKEY_LOCAL_MACHINESOFTWAREMicrosoftClientForNFSCurrentVersionDefaultAnonymousGID (both
are DWORD keys and accept the numeric user id and group id). Note that changing
these settings only takes effect after a reboot of the machine or a restart of
the NFS service.

In case one wants to use NFS in the old 90’th way without authentication (privileged
ports have been considered trusted since the client has been considered trusted
and Kerberos has not been a thing back then) one has to create the user and group
mappings Windows is using for it’s mountpoints. This is done using a passwd
and groups file at C:windowssystem32driversetcpasswd
and C:windowssystem32driversetcgroup

The typical format of lines inside these files is for passwd:

[USERNAME]:x:[UID]:[GID]:[GECOS],,,:c:users[USERNAME]

and for group:

[GROUPNAME]:x:[GID]:[UID]

For example in case one wants to identify the user exampleuser with the
Unix UID 1234 and the GID 567 the entries might look like the following:

exampleuser:x:1234:567:Just an example user,,,:c:usersexampleuser

and

Please note that the parser is rather picky:

• No empty lines at the end of the file or somewhere in between
• No extra blanks at the end of lines
• No duplicated users
• No non existing users

With Kerberos

This is by far the best idea. I won’t cover the setup of Kerberos in one’s network
in this blog post since this is a little bit more complex (it requires correctly
configured DNS and reverse DNS, a running KDC, etc.) but it’s totally worth it.
In case one has not configured Kerberos or user mapping one just has to perform
the standard setup sequence for Kerberos on the Windows client:

ksetup /setdomain EXAMPLE.COM
ksetup /setmachpassword <your kerberos password>
ksetup /addrealmflags EXAMPLE.COM sendaddress delegate
ksetup /mapuser * *

The last step maps all users from the network by name to local users. One can
few the current state of Kerberos:

To check if a user is capable of getting a Kerberos ticket one just as usual
uses klist to list current tickets.

Mounting an NFS share works similar to anonymous mounting — just specifying
Kerberos as security layer:

mount -o sec=krb5 server:/path/to/directory DRIVE:

Again using the same example:

• The share /nfs/testdata
• On nas.example.com
• Onto drive x on the windows machine

mount -o sec=krb5 nas.example.com:/nfs/testdata x:

This article is tagged:

• System administration
• Windows
• Network