Сетевая файловая система NFS является родным для мира Linux способом организации общего доступа к файлам по сети и ее взаимоотношения с Windows долгое время оставались напряженными. Однако последнее время ситуация начала меняться и Windows перешел от конфронтации к сотрудничеству с открытым ПО. Начиная с Windows 10 1607 (14393) в системе появился штатный NFS-клиент, который позволяет прозрачно подключать и использовать NFS-ресурсы. В данной статье мы расскажем, как его установить и использовать, а также разберем некоторые особенности эксплуатации.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Для установки 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 — хорошо, так как делает поддержку гетерогенных сред проще.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Modern organizations typically use a mixture of operating systems, including Unix, Linux, Windows and macOS. Network File System (NFS) is an open client/server protocol that allows organizations to centralize their data storage on one or more servers and enable seamless file sharing between their various operating systems.
This blog explains how to mount NFS Windows clients so users can access shared files over the network as if they were stored locally. It also provides best practices to optimize both security and performance.
Configuring NFS on Windows: Step-by-Step Guide
To allow a user to access remote NFS files, follow these steps to configure Windows mount NFS.
Step 1: Install the ‘Client for NFS’ feature on your Windows machine to set up the NFS client for Windows.
In Windows 10 or Windows 11, open Control Panel and go Windows Features. Expand Services for NFS and check the box next to Client for NFS, as shown below.
For Windows Server 2012 and above, run the Roles and Features Wizard and select Client for NFS, as shown below.
Alternatively, you can use an elevated Windows PowerShell session to install the NFS client Windows:
- For Windows 10 or Window 11, the command is:
Enable-WindowsOptionalFeature -Online -FeatureName ServicesForNFS-ClientOnly
- For Windows Server, the command is:
Install-WindowsFeature -Name NFS-Client
Step 2: Verify the client and connectivity.
Verify that the NFS Client service is running on your machine, as shown below.
Of course, you must have connectivity to the designated NFS server. For a successful Windows NFS mount, ensure that the NFS Client service is running and the firewall allows NFS traffic. The default port is 2049.
Step 3: Perform identity mapping.
To enable Windows users to authenticate to a Unix server providing NFS exports, we need to map Windows users to the Unix user identifiers (UIDs) and group identifiers (GIDs) used by Unix-like operating systems. This mapping allows the Unix server to determine which user made the request for the NFS export.
Identity mapping can be done using any of the following methods:
- Active Directory (if integrated with the NFS environment)
- Local user mapping files
- Windows Registry settings
The first option is preferred for security and scalability reasons.
Method A (Preferred): Perform Identity Mapping in Active Directory (AD)
If both the Unix NFS server and Windows NFS client are joined to the same Active Directory domain, then we can use identity mapping in Active Directory. This is the preferred method whenever possible.
By default, a NFS client won’t look up identity mapping in Active Directory. However, we can change that by running the following command in an elevated PowerShell session on the NFS client:
Set-NfsMappingStore -EnableADLookup $True -ADDomainName “yourdomain.com”
You can add these LDAP options to specify your domain controllers:
Set-NfsMappingStore -LdapServers “dc1.yourdomain.com”,”dc2.yourdomain.com”
Restart the NFS client service.
Next, we need to configure our identity mapping. We can do that in Active Directory Users and Computers as follows:
- Enable Advanced Features enabled under the View dropdown, as shown below.
- Right-click on the object you want to view and select Properties.
- In the Attribute Editor tab, select the uidNumber or gidNumber attribute and click Edit.
- Enter a value, and click OK to save your changes.
Alternatively, you can use the following PowerShell command:
Set-ADUser -Identity <UserPrincipalName> -Add @{uidNumber=”<user_unix_uid>”;gidNumber=”<user_unix_gid>”}
Replace the following:
- UserPrincipalName — The user to modify (e.g., user@domain.com)
- @{ … } — A hashtable containing the new attributes to add
- uidNumber — The Unix user ID (UID) for the user
- gidNumber — The Unix group ID (GID) for the user’s primary group
To perform this task automatically, create a CSV file containing user data and loop through it.
Method B: Perform Identity Mapping using Local Configuration Files
Using local user mapping files is a straightforward approach to establish correspondence between Windows users and Unix UIDs/GIDs without relying on Active Directory. This method uses two main configuration files:
- passwd — Maps Windows users to Unix UIDs
- group — Maps Windows groups to Unix GIDs
Both files are typically located in the C:\Windows\system32\drivers\etc\ directory. They follow a specific format, with each line representing a user or group mapping. When a Windows user attempts to access an NFS resource, the NFS service consults these files to look up the user’s Windows account name and retrieve the corresponding UID and GID, which are then used for NFS operations.
This method is simple to set up and manage in small environments and is particularly useful for standalone servers or workgroups. However, because it requires manual maintenance of mapping files, it doesn’t scale well for large environments. In addition, while it offers a solution for environments where Active Directory integration is not feasible, it’s important to consider security implications and regularly audit the mappings to ensure they remain accurate and secure.
Method C: Perform Identity Mapping using Windows Registry Settings
This method involves setting registry values to specify a default UID and GID that the Windows NFS client will use when accessing NFS shares. It’s particularly useful when you want all NFS access from the Windows client to appear as a specific Unix user, regardless of the Windows user account.
To implement this mapping, use the following PowerShell commands:
New-ItemProperty “HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default” -Name AnonymousUID -Value <unix_export_owner_uid> -PropertyType “DWord”
New-ItemProperty “HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default” -Name AnonymousGID -Value <unix_export_owner_gid> -PropertyType “DWord”
You need to reboot to have the new settings take effect. This mapping will apply to all NFS mounts made by the Windows client. After performing identity mapping, you can mount NFS in Windows using the command prompt.
Note that this method applies the same UID/GID to all NFS access from the Windows client, which may not provide sufficient access control in multi-user environments. In addition, modifying the registry requires administrative privileges, which could be a security concern. For these and other reasons, this method is considered an insecure approach and is not recommended.
Mounting in NFS means attaching a remote file system (exported by an NFS server) to a directory on the local file system of a client machine. When a client mounts an NFS share, it connects to the remote file system and makes it appear as if the NFS share is part of the local directory structure.
To mount NFS on Windows, map it to an available drive letter using the command prompt, as follows:
mount \\<nfs_server_ip_address>\<pathtonfsexport> Z:
Replace the following:
- <nfs_server_ip_address> — The IP address of your NFS server
- <pathtonfsexport> — The export path on the server
- Z — The drive letter to which the NFS share will be mounted on your Windows computer.
You can add additional options; for instance, mount -o anon specifies that the connection should be made anonymously, and mount -o nolock overrides the default file locking used by NFS.
After running the mount or mount o command,check whether the NFS share was successfully mounted by running the net use command to display all mapped network drives.
Troubleshooting Tips
Here are some errors that can arise during the mounting process and their typical underlying causes:
- Permission denied — Incorrect export settings on the NFS server or NFS rule blocking
- Access denied by server — Mismatched UID/GID between client and server
- Version mismatch — Client and server using incompatible NFS versions
- Mount point already in use — Attempting to mounting to a directory that’s already being used as a mount point
- No such file or directory — The export path on the server doesn’t exist
Best Practices for NFS Mounting on Windows
The following best practices can help you optimize security and performance when using NFS mounting on Windows.
Security
- Use strong authentication protocols such as Kerberos.
- Configure firewalls to segment the network and restrict NFS access from untrusted networks, allowing only necessary ports (TCP and UDP port 2049).
- Encrypt data in transit using secure protocols to safeguard data against eavesdropping and tampering.
- Limit NFS export permissions by granting the minimum required access and restricting client connections to specific IP addresses or hostnames.
- Regularly update and patch both the Windows client and NFS server to protect against known vulnerabilities.
- Enable detailed logging on the NFS server and monitor for suspicious activity.
- Use additional network security measures like VPNs for remote access.
Performance
- If possible, use NFSv4 or NFSv4.1 rather than NFSv3.
- Enable read and write caching on the client side to improve performance for frequently accessed data. You can do this using the following command: mount –o readcache,writecache.
- If security is not a concern in your environment, consider using the nolock option to disable file locking.
- Keep the Windows NFS client software up to date to benefit from the latest performance improvements and bug fixes.
FAQ
Does Windows 11 support NFS clients?
Yes, Windows 11 supports NFS clients.
How can I use NFS in Windows?
Here are some ways you can use NFS in Windows:
- You can provide access to the same file share using both the SMB and NFS protocols by using a Windows NFS file server.
- You can deploy a non-Windows operating system to provide NFS file shares accessible to non-Windows clients using the NFS protocol.
- To enable applications to be migrated from one operating system to another, you can store data on file shares accessible using both the SMB and NFS protocols.
What improvements are included in NFS version 4.1?
For complete details, visit the Microsoft NFS page. Key improvements in version 4.1 include:
- Remote Procedure Call (RPC)/External Data Representation (XDR) transport infrastructure, which offers better support and provides better scalability
- RPC port multiplexer
- Auto-tuned caches and thread pools
- New Kerberos privacy implementation and authentication options
How do I add the server for NFS role service?
In Server Manager or Windows Admin Center, use the Add Roles and Features Wizard.
What Windows command-line administration tools does Server for NFS contain?
- Mount provides an NFS mount on Windows clients that maps to a local drive.
- Nfsadmin manages configuration settings of the Server for NFS and Client for NFS components.
- Nfsshare sets up NFS share settings for folders that are shared via Server for NFS.
- Nfsstat displays or resets statistics on calls received by Server for NFS.
- Showmount lists the file systems that have been exported by Server for NFS.
Security Researcher at Netwrix and member of the Netwrix Security Research Team. Joe is an expert in Active Directory, Windows, and a wide variety of enterprise software platforms and technologies, Joe researches new security risks, complex attack techniques, and associated mitigations and detections.
Администрируя серверы на базе ОС 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. Будем использовать это в работе.
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 и консоль управления с помощью PowerShell:
Install-WindowsFeature NFS-Client, RSAT-NFS-Admin
В Windows 10/11 для установки NFS клиента выполните:
Enable-WindowsOptionalFeature -FeatureName ServicesForNFS-ClientOnly, ClientForNFS-Infrastructure -Online -NoRestart
Клиент 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.
NFS (Network File System) — сетевой протокол доступа к доступ к файлам и файловой системе NFS-сервера, популярный в семейства ОС Linux/ UNIX, а также различных системах хранения. Microsoft также, не желая отставать от конкурентов, внедрила базовый функционал NFS сервера еще в Windows Server 2003 R2. В последующих версиях серверных платформ Microsoft возможности встроенного NFS Windows сервера расширялись, появлялся новый функционал и средства управления. NFS сервер в Windows Server 2012 – очередная веха в развитии данной технологии.
Что же нового предлагают нам разработчики Microsoft в данном продукте? Новые возможности NFS сервера в Windows Server 2012:
- Поддержка стандарта NFS v4.1. Поддержка последней версии NFS 4.1 – одно из основных новшеств Windows Server 2012. По сравнению с NFS v3 этот протокол обеспечивает повышенную безопасность, производительность и совместимость, полностью реализуя все аспекты RFC 5661.
- Производительность «из коробки». Благодаря использованию новой транспортной инфраструктуры RPC-XDR, оптимальная производительность NFS сервера может быть достигнута сразу «из коробки» без необходимости тонкой настройки параметров системы. Оптимальная производительность достигается за счет автоматически настраивающегося кэша, разделения рабочих процессов на пулы и динамическое управление пулами, основанное на их нагрузке.
- Упрощенное развертывание и управление. Данный факт достигнут за счет:
- — более 40 командлетов PowerShell для настройки сервера NFS и управления общими папками
- — простого графического интерфейса управления, позволяющего одновременно управлять как SMB, так и NFS шарами, а также настройками скрининга файлов и файловой классификации.
- — фиксации RPC порта (порт 2049) для простоты настройки файерволов
- — нового провайдера WMI v2
- — упрощенной идентификации за счет плоского файла мапинга
- Улучшения в NFSv3. За счет быстрой отправки клиентам уведомлений о сбоях монитором NSM (Network Status Monitor), старые NFS клиенты лучше и быстрее обрабатывают процедуру failover, что означает меньшее время простоя.
Итак, NFS сервер в Windows Server 2012 значительно улучшен с точки зрения простоты развертывания, масштабируемость, стабильность, доступность, надежность, безопасности и совместимости. Общие папки могут быть одновременно доступны по протоколам SMB и NFS, что означает возможность использования Windows Server 2012 в качестве хранилища в гетерогенных сетях.
Далее мы разберем сценарий развертывания и управления сервером NFS в Windows Server 2012.
Установка NFS сервера в Windows Server 2012
NFS сервер в Windows Server 2012 можно установить с помощью GUI и Powershell. Чтобы установить NFS сервер с помощью графического интерфейса, откройте консоль Server Manager и внутри роли файлового сервера (File and Storage Services) отметьте компонент Server for NFS.
После окончания установки компонента NFS, сервер необходимо перезагрузить.
Установка этой же роли с помощью Powershell также не вызывает затруднений, просто выполните команду:
Add-WindowsFeature "FS-NFS-Service"
Настройка общей папки NFS в Windows Server 2012
Далее мы покажем, как с помощью установленной нами роли создать NFS шару (общую папку) на сервере Windows. Создать NFS шару можно опять несколькими способами: с помощью графического интерфейса или Powershell.
Создание общего каталога NFS с помощью консоли Server Manager
Откройте консоль Server Manager, перейдите в раздел Share management (находится внутри роли File and Storage Services).
В контекстном меню запустите мастер создания нового общего каталога- New Share…
Выберите тип шары NFS Share — Quick
Далее нужно указать местоположение каталога на диске и путь, по которому должны подключатся удаленные NFS клиенты.
Затем необходимо задать тип аутентификации NFS клиентов: возможно, задействовать как Kerberos- аутентификацию, так и анонимную.
Предположим, в качестве потребителя создаваемого NFS ресурса будет выступать сервер виртуализации ESXi, в котором возможность аутентифицировать NFS соединения отсутствует (ESXi не поддерживает NFSv4). Поэтому тип аутентификации будет No Server Authentication, отметим также опции Enable unmapped user access и Allow unmapped user access by UID/GID.
Чтобы немного обезопасить создаваемую NFS шару от доступа сторонних лиц, ограничим доступ к NFS ресурсу по IP адресу клиента.
Host: 192.168.1.100
Language Encoding : BIG5
Share Permissions : Read/Write
Allow root access : Yes
Далее осталось проверить, что на уровне NTFS пользователь, в которого мапится подключающийся юзер, имеет доступ на чтение/запись (если решено задействовать анонимный доступ, придется для пользователя Everyone дать полные r/w права на уровне NTFS).
Как создать NFS шару с помощью Powershell
Создадим новую NFS шару:
New-NfsShare -Name "NFS " -Path "d:\shares\nfr" -AllowRootAccess $true -Permission Readwrite -Authentication sys
Разрешим доступ к шаре для IP адреса 192.168.1.100 и зададим кодировку BIG5 (возможность просмотра содержимого NFS шары для клиента ESXi).
Grant-NfsSharePermission -Name “NFS” -ClientName 192.168.1.100 -ClientType host -LanguageEncoding BIG5
Созданную NFS шару можно использовать, например, как NFS-datastore в среде виртуализации VMWare vSphere, или для доступа к данным с других Unix-like клиентов. Как смонтировать NFS шару в Windows — клиентах описано в этой статье.