Триколор 

Сетевая файловая система 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:

  1. Поддержка стандарта NFS v4.1 . Поддержка последней версии NFS 4.1 – одно из основных новшеств Windows Server 2012. По сравнению с NFS v3 этот протокол обеспечивает повышенную безопасность, производительность и совместимость, полностью реализуя все аспекты RFC 5661.
  2. Производительность «из коробки». Благодаря использованию новой транспортной инфраструктуры RPC-XDR, оптимальная производительность NFS сервера может быть достигнута сразу «из коробки» без необходимости тонкой настройки параметров системы. Оптимальная производительность достигается за счет автоматически настраивающегося кэша, разделения рабочих процессов на пулы и динамическое управление пулами, основанное на их нагрузке.
  3. Упрощенное развертывание и управление . Данный факт достигнут за счет:
    • — более 40 командлетов PowerShell для настройки сервера NFS и управления общими папками
    • — простого графического интерфейса управления, позволяющего одновременно управлять как SMB, так и NFS шарами, а также настройками скрининга файлов и .
    • — фиксации RPC порта (порт 2049) для простоты настройки файерволов
    • — нового провайдера WMI v2
    • — упрощенной идентификации за счет плоского файла мапинга
  4. Улучшения в NFSv3 . За счет быстрой отправки клиентам уведомлений о сбоях монитором NSM (Network Status Monitor), старые NFS клиенты лучше и быстрее обрабатывают процедуру failover, что означает меньшее время простоя.

Итак, NFS сервер в Windows Server 2012 значительно улучшен с точки зрения простоты развертывания, масштабируемость, стабильность, доступность, надежность, безопасности и совместимости. Общие папки могут быть одновременно доступны по протоколам SMB и NFS, что означает возможность использования Windows Server 2012 в качестве хранилища в гетерогенных сетях.

NFS сервер в Windows Server 2012 можно установить с помощью GUI и Powershell. Чтобы установить NFS сервер с помощью графического интерфейса, откройте и внутри роли файлового сервера (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 клиентов: возможно, задействовать как 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 в среде виртуализации , или для доступа к данным с других Unix-like клиентов. Как смонтировать NFS шару в Windows — клиентах описано в статье.

Сетевая файловая система (NFS - Network File System) является решением об­щего доступа к файлам для организаций, которые имеют смешанные среды машин с Windows и Unix/Linux. Файловая система NFS дает возможность открывать общий доступ к файлам между указанными разными платформами при функционирую­щей операционной системе Windows Server 2012. Службы NFS в Windows Server 2012 включают следующие возможности и усовершенствования.

1. Поиск в Active Directory. Вы имеете возможность применять Windows Active Directory для доступа к файлам. Расширение схемы Identity Management for Unix (Управление удостоверениями для Unix) для Active Directory содержит поля идентификатора пользователя Unix (Unix user identifier - UID) и иден­тификатора группы (group identifier - GID). Это позволяет службам Server for NFS (Сервер для NFS) и Client for NFS (Клиент для NFS) просматривать отображения учетных записей пользователей Windows на Unix прямо из служб домена Active Directory (Active Directory Domain Services). Компонент Identity Management for Unix упрощает управление отображением учетных записей пользователей Windows на Unix в Active Directory Domain Services.

2. Улучшенная производительность сервера. Службы для NFS включают драйвер фильтра файлов, который значительно сокращает общие задержки при досту­пе к файлам на сервере.

3. Поддержка специальных устройств Unix. Службы для NFS поддерживают спе­циальные устройства Unix (mknod).

4. Расширенная поддержка Unix. Службы для NFS поддерживают следующие вер­сии Unix: Sun Microsystems Solaris версии 9, Red Hat Linux версии 9, IBM AIX версии 5L 5.2 и Hewlett Packard HP-UX версии 11i, а также многие современные дистрибутивы Linux.

Один из наиболее распространенных сценариев, который создает необходи­мость в применении NFS, предусматривает открытие доступа пользователям в среде Windows к системе планирования ресурсов предприятия (enterprise resource planning - ERP), основанной на Unix. Находясь в системе ERP, пользователи могут создавать отчеты и/или экспортировать финансовые данные в Microsoft Excel для дальнейшего анализа. Файловая система NFS позволяет обращаться к этим файлам, по-прежнему находясь в среде Windows, что сокращает потребность в наличии специальных технических навыков и снижает временные затраты на экспорт файлов с использованием сценария Unix и последующий их импорт в определенное приложение Windows.

Может также возникнуть ситуация, когда у вас имеется система Unix, которая применяется для хранения файлов в какой-то сети хранения данных (Storage Area Network - SAN). Запуск служб NFS на машине Windows Server 2012 позволяет пользователям в организации получать доступ к сохраненным там файлам без накладных расходов, связанных со сценариями на стороне Unix.

До установки служб NFS вы должны удалить любые ранее установленные компоненты NFS, такие как компоненты NFS, которые были включены в состав Services for Unix.

Компоненты служб NFS

Доступны следующие два компонента служб NFS.

1. Server for NFS (Сервер для NFS). Обычно компьютер, основанный на Unix, не может обращаться к файлам, расположенным на компьютере, основанном на Windows. Тем не менее, компьютер, на котором функционирует Windows Server 2012 R2 и компонент Server for NFS, может действовать в качестве файло­вого сервера для компьютеров с Windows и Unix.

2. Client for NFS (Клиент для NFS). Обычно компьютер, основанный на Windows, не может обращаться к файлам, находящимся на компьютере, основанном на Unix. Тем не менее, компьютер, на котором функционирует Windows Server 2012 R2 и компонент Client for NFS, может получать доступ к файлам, которые хранятся на сервере NFS, основанном на Unix.

Установка Server For NFS с помощью PowerShell

Давайте посмотрим, как применять PowerShell для установки роли NFS на сервере и для создания общего файлового ресурса NFS.

1. Откройте окно Windows PowerShell через панель задач от имени учетной запи­си администратора.

2. Введите следующие команды, чтобы установить роль NFS на сервере:

PS С:\> Import-Module ServerManager PS С:\> Add-WindowsFeature FS-NFS-Services PS С:\> Import-Module NFS

3. Введите приведенную ниже команду, чтобы создать новый общий файловый ресурс NFS:

PS С:\> New-NfsShare -Name "Test" -Path "C:\Shares\Test"

4. Для просмотра всех новых командлетов PowerShell, относящихся к NFS, кото­рые доступны в Windows Server 2012 R2, выполните следующую команду:

PS С:\> Get-Command -Module NFS

5. Щелкните по папке C:\Shares\Test правой кнопкой мыши, выберите «свойства», далее перейдите на вкладку NFS Sharing (Общий доступ NFS). Нажмите на кнопку Manage NFS Sharing (Управлять общим доступом NFS), в появившемся диалоговом окне вы можете управлять разрешениями для доступа к папке, разрешить анонимный доступ, настроить параметры кодировки файлов. Вы можете открывать общий доступ к папке по NFS с помощью диалогового окна NFS Advanced Sharing без использования PowerShell.

Установка стандартных разрешений

Теперь нам потребуется открыть некоторые порты брандмауэра для функционирования NFS. Порты, необходимые для нормального функционирования служб NFS, представлены ниже в таблице.

Network file system (NFS) - протокол сетевого доступа к файловым системам, позволяет подключать удалённые файловые системы.
Первоначально разработан Sun Microsystems в 1984 г. Основой является Sun RPC: вызов удаленной процедуры (Remote Procedure Call). NFS независим от типов файловых систем сервера и клиента. Существует множество реализаций NFS-серверов и клиентов для различных ОС. В настоящее время используется версия NFS v.4, поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).
NFS предоставляет клиентам прозрачный доступ к файлам и файловой системе сервера. В отличие от FTP, протокол NFS осуществляет доступ только к тем частям файла, к которым обратился процесс, и основное достоинство его в том, что он делает этот доступ прозрачным. Благодаря этому любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с NFS файлом, без изменений самой программы.
NFS клиенты получают доступ к файлам на NFS сервере путем отправки RPC-запросов на сервер. Это может быть реализовано с использованием обычных пользовательских процессов - а именно, NFS клиент может быть пользовательским процессом, который осуществляет конкретные RPC вызовы на сервер, который так же может быть пользовательским процессом.

Версии
NFSv1 была только для внутреннего пользования в экспериментальных целях. Детали реализации определены в RFC 1094.
NFSv2 (RFC 1094, март 1989 года) первоначально полностью работала по протоколу UDP.
NFSv3 (RFC 1813, июнь 1995 года). Описатели файлов в версии 2 - это массив фиксированного размера - 32 байта. В версии 3 - это массив переменного размера с размером до 64 байт. Массив переменной длины в XDR определяется 4-байтным счётчиком, за которым следуют реальные байты. Это уменьшает размер описателя файла в таких реализациях, как, например, UNIX, где требуется всего около 12 байт, однако позволяет не-Unix реализациям обмениваться дополнительной информацией.
Версия 2 ограничивает количество байт на процедуры READ или WRITE RPC размером 8192 байта. Это ограничение не действует в версии 3, что, в свою очередь, означает, что с использованием UDP ограничение будет только в размере IP датаграммы (65535 байт). Это позволяет использовать большие пакеты при чтении и записи в быстрых сетях.
Размеры файлов и начальное смещение в байтах для процедур READ и WRITE стали использовать 64-битную адресацию вместо 32-битной, что позволяет работать с файлами большего размера.
Атрибуты файла возвращаются в каждом вызове, который может повлиять на атрибуты.
Записи (WRITE) могут быть асинхронными, тогда как в версии 2 они должны были быть синхронными.
Одна процедура была удалена (STATFS) и семь были добавлены: ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1 информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение).
На момент введения версии 3, разработчики стали больше использовать TCP как транспортный протокол. Хотя некоторые разработчики уже Использовали протокол TCP для NFSv2, Sun Microsystems добавили поддержку TCP в NFS версии 3. Это сделало использование NFS через Интернет более осуществимым.
NFSv4 (RFC 3010, декабрь 2000 г., RFC 3530, пересмотренная в апреле 2003), под влиянием AFS и CIFS, включила в себя улучшение производительности, высокую безопасность, и предстала полноценным протоколом. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF), после того, как Sun Microsystems передала развитие протоколов NFS. NFS версии v4.1 была одобрена IESG в январе 2010 года, и получила номер RFC 5661. Важным нововведением версии 4.1 является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые "облачные" ("cloud") хранилища и информационные системы.

Структура NFS
Структура NFS включает три компонента разного уровня:
Прикладной уровень (собственно NFS) - это вызовы удаленных процедур (rpc), которые и выполняют необходимые операции с файлами и каталогами на стороне сервера.
Функции уровня представления выполняет протокол XDR (eXternal Data Representation), который является межплатформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую, форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.
Сервис RPC (Remote Procedure Call), обеспечивающий запрос удаленных процедур клиентом и их выполнение на сервере, представляет функции сеансового уровня.Подключение сетевых ресурсов
Процедура подключения сетевого ресурса средствами NFS называется "экспортированием". Клиент может запросить у сервера список представляемых им экспортируемых ресурсов. Сам сервер NFS не занимается широковещательной рассылкой списка своих экспортируемых ресурсов.
В зависимости от заданных опций, экспортируемый ресурс может быть смонтирован (присоединён) "только для чтения", можно определить список хостов, которым разрешено монтирование, указать использование защищенного RPC (secureRPC) и пр. Одна из опций определяет способ монтирования: "жесткое" (hard) или "мягкое" (soft).
При "жестком" монтировании клиент будет пытаться смонтировать файловую систему во что бы то ни стало. Если сервер не работает, это приведет к тому, что весь сервис NFS как бы зависнет: процессы, обращающиеся к файловой системе, перейдут в состояние ожидания окончания выполнения запросов RPC. С точки зрения пользовательских процессов файловая система будет выглядеть как очень медленный локальный диск. При возврате сервера в рабочее состояние сервис NFS продолжит функционирование.
При "мягком" монтировании клиент NFS сделает несколько попыток подключиться к серверу. Если сервер не откликается, то система выдает сообщение об ошибке и прекращает попытки произвести монтирование. С точки зрения логики файловых операций при отказе сервера "мягкое" монтирование эмулирует сбой локального диска.
Выбор режима зависит от ситуации. Если данные на клиенте и сервере должны быть синхронизированы при временном отказе сервиса, то "жесткое" монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах "только для чтения", режим "мягкого" монтирования представляется более удобным.

Общий доступ в смешанной сети
Сервис NFS идеально подходит для сетей на основе UNIX, так как поставляется с большинством версий этой операционной системы. Более того, поддержка NFS реализована на уровне ядра UNIX. Использование NFS на клиентских компьютерах с Windows создает определенные проблемы, связанные с необходимостью установки специализированного и довольно дорогого клиентского ПО. В таких сетях использование средств разделения ресурсов на основе протокола SMB/CIFS, в частности ПО Samba, выглядит более предпочтительным.

Стандарты
RFC 1094 NFS: Network File System Protocol Specification] (March 1989)
RFC 1813 NFS Version 3 Protocol Specification] (June 1995)
RFC 2224 NFS URL Scheme
RFC 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols
RFC 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol’s Use of RPCSEC_GSS and Kerberos V5
RFC 2624 NFS Version 4 Design Considerations
RFC 3010 NFS version 4 Protocol
RFC 3530 Network File System (NFS) version 4 Protocol
RFC 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol

Используемые источники
1. ru.wikipedia.org
2. ru.science.wikia.com
3. phone16.ru
4. 4stud.info
5. yandex.ru
6. gogle.com

NFS
Уровень (по модели OSI): Прикладной
Семейство: стек протоколов TCP/IP
Порт/ID: 67, 68/UDP
Назначение протокола: Получение сетевой конфигурации
Спецификация: RFC 2131
Основные реализации (серверы): dhcpd, ISC DHCP Server, Infoblox
Вступил в силу с: 1990

NFS абстрагирован от типов файловых систем как сервера, так и клиента, существует множество реализаций NFS-серверов и клиентов для различных операционных систем и аппаратных архитектур. Наиболее зрелая версия NFS - v.4, поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).

Общая организация NFS

NFS предоставляет клиентам прозрачный доступ к файлам и файловой системе сервера. В отличие от FTP , протокол NFS осуществляет доступ только к тем частям файла, к которым обратился процесс, и основное достоинство его в том, что он делает этот доступ прозрачным. Это означает, что любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с NFS файлом, без каких либо модификаций самой программы.

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

Важной частью последней версии стандарта NFS (v4.1) стала спецификация pNFS, нацеленная на обеспечение распараллеленной реализации общего доступа к файлам, увеличивающая скорость передачи данных пропорционально размерам и степени параллелизма системы.

История

Протокол NFS имеет в своей истории 4 версии.

Первая версия применялась только для внутреннего использования в Sun в экспериментальных целях. Версия 2 выпущена в марте 1989 года, первоначально полностью работала по протоколу UDP. Разработчики решили не хранить данных о внутреннем состоянии внутри протокола, как пример, блокировка, реализованная вне базового протокола. Люди, вовлечённые в создание NFS версии 2 - Расти Сэндберг (Rusty Sandberg,) Боб Лайон (Bob Lyon), Билл Джой и Стив Клейман (Steve Kleiman).

NFSv3 вышла в июне 1995 года, в ней добавлена поддержка дескрипторов файлов переменного размера до 64 байт (в версии 2 - массив фиксированного размера 32 байта), снято ограничение на 8192 байта в RPC-вызовах чтения и записи (тем самым, размер передаваемого блока в вызовах ограничен только пределом для UDP-датаграммы - 65535 байт), реализована поддержка файлов больших размеров, поддержаны асинхронные вызовы операций записи, к процедурам READ и WRITE добавлены вызовы ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1-информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение). На момент введения версии 3 отмечен рост популярности в среде разработчиков протокола TCP. Некоторые независимые разработчики самостоятельно добавили поддержку протокола TCP для NFS версии 2 в качестве транспортного, Sun Microsystems добавили поддержку TCP в NFS в одном из дополнений к версии 3. С поддержкой TCP повысились практическая осуществимость использования NFS в глобальных сетях.

NFSv4 выпущена в декабре 2000 года под влиянием AFS и CIFS, в неё включены улучшения производительности и безопасности. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF). NFS версии v4.1 была одобрена IESG в январе 2010 года (новая спецификация, объёмом 612 страниц, стала известна как самый длинный документ, одобренный IETF). Важным нововведением версии 4.1 является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые облачные хранилища и информационные системы.

Цели разработки

Изначальными требованиями при разработке NFS были:

  • потенциальная поддержка различных операционных систем (не только UNIX), чтобы серверы и клиенты NFS возможно было бы реализовать в разных операционных системах;
  • протокол не должен зависеть от каких-либо определённых аппаратных средств;
  • должны быть реализованы простые механизмы восстановления в случае отказов сервера или клиента;
  • приложения должны иметь прозрачный доступ к удаленным файлам без использования специальных путевых имен или библиотек и без перекомпиляции;
  • для UNIX-клиентов должна поддерживаться семантика UNIX;
  • производительность NFS должна быть сравнима с производительностью локальных дисков;
  • реализация не должна быть зависимой от транспортных средств.

Принцип работы NFS

NFS строится по крайней мере из двух основных частей: сервера и одного или большего количества клиентов. Клиент обращается к данным, находящимся на сервере, в режиме удалённого доступа. Для того, чтобы это нормально функционировало, нужно настроить и запустить несколько процессов. Реализация NFS состоит из нескольких компонентов. Некоторые из них локализованы либо на сервере, либо на клиенте, а некоторые используются и на обеих сторонах соединения. Некоторые компоненты не требуются для обеспечения основных функциональных возможностей, но составляют часть расширенного интерфейса NFS.

Протокол NFS определяет набор запросов (операций), которые могут быть направлены клиентом к серверу, а также набор аргументов и возвращаемые значения для каждого из этих запросов. Версия 1 этого протокола существовала только в недрах Sun Microsystems и никогда не была выпущена. Все реализации NFS (в том числе NFSv3) поддерживают версию 2 NFS (NFSv2), которая впервые была выпущена в 1985 году в SunOS 2.0. Версия 3 протокола была опубликована в 1993 году и реализована некоторыми фирмами-поставщиками.

Протокол удаленного вызова процедур (RPC) определяет формат всех взаимодействий между клиентом и сервером. Каждый запрос NFS посылается как пакет RPC. На сервере работают следующие даемоны :

  • rpc.nfsd - Основной даемон сервера NFS - nfsd (в новых версиях иногда называется nfsd4). Этот демон обслуживает запросы клиентов NFS. Параметр RPCNFSDCOUNT в файле /etc/default/nfs-kernel-server в Debian и NFSDCOUNT в файле /etc/sysconfig/nfs в RedHat определяет число запускаемых демонов (по-умолчанию - 8). (RPC программа 100003)
  • rpc.mountd - Даемон монтирования NFS mountd обрабатывает запросы клиентов на монтирование каталогов. Демон mountd работает на серверах NFS. (RPC программа 100005)
  • rpc.statd - Даемон наблюдения за сетевым состоянием (он же Network Status Monitor, он же NSM). Он позволяет корректно отменять блокировку после сбоя/перезагрузки. Для уведомления о сбое использует программу /usr/sbin/sm-notify. Демон statd работает как на серверах, так и на клиентах. Ранее данный сервер был необходим для работы rpc.lockd, но за блокировки сейчас отвечает ядро. (RPC программа 100021 и 100024 - в новых версиях)
  • rpc.lockd - Даемон блокировки lockd (он же NFS lock manager (NLM)) обрабатывает запросы на блокировку файлов. Демон блокировки работает как на серверах, так и на клиентах. Клиенты запрашивают блокировку файлов, а серверы ее разрешают. (устарел и в новых дистрибутивах не используется как демон. Его функции в современных дистрибутивах (с ядром старше 2.2.18) выполняются ядра (lockd). (RPC программа 100024)
  • rpc.idmapd - Даемон idmapd для NFSv4 на сервере преобразует локальные uid/gid пользователей в формат вида имя@домен, а сервис на клиенте преобразует имена пользователей/групп вида имя@домен в локальные идентификаторы пользователя и группы (согласно конфигурационному файлу /etc/idmapd.conf).

Клиент может запустить также даемон, называемый nfsiod. nfsiod обслуживает запросы, поступающие от сервера от сервера NFS. Он необязателен, увеличивает производительность, однако для нормальной и правильной работы не требуется. В NFSv4 при использовании Kerberos дополнительно запускаются демоны:

  • rpc.gssd - Даемон NFSv4 обеспечивает методы аутентификации через GSS-API (Kerberos-аутентификация). Работает на клиенте и сервере.
  • rpc.svcgssd - Даемон сервера NFSv4, который обеспечивает проверку подлинности клиента на стороне сервера.

Даемоны старых версий (NFS v.3 и ниже):

  • nfslogd - даемон журналов NFS фиксирует активность для экспортированных файловых систем, работает на серверах NFS
  • rpc.rquotad - сервер удаленных квот предоставляет информацию о квотах пользователей в удаленных файловых системах, может работать как на серверах, так и на клиентах.

Кроме указанных выше пакетов, для корректной работы NFSv2 и v3 требуется дополнительный пакет portmap (в более новых дистрибутивах заменен на переименован в rpcbind). Sun RPC - это сервер, который преобразует номера программ RPC (Remote Procedure Call) в номера портов TCP/UDP.

portmap оперирует несколькими сущностями:

  • RPC-вызовами или запросами
  • TCP/UDP портами, версией протокола (tcp или udp)
  • номерами программ и версиями программ

Даемон portmap запускается скриптом /etc/init.d/portmap до старта NFS-сервисов.

Работа сервера RPC (Remote Procedure Call) заключается в обработке RPC-вызовов (т.н. RPC-процедур) от локальных и удаленных процессов. Используя RPC-вызовы, сервисы регистрируют или удаляют себя в/из преобразователя портов (portmap, portmapper, он же, в новых версиях, rpcbind), а клиенты с помощью RPC-вызовов направляя запросы к portmapper получают необходимую информацию.

Работу RPC-сервера можно представить следующими шагами:

  1. Преобразователь портов должен стартовать первым, обычно при загрузке системы. При этом создается конечная точка TCP и осуществляется открытие TCP порта 111. Также создается конечная точка UDP, которая находится в ожидании, когда на UDP порт 111 прибудет UDP датаграмма.
  2. При старте программа, работающая через сервер RPC создает конечную точку TCP и конечную точку UDP для каждой поддерживаемой версии программы. (Сервер RPC может поддерживать несколько версий. Клиент указывает требуемую версию при посылке RPC-вызова.) Динамически назначаемый номер порта закрепляется за каждой версией сервиса. Сервер регистрирует каждую программу, версию, протокол и номер порта, осуществляя соответствующий RPC-вызов.
  3. Когда программе клиента RPC необходимо получить необходимую информацию, она вызывает вызов процедуру преобразователя портов, чтобы получить динамически назначаемый номер порта для заданной программы, версии и протокола.
  4. В ответ на этот запрос север возвращает номер порта.
  5. Клиент отправляет сообщение RPC-запрос на номер порта, полученный в пункте 4. Если используется UDP, клиент просто посылает UDP датаграмму, содержащую сообщение RPC-вызова, на номер UDP порта, на котором работает запрошенный сервис. В ответ сервис отправляет UDP датаграмму, содержащую сообщение RPC отклика. Если используется TCP, клиент осуществляет активное открытие на номер TCP порта требуемого сервиса и затем посылает сообщение вызова RPC по установленному соединению. Сервер отвечает сообщением отклика RPC по соединению.

Для получения информации от RPC-сервера используется утилита rpcinfo, она отображает номер зарегистрированной программы, версию, протокол, порт и название. С помощью rpcinfo также можно удалить регистрацию программы или получить информацию об отдельном сервисе RPC. При указании параметров -p host программа выводит список всех зарегистрированных RPC программ на хосте host. Без указания хоста программа выведет сервисы на localhost.

NFS сервер (точнее даемон rpc.nfsd) получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS работает с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт 2049 жестко закреплен за NFS в большинстве реализаций.

Описание процесса обращения к файлу, расположенному на сервере NFS:

  • Клиенту (пользовательскому процессу) безразлично, получает ли он доступ к локальному файлу или к NFS файлу. Ядро занимается взаимодействием с железом через модули ядра или встроенные системные вызовы.
  • Модуль ядра kernel/fs/nfs/nfs.ko, который выполняет функции NFS клиента отправляет RPC запросы NFS серверу через модуль TCP/IP. NFS обычно использует UDP, однако более новые реализации могут использовать TCP.
  • NFS сервер получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS может работать с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт 2049 жестко закреплен за NFS в большинстве реализаций.
  • Когда NFS сервер получает запрос от клиента, он передаётся локальной подпрограмме доступа к файлу, которая обеспечивает доступ к локальному диску на сервере.
  • Результат обращения диску возвращается клиенту.

Настройка сервера NFS

Настройка сервера в целом заключается в задании локальных каталогов, разрешенных для монтирования удаленными системами в файле /etc/exports. Это действие называется экспорт иерархии каталогов. Основными источниками информации об экспортированных каталогах служат следующие файлы:

Структура папки Root

  1. /etc/exports - основной конфигурационный файл, хранящий в себе конфигурацию экспортированных каталогов. Используется при запуске NFS и утилитой exportfs.
  2. /var/lib/nfs/xtab - содержит список каталогов, монтированных удаленными клиентами. Используется демоном rpc.mountd, когда клиент пытается смонтировать иерархию (создается запись о монтировании).
  3. /var/lib/nfs/etab - список каталогов, которые могут быть смонтированы удаленными системами с указанием всех параметров экспортированных каталогов.
  4. /var/lib/nfs/rmtab - список каталогов, которые не разэкспортированы в данный момент.
  5. /proc/fs/nfsd - специальная файловая система (ядро 2.6) для управления NFS сервером.
  6. /proc/net/rpc - содержит "сырую" (raw) статистику, которую можно получить с помощью nfsstat, а также различные кеши.
  7. /var/run/portmap_mapping - информация о зарегистрированных в RPC сервисах.

В файле exports используются следующие общие опции:

  • auth_nlm (no_auth_nlm) или secure_locks (insecure_locks) - указывает, что сервер должен требовать аутентификацию запросов на блокировку (с помощью протокола NFS Lock Manager (диспетчер блокировок NFS)).
  • nohide (hide) - если сервер экспортирует две иерархии каталогов, при этом одна вложенна (примонтированна) в другую. Клиенту необходимо явно смонтировать вторую (дочернюю) иерархию, иначе точка монтирования дочерней иерархии будет выглядеть как пустой каталог. Опция nohide приводит к появлению второй иерархии каталогов без явного монтирования.
  • ro - Разрешает только запросы на чтение.
  • rw - Разрешает запросы на запись.
  • secure (insecure) - требует, чтобы запросы NFS поступали с защищенных портов (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
  • subtree_check (no_subtree_check) - Если экспортируется подкаталог фаловой системы, но не вся файловая система, сервер проверяет, находится ли запрошенный файл в экспортированном подкаталоге. Отключение проверки уменьшает безопасность, но увеличивает скорость передачи данных.
  • sync (async) - указывает, что сервер должен отвечать на запросы только после записи на диск изменений, выполненных этими запросами. Опция async указывает серверу не ждать записи информации на диск, что повышает производительность, но понижает надежность, т.к. в случае обрыва соединения или отказа оборудования возможна потеря информации.
  • wdelay (no_wdelay) - указывает серверу задерживать выполнение запросов на запись, если ожидается последующий запрос на запись, записывая данные более большими блоками. Это повышает производительность при отправке больших очередей команд на запись. no_wdelay указывает не откладывать выполнение команды на запись, что может быть полезно, если сервер получает большое количество команд не связанных друг с другом.

Управление сервером NFS

Управление сервером NFS осуществляется с помощью следующих утилит:

  • nfsstat
  • showmsecure (insecure)ount
  • exportfs

Утилита nfsstat позволяет посмотреть статистику RPC и NFS серверов.

showmount

Утилита showmount запрашивает демон rpc.mountd на удалённом хосте о смонтированных файловых системах. По умолчанию выдаётся отсортированный список клиентов. Команды:

  • --all - выдаётся список клиентов и точек монтирования с указанием куда клиент примонтировал каталог. Эта информация может быть не надежной.
  • --directories - выдаётся список точек монтирования.
  • --exports - выдаётся список экспортируемых файловых систем с точки зрения nfsd.

При запуске showmount без аргументов, на консоль будет выведена информация о системах, которым разрешено монтировать локальные каталоги.

exportfs

Данная команда синхронизирует экспортированные каталоги, заданные в файле /etc/exports, с файлом /var/lib/nfs/xtab и удаляет из xtab несуществующие. exportfs выполняется при запуске демона nfsd с аргументом -r. Утилита exportfs в режиме ядра 2.6 общается с демоном rpc.mountd через файлы каталога /var/lib/nfs/ и не общается с ядром напрямую. Без параметров выдаёт список текущих экспортируемых файловых систем. Параметры exportfs:

  1. [клиент:имя-каталога] - добавить или удалить указанную файловую систему для указанного клиента)
  2. -v - выводить больше информации
  3. -r - переэкспортировать все каталоги (синхронизировать /etc/exports и /var/lib/nfs/xtab)
  4. -u - удалить из списка экспортируемых
  5. -a - добавить или удалить все файловые системы
  6. -o - опции через запятую (аналогичен опциям применяемым в /etc/exports; т.о. можно изменять опции уже смонтированных файловых систем)
  7. -i - не использовать /etc/exports при добавлении, только параметры текущей командной строки
  8. -f - сбросить список экспортируемых систем в ядре 2.6.

Монтирование файловой системы Network Files System командой mount

Пример команды mount для монтирования файловой системы NFS в Debian:

FILES ~ # mount -t nfs archiv:/archiv-small /archivs/archiv-small FILES ~ # mount -t nfs -o ro archiv:/archiv-big /archivs/archiv-big FILES ~ # mount ....... archiv:/archiv-small on /archivs/archiv-small type nfs (rw,addr=10.0.0.6) archiv:/archiv-big on /archivs/archiv-big type nfs (ro,addr=10.0.0.6)

Первая команда монтирует экспортированный каталог /archiv-small на сервере archiv в локальную точку монтирования /archivs/archiv-small с опциями по умолчанию (то есть для чтения и записи). Вторая команда монтирует экспортированный каталог /archiv-big на сервере archiv в локальный каталог /archivs/archiv-big с опцией только для чтения (ro). Команда mount без параметров наглядно отображает нам результат монтирования. Кроме опции только чтения (ro), возможно задать другие основные опции при монтировании NFS :

  • nosuid - Данная опция запрещает исполнять setuid программы из смонтированного каталога.
  • nodev (no device - не устройство) - Данная опция запрещает использовать в качестве устройств символьные и блочные специальные файлы.
  • lock (nolock) - Разрешает блокировку NFS (по умолчанию). nolock отключает блокировку NFS (не запускает демон lockd) и удобна при работе со старыми серверами, не поддерживающими блокировку NFS.
  • mounthost=имя - Имя хоста, на котором запущен демон монтирования NFS - mountd.
  • mountport=n - Порт, используемый демоном mountd.
  • port=n - порт, используемый для подключения к NFS серверу (по умолчанию 2049, если демон rpc.nfsd не зарегистрирован на RPC-сервере). Если n=0 (по умолчанию), то NFS посылает запрос к portmap на сервере, чтобы определить порт.
  • rsize=n (read block size - размер блока чтения) - Количество байтов, читаемых за один раз с NFS-сервера. Стандартно - 4096.
  • wsize=n (write block size - размер блока записи) - Количество байтов, записываемых за один раз на NFS-сервер. Стандартно - 4096.
  • tcp или udp - Для монтирования NFS использовать протокол TCP или UDP соответственно.
  • bg - При потери доступа к серверу, повторять попытки в фоновом режиме, чтобы не блокировать процесс загрузки системы.
  • fg - При потери доступа к серверу, повторять попытки в приоритетном режиме. Данный параметр может заблокировать процесс загрузки системы повторениями попыток монтирования. По этой причине параметр fg используется преимущественно при отладке.
  • Опции, влияющие на кэширование атрибутов при монтировании NFS
  • Атрибуты файлов, хранящиеся в inod (индексных дескрипторах), такие как время модификации, размер, жесткие ссылки, владелец, обычно изменяются не часто для обычных файлов и еще реже - для каталогов. Ядро использует время модификации файла, чтобы определить устарел ли кэш, сравнивая время модификации в кэше и время модификации самого файла.

Кэш атрибутов периодически обновляется в соответствии с заданными параметрами:

  1. ac (noac) (attrebute cache - кэширование атрибутов) - Разрешает кэширование атрибутов (по-умолчанию). Хотя опция noac замедляет работу сервера, она позволяет избежать устаревания атрибутов, когда несколько клиентов активно записывают информацию в общию иерархию.
  2. acdirmax=n (attribute cache directory file maximum - кэширование атрибута максимум для файла каталога) - Максимальное количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 60 сек.)
  3. acdirmin=n (attribute cache directory file minimum - кэширование атрибута минимум для файла каталога) - Минимальное количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 30 сек.)
  4. acregmax=n (attribute cache regular file maximum - кэширование атрибута максимум для обычного файла) - Максимаьное количество секунд, которое NFS ожидает до обновления атрибутов обычного файла (по-умолчанию 60 сек.)
  5. acregmin=n (attribute cache regular file minimum- кэширование атрибута минимум для обычного файла) - Минимальное количество секунд, которое NFS ожидает до обновления атрибутов обычного файла (по-умолчанию 3 сек.)
  6. actimeo=n (attribute cache timeout - таймаут кэширования атрибутов) - Заменяет значения для всех вышуказаных опций. Если actimeo не задан, то вышеуказанные значения принимают значения по умолчанию.

Опции обработки ошибок NFS

Следующие опции управляют действиями NFS при отсутствии ответа от сервера или в случае возникновения ошибок ввода/вывода:

  • fg (bg) (foreground - передний план, background - задний план) - Производить попытки монтирования отказавшей NFS на переднем плане/в фоне.
  • hard (soft) - выводит на консоль сообщение "server not responding" при достижении таймаута и продолжает попытки монтирования. При заданной опции soft - при таймауте сообщает вызвавшей операцию программе об ошибке ввода/вывода.
  • nointr (intr) (no interrupt - не прерывать) - Не разрешает сигналам прерывать файловые операции в жестко смонтированной иерархии каталогов при достижении большого таймаута. intr - разрешает прерывание.
  • retrans=n (retransmission value - значение повторной передачи) - После n малых таймаутов NFS генерирует большой таймаут (по-умолчанию 3). Большой таймаут прекращает выполнение операций или выводит на консоль сообщение "server not responding", в зависимости от указания опции hard/soft.
  • retry=n (retry value - значение повторно попытки) - Количество минут повторений службы NFS операций монтирования, прежде чем сдаться (по-умолчанию 10000).
  • timeo=n (timeout value - значение таймаута) - Количество десятых долей секунды ожидания службой NFS до повторной передачи в случае RPC или малого таймаута (по-умолчанию 7). Это значение увеличивается при каждом таймауте до максимального значения 60 секунд или до наступления большого таймаута. В случае занятой сети, медленного сервера или при прохождении запроса через несколько маршрутизаторов или шлюзов увеличение этого значения может повысить производительность.

Повышение производительности NFS

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

Одним из способов повышения производительности NFS - увеличение количества байтов, передаваемых за один раз. Размер в 4096 байт слишком мал для современных быстрых соединений, увеличивая это значение до 8192 и более можно экспериментальным путем найти оптимальную скорость.

Так же, не стоит упускать из внимания и настройки тайм-аутов. NFS ожидает ответа на пересылку данных в течении промежутка времени, указанного в опции timeo, если ответ за это время не получен, то выполняется повторная пересылка. На загруженных и медленных соединениях это время может быть меньше времени реакции сервера и способности каналов связи, в результате чего могут быть излишние повторные пересылки, замедляющие работу.По умолчанию, timeo равно 0,7 сек (700 миллисекунд). после обнаружения факта обрыва связи в течении 700 мс сервер совершит повторную пересылку и удвоит время ожидания до 1,4 сек., увеличение timeo будет продолжаться до максимального значения в 60 сек.

пользователь может работать в разное время на разных компьютерах. С помощью файлового сервера решается сразу несколько задач:
  1. регулярное резервное копирование всех данных: нереально выполнять эту операцию для нескольких десятков или сотен компьютеров, но вполне реально - с единственного сервера или нескольких серверов.
  2. повышение надежности хранения данных: неразумно каждый компьютер сети оснащать RAID-массивом, ведь подавляющее большинство файлов в компьютере, таких, как установленные пакеты программ, проще установить заново, чем защищать их от сбоя; но будет вполне разумным укомплектовать файловый сервер аппаратным RAID-массивом или организовать там программный RAID-массив, хотя бы простое зеркалирование дисков.
  3. уменьшение стоимости хранения данных: дорого и неэффективно в каждый компьютер устанавливать огромный диск на случай, если потребуется хранить много данных, но на сервере вполне можно установить масштабируемую дисковую подсистему большого объема.
  4. обеспечение доступа к одним и тем же данным с любого компьютера.

Описание NFS

Служба NFS позволяет серверу обеспечить разделяемый доступ к указанным каталогам его локальной файловой системы , а клиенту - монтировать эти каталоги так же, как если бы они были локальными каталогами клиента.

Версии NFS

NFS , разработанная компанией Sun Microsystems, оказалась настолько удачной, что ее реализации были воплощены разными компаниями почти во всех операционных системах. Существует несколько принципиально разных реализаций NFS . Достаточно распространена версия NFS 2.0, хотя уже в Solaris 2.5 была введена NFS 3.0. В последующих версиях Solaris, включая Solaris 9, в NFS были внесены существенные дополнения, но сам протокол остался совместимым с реализациями NFS 3.0 в других системах. Начиная с NFS 3.0, поддерживается передача пакетов посредством TCP и UDP, ранее поддерживался только UDP.

Будьте внимательны ! В сети следует использовать клиенты и серверы NFS одной и той же версии . NFS 2.0 можно встретить в старых системах, например, в HP-UX 10.0. Совместная работа систем, использующих разные версии NFS , нежелательна.

Совместимость NFS и других служб разделяемых каталогов

NFS по смыслу и по организации работы похожа на разделяемые каталоги (shared folders) в системах Windows, но эти службы используют совершенно разные протоколы работы и между собой не совместимы. Однако существует несколько программных продуктов, которые устанавливают поддержку NFS в системах Windows, поэтому применение NFS в сети с различными операционными системами не представляет проблемы, надо только помнить о необходимости использовать одинаковые версии NFS .

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

Поскольку компьютеры на рабочих местах сотрудников в России обычно управляются Windows-системами, в качестве файловых серверов часто используются также Windows-системы. Однако нередко возникает желание установить UNIX на файл-сервер, чтобы повысить надежность, сократить затраты на оборудование или использовать этот же сервер для ряда других корпоративных нужд: в качестве web-сервера, сервера баз данных и т.п. Чтобы не устанавливать дополнительное ПО для поддержки NFS , в таком случае достаточно установить пакет samba на UNIX-машину. Он позволит ей "прикинуться" Windows-сервером так, чтобы все клиентские компьютеры воспринимали его как самый обычный файл-сервер или принт-сервер Windows-сети. Пакет samba обеспечивает поддержку "родного" для Windows-сетей протокола SMB.

В тех случаях, когда в сети работают несколько UNIX-компьютеров и им нужно обращаться к одному файл-серверу, имеет смысл использовать механизм NFS (network file system).

NFS не очень устойчив к сбоям сети, требует ее бесперебойной работы и предполагает быстрое соединение между клиентом и сервером. Использование NFS для монтирования файловых систем вне локальной сети, например, через Интернет, технически осуществимо, но не очень рационально и небезопасно.

Терминология NFS

После настройки NFS-сервера UNIX-компьютер будет предоставлять доступ внешним пользователям к некоторым каталогам своей файловой системы . Такое предоставление доступа называется "экспортом": говорят, что система экспортирует свои каталоги. Как именно каталоги будут экспортироваться, определяется списком, который задает системный администратор. В большинстве систем UNIX этот список содержится в файле /etc/exports , но в Solaris он находится в другом файле - /etc/dfs/dfstab .

NFS работает посредством механизма удаленного вызова процедур ( RPC - Remote Procedure Call ).

Что такое RPC

Идеология RPC очень проста и привлекательна для программиста. Как обычно работает сетевое приложение? Оно следует некоему протоколу (например, HTTP): формирует пакет с запросом, вызывает системную функцию установления соединения, затем функцию отправки пакета, затем ждет ответного пакета и вызывает функцию закрытия соединения. Это значит, что вся работа с сетью является заботой программиста, который пишет приложение: он должен помнить о вызове функций сетевого API системы, думать о действиях в случае сбоев сети.

RPC предполагает иной способ обмена данными между клиентом и сервером. С точки зрения программиста, приложение клиента, работающее с помощью RPC , вызывает функцию на сервере, она выполняется и возвращает результат. Пересылка запроса на выполнение функции через сеть и возврат результатов от сервера клиенту происходит незаметно для приложения, поэтому последнее не должно беспокоиться ни о сбоях сети, ни о деталях реализации транспортного протокола.

Для того чтобы обеспечить прозрачность пересылки данных через сеть, придумана двухступенчатая процедура. На сервере любое приложение, предоставляющее свой сервис через RPC , должно зарегистрироваться в программе, которая называется транслятором портов (port mapper). Функция этой программы - устанавливать соответствие между номером процедуры RPC , которую запросил клиент, и номером TCP или UDP порта, на котором приложение сервера ждет запросов. Вообще говоря, RPC может работать не только с TCP или UDP. В Solaris как раз реализована работа на базе механизма TI (TransportIndependent), поэтому в Solaris транслятор портов называется rpcbind , а не portmap , как в Linux или FreeBSD.

Приложение, которое регистрируется у транслятора портов, сообщает ему номер программы, номер версии и номера процедур, которые могут обрабатываться данной программой. Эти процедуры будут впоследствии вызываться клиентом по номеру. Кроме этого, приложение сообщает номера портов TCP и UDP, которые будут использоваться для приема запросов на выполнение процедур.

Клиент, желающий вызвать выполнение процедуры на сервере, сначала отправляет запрос транслятору портов на сервер, чтобы узнать, на какой TCP или UDP порт надо отправить запрос. Транслятор портов запускается при старте системы и всегда работает на стандартном порту 111. Получив ответ от него, клиент отправляет запрос на тот порт, который соответствует требуемому приложению. Например, сервер NFS работает на порту 2049.

Процедура монтирования общего каталога через NFS

Прежде чем мы перейдем к описанию настроек сервера и клиентов NFS , следует понять, как осуществляется монтирование удаленных файловых систем в принципе.

Клиент NFS посылает запрос на монтирование удаленному компьютеру, который предоставляет свою файловую систему (обычно - некоторую ее часть) для общего пользования. При этом говорят, что сервер NFS "экспортирует" тот или иной каталог (подразумевается - с подкаталогами). Запрос от клиента