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-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. Будем использовать это в работе.

Сетевая файловая система NFS является родным для мира Linux способом организации общего доступа к файлам по сети и ее взаимоотношения с Windows долгое время оставались напряженными. Однако последнее время ситуация начала меняться и Windows перешел от конфронтации к сотрудничеству с открытым ПО. Начиная с Windows 10 1607 (14393) в системе появился штатный NFS-клиент, который позволяет прозрачно подключать и использовать NFS-ресурсы. В данной статье мы расскажем, как его установить и использовать, а также разберем некоторые особенности эксплуатации.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Для установки NFS-клиента откройте оснастку Программы и компоненты и перейдите по ссылке Включение или отключение компонентов Windows, найдите там раздел Службы для NFS и включите его содержимое.

Также можно быстро выполнить установку при помощи PowerShell, для выполнения команды нужно запустить терминал с повышенными правами:

Enable-WindowsOptionalFeature -FeatureName ServicesForNFS-ClientOnly, ClientForNFS-Infrastructure -Online -NoRestart

Графических инструментов для подключения NFS-ресурсов нет, поэтому снова воспользуемся терминалом, только теперь запустим его без повышения прав:

mount -o anon \\192.168.233.184\mnt\nfs\doc Z:

Команда mount поддерживает ряд опций, которые указываются после ключа -o, в данном случае опция одна — anon, что означает подключение анонимным пользователем. Затем указываем сетевой путь к экспортируемому ресурсу, обратите внимание, что NFS-клиент для Windows поддерживает только NFS v3 и поэтому путь нужно указывать не от корня NFS, а от корня файловой системы. И наконец буква диска куда будет примонтирован ресурс. Адрес NFS-сервера в нашем случае 192.168.233.184.

Если нигде не было допущено ошибок, то в проводнике появится новый сетевой диск с указанной буквой.

Для отключение используйте команду:

umount Z:

У команды mount есть один существенный недостаток, сетевые диски, подключенные таким образом, не восстанавливаются при загрузке системы. Можно, конечно, пойти наиболее простым путем и добавить в автозагрузку пакетный файл с нужными командами, но лучше снова позвать на помощь PowerShell. Данную команду также нужно выполнять без повышения прав:

New-PSdrive -PSProvider FileSystem -Name Z -Root \\192.168.233.184\mnt\nfs\doc -Persist

Обратите внимание, что букву диска для монтирования указываем без двоеточия, а опция -Persist предписывает подключить ресурс на постоянной основе.

Для отключения ресурса воспользуйтесь командой:

Remove-PSdrive -Name Z

Для просмотра всех смонтированных NFS-ресурсов, неважно как они были подключены, используйте команду:

mount

Как можем увидеть, при анонимном подключении Windows использует UID/GID = -2, если мы используем all_squash со стороны NFS-сервера, то это не имеет особого значения, в иных случаях нам может потребоваться указать иные идентификаторы. Это можно сделать через системный реестр, откройте ветвь:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default

И добавьте туда два параметра DWORD (32бит) с именами AnonymousUid и AnonymousGid и укажите в них нужные идентификаторы в десятичном виде. После чего перезагрузите компьютер.

А теперь о проблемах. Для их понимания достаточно посмотреть на следующий скриншот:

Начнем с самого безобидного, регистра в именах файлов. Как мы помним — Linux система чувствительная к регистру, поэтому там TEST.txt и test.txt разные файлы. И если вы будете работать с ними в пределах NFS-ресурса, то проблем не возникнет, вы можете даже открыть оба файла одновременно, внести изменения и сохранить. Все это возможно потому, что NFS — это не протокол удаленного доступа, а именно сетевая файловая система.

Проблемы начнутся, если вы захотите скопировать их в свою систему. Неопытный пользователь вполне может допустить ошибку и перезаписать важный локальный файл.

А вот следующая проблема куда серьезней и не имеет приемлемого решения на сегодняшний день. Современные Linux системы давно работают с UTF-8, в то время как Windows продолжает использовать региональные кодовые страницы, например, CP-1251 для русского языка. Это приводит к тому, что имена файлов, набранные кириллицей (или любыми иными национальными символами) отображаются «крякозябликами». Сами файлы при этом доступны и могут быть отредактированы.

Если же мы со стороны Windows поместим на NFS-ресурс файл с кириллицей в имени, то со стороны Linux мы увидим веселые ромбики.

В качестве решения можно найти совет включить поддержку UTF-8 в Windows, которая пока находится в состоянии бета. Эта возможность доступа в языковых настройках панели управления.

Но это решение из разряда «одно лечим — другое калечим» и покалечено будет гораздо больше, чем вылечено. Дело в том, что достаточно большое количество вполне современных программ ничего не знают об UTF-8 и не умеют с ним работать, в итоге веселые ромбики начнут попадаться вам в самых неожиданных местах вашей системы.

Поэтому, используя NFS-клиент для Windows следует четко понимать все плюсы, минусы и имеющиеся недостатки. Но в целом появление поддержки NFS в Windows — хорошо, так как делает поддержку гетерогенных сред проще.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Network File System (NFS) клиент по умолчанию не установлен в Windows Server 2022/2019/2016 и десяточных версиях Windows 11/10. Для его установки запустите Server Manager, выберите Add Roles and Features -> Client for NFS.

Если вы хотите установить графические консоли управления NFS (nfsmgmt.msc), выберите дополнительно Services for Network File System Management Tools в Remote Server Administration Tools -> Role Administration Tools -> File Services Tools.

Клиент NFS в Windows поддерживает NFSv2 и NFSv3.

Теперь вы можете подключить NFS шару с помощью PowerShell:

New-PSdrive -PSProvider FileSystem -Name M -Root \\192.168.0.211\mnt\hyperv -Persist

Опция Persist включает автоматическое подключение NFS шары после перезагрузки.

Из CMD:

mount -o anon nolock \\192.168.0.211\mnt\hyperv M:

Также вы можете смонтировать NFS каталог из графического интерфейса File Explorer.

Для отключения NFS шары, выполните:

Umount M:

Или

Remove-PSdrive -Name M

При подключении NFS шары может появится ошибка:

The remote device or resource won’t accept the connection.

Чтобы исправить проблему, запустите консоль Services for Network File System (NFS) и проверьте права для подключения к удаленному ресурсу.

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

New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousUID -Value 000001f4 -PropertyType "DWord"
New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousGID -Value 00000064 -PropertyType "DWord"

Если для подключения нужно всегда использовать учетную запись root, измените значения параметров AnonymousUID и AnonymousGID на 0.

Если вы используете NFS подключения в окружении Active Directory, нужно отменить важный нюанс.

Если в AD не добавлены UNIX атрибуты и User Name Mapping не настроен, то для подключения к NFS серверу из Windows будет использоваться анонимное подключение. Для использование учетных данных для подключения к NFS вам нужно внести изменения в схему AD (атрибуты uidNumber и gidNumber).

На контроллерах домена WS 2012R2 можно добавить вкладку UNIX атрибутов в свойствах пользователя AD:

Dism.exe /online /enable-feature /featurename:adminui /all

Однако эта опция является deprecated в Windows Server 2016 и атрибуты пользователя предлагается править вручную или с помощью PowerShell:

Set-ADUser -identity user1 -add @{uidNumber="<user_unix_uid>";gidNumber="<user_unix_gid>"}

При подключении NFS каталога также может появится ошибка:

You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.

В этом случае нужно создать параметр реестра AllowInsecureGuestAuth:
New-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters -Name AllowInsecureGuestAuth -Value 00000001
New-ItemProperty HKLM:\ oftware\Policies\Microsoft\Windows\LanmanWorkstation -Name AllowInsecureGuestAuth -Value 00000001
Затем перепустите службу 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 \\server\path\to\directory 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.com\nfs\testdata x:

One can control the UID and GID that Windows is using for anonymous mounts using
the registry keys HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default\AnonymousUID
and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default\AnonymousGID (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:\windows\system32\drivers\etc\passwd
and C:\windows\system32\drivers\etc\group

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:\users\exampleuser

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