Руководство по nfs

Доброго времени, читатели и гости моего блога. Очень большой перерыв между постами был, но я снова в бою ). В сегодняшней статье рассмотрю работу протокола NFS, а так же настройку сервера NFS и клиента NFS на Linux.

Введение в NFS

NFS (Network File System — сетевая файловая система) по моему мнению — идеальное решение в локальной сети, где необходим быстрый (более быстрый по сравнению с SAMBA и менее ресурсоемкий по сравнению с удаленными файловыми системами с шифрованием — sshfs, SFTP, etc…) обмен данными и во главе угла не стоит безопасность передаваемой информации. Протокол NFS позволяет монтировать удалённые файловые системы через сеть в локальное дерево каталогов, как если бы это была примонтирована дисковая файловая система. Тем самым локальные приложения могут работать с удаленной файловой системой, как с локальной. Но нужно быть осторожным (!) с настройкой NFS, ибо при определенной конфигурации можно подвесить операционную систему клиента в ожидании бесконечного ввода/вывода. Протокол NFS основан на работе протокола RPC, который пока не поддается моему пониманию )) поэтому материал в статье будет немного расплывчат… Прежде, чем Вы сможете использовать NFS, будь это сервер или клиент, Вы должны удостовериться, что Ваше ядро имеет поддержку файловой системы NFS. Проверить поддерживает ли ядро файловую систему NFS можно, просмотрев наличие соответствующих строк в файле /proc/filesystems:

ARCHIV ~ # grep nfs /proc/filesystems
nodev nfs
nodev nfs4
nodev nfsd

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

История Network File System

Протокол NFS разработан компанией Sun Microsystems и имеет в своей истории 4 версии. NFSv1 была разработана в 1989 и являлась экспериментальной, работала на протоколе UDP. Версия 1 описана в RFC 1094. NFSv2 была выпущена в том же 1989 г., описывалась тем же RFC1094 и так же базировалась на протоколе UDP, при этом позволяла читать не более 2Гб из файла. NFSv3 доработана в 1995 г. и описана в RFC 1813. Основными нововведениями третьей версии стало поддержка файлов большого размера, добавлена поддержка протокола TCP и TCP-пакетов большого размера, что существенно ускорило работоспосбоность технологии. NFSv4 доработана в 2000 г. и описана в RFC 3010, в 2003 г. пересмотрена и описана в RFC 3530. Четвертая версия включила в себя улучшение производительности, поддержку различных средств аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов). NFS версии v4.1 была одобрена IESG в 2010 г., и получила номер RFC 5661. Важным нововведением версии 4.1, является спецификация pNFS — Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые «облачные» («cloud») хранилища и информационные системы.

NFS сервер

Так как у нас NFS — это сетевая файловая система, то необходимо настроить сеть в Linux. (Так же можно почитать статью основные понятия сетей). Далее необходимо установить соответствующий пакет. В Debian это пакет nfs-kernel-server и nfs-common, в RedHat это пакет nfs-utils. А так же, необходимо разрешить запуск демона на необходимых уровнях выполнения ОС (команда в RedHat — /sbin/chkconfig nfs on, в Debian — /usr/sbin/update-rc.d nfs-kernel-server defaults).

Установленные пакеты в Debian запускается в следующем порядке:

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs
lrwxrwxrwx  1 root root   20 Окт 18 15:02 S15nfs-common -> ../init.d/nfs-common
lrwxrwxrwx  1 root root   27 Окт 22 01:23 S16nfs-kernel-server -> ../init.d/nfs-kernel-server

То есть, сначала запускается nfs-common, затем сам сервер nfs-kernel-server. В RedHat ситуация аналогичная, за тем лишь исключением, что первый скрипт называется nfslock, а сервер называется просто nfs. Про nfs-common нам сайт debian дословно говорит следующее: общие файлы для клиента и сервера NFS, этот пакет нужно устанавливать на машину, которая будет работать в качестве клиента или сервера NFS. В пакет включены программы: lockd, statd, showmount, nfsstat, gssd и idmapd. Просмотрев содержимое скрипта запуска /etc/init.d/nfs-common можно отследить следующую последовательность работы: скрипт проверяет наличие исполняемого бинарного файла /sbin/rpc.statd, проверяет наличие в файлах /etc/default/nfs-common, /etc/fstab и /etc/exports параметров, требующих запуск демонов idmapd и gssd, запускает демона  /sbin/rpc.statd, далее перед запуском /usr/sbin/rpc.idmapd и /usr/sbin/rpc.gssd проверяет наличие этих исполняемых бинарных файлов, далее для демона /usr/sbin/rpc.idmapd проверяет наличие модулей ядра sunrpc, nfs и nfsd, а так же поддержку файловой системы rpc_pipefs в ядре (то есть наличие ее в файле /proc/filesystems), если все удачно, то запускает /usr/sbin/rpc.idmapd. Дополнительно, для демона /usr/sbin/rpc.gssd проверяет модуль ядра rpcsec_gss_krb5 и запускает демон.

Если просмотреть содержимое скрипта запуска NFS-сервера на Debian (/etc/init.d/nfs-kernel-server), то можно проследить следующую последовательность: при старте, скрипт проверяет существование файла /etc/exports, наличие модуля ядра nfsd, наличие поддержки файловой системы NFS в ядре Linux (то есть в файле /proc/filesystems), если все на месте, то запускается демон /usr/sbin/rpc.nfsd, далее проверяет задан ли параметр NEED_SVCGSSD (задается в файле настроек сервера /etc/default/nfs-kernel-server ) и, если задан — запускает демона /usr/sbin/rpc.svcgssd, последним запускает демона /usr/sbin/rpc.mountd. Из данного скрипта видно, что работа сервера NFS состоит из демонов rpc.nfsd, rpc.mountd и если используется Kerberos-аутентификация, то и демон rcp.svcgssd. В краснойшляпе еще запускается демон rpc.rquotad и nfslogd (В Debian я почему-то не нашел информации об этом демоне и о причинах его отсутствия, видимо удален…).

Из этого становиться понятно, что сервер Network File System состоит из следующих процессов (читай — демонов), расположенных в каталогах /sbin и /usr/sbin :

• 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.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.idmapd — Демон idmapd для NFSv4 на сервере преобразует локальные uid/gid пользователей в формат вида имя@домен, а сервис на клиенте преобразует имена пользователей/групп вида имя@домен в локальные идентификаторы пользователя и группы (согласно конфигурационному файлу /etc/idmapd.conf, подробней в man idmapd.conf):.
• дополнительно, в старых версиях NFS использовались демоны: nfslogd — демон журналов NFS фиксирует активность для экспортированных файловых систем, работает на серверах NFS и rquotad — сервер удаленных квот  предоставляет информацию о квотах пользователей в удаленных файловых системах, может работать как на серверах, так и на клиентах.(RPC программа 100011)

В NFSv4 при использовании Kerberos дополнительно запускаются демоны:

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

portmap и протокол RPC (Sun RPC)

Кроме указанных выше пакетов, для корректной работы NFSv2 и v3 требуется дополнительный пакет portmap (в более новых дистрибутивах заменен на переименован в rpcbind). Данный пакет обычно устанавливается автоматически с NFS как зависимый и реализует работу сервера RPС, то есть отвечает за динамическое назначение портов для  некоторых служб, зарегистрированных в 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 получают необходимую информацию. Юзер-френдли названия сервисов программ и соответствующие им номера определены в файле /etc/rpc. Как только какой-либо сервис отправил соответствующий запрос и зарегистрировал себя на сервере RPC в отображателе портов, RPC-сервер присваивает сопоставляет сервису TCP и UDP порты на которых запустился сервис и хранит в себе ядре соответствующую информацию о работающем сервисе (о имени), уникальном номере сервиса (в соответствии с /etc/rpc) , о протоколе и порте на котором работает сервис и о версии сервиса и предоставляет указанную информацию клиентам по запросу. Сам преобразователь портов имеет номер программы (100000), номер версии — 2, TCP порт 111 и UDP порт 111. Выше, при указании состава демонов сервера NFS я указал основные RPC номера программ. Я, наверно, немного запутал Вас данным абзацем, поэтому произнесу основную фразу, которая должна внести ясность: основная функция отображателя портов заключается в том, чтобы по запросу клиента, который предоставил номер RPC-программы (или RPC-номер программы) и версию, вернуть ему (клиенту) порт, на котором работает запрошенная программа. Соответственно, если клиенту нужно обратиться к RPC с конкретным номером программы, он сначала должен войти в контакт с процессом portmap на серверной машине и определить номер порта связи с необходимым ему сервисом RPC.

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

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

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

ARCHIV ~ # rpcinfo -p
   прог-ма верс прото   порт
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  59451  status
    100024    1   tcp  60872  status
    100021    1   udp  44310  nlockmgr
    100021    3   udp  44310  nlockmgr
    100021    4   udp  44310  nlockmgr
    100021    1   tcp  44851  nlockmgr
    100021    3   tcp  44851  nlockmgr
    100021    4   tcp  44851  nlockmgr
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100005    1   udp  51306  mountd
    100005    1   tcp  41405  mountd
    100005    2   udp  51306  mountd
    100005    2   tcp  41405  mountd
    100005    3   udp  51306  mountd
    100005    3   tcp  41405  mountd

Как видно, rpcinfo отображает (в столбиках слева направо) номер зарегистрированной программы, версию, протокол, порт и название. С помощью rpcinfo можно удалить регистрацию программы или получить информацию об отдельном сервисе RPC (больше опций в man rpcinfo). Как видно, зарегистрированы демоны portmapper версии 2 на udp и tcp портах, rpc.statd версии 1 на udp и tcp портах, NFS lock manager версий 1,3,4, демон nfs сервера версии 2,3,4,  а так же демон монтирования версий 1,2,3.

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

Работа протокола Network File System

Монтирование удаленной NFS

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

Описание протокола NFS при монтировании удаленного каталога:

1. На сервере и клиенте запускается RPC сервер (обычно при загрузке), обслуживанием которого занимается процесс portmapper и регистрируется на порту tcp/111 и udp/111.
2. Запускаются сервисы (rpc.nfsd,rpc.statd и др.), которые регистрируются на RPC сервере и регистрируются на произвольных сетевых портах (если в настройках сервиса не задан статичный порт).
3. команда mount на компьютере клиента отправляет ядру запрос на монтирование сетевого каталога с указанием типа файловой системы, хоста и собственно — каталога, ядро отправляет формирует RPC-запрос процессу portmap на NFS сервере на порт udp/111 (если на клиенте не задана опция работать через tcp)
4. Ядро сервера NFS опрашивает RPC о наличии демона rpc.mountd и возвращает ядру клиента сетевой порт, на котором работает демон.
5. mount отправляет RPC запрос на порт, на котором работает rpc.mountd. Теперь NFS сервер может проверить достоверность клиента основываясь на его IP адресе и номере порта, чтобы убедиться, можно ли этому клиенту смонтировать указанную файловую систему.
6. Демон монтирования возвращает описание запрошенной файловой системы.
7. Команда mount клиента выдает системный вызов mount, чтобы связать описатель файла, полученный в шаге 5, с локальной точкой монтирования на хосте клиента. Описатель файла хранится в коде NFS клиента, и с этого момента любое обращение пользовательских процессов к файлам на файловой системе сервера будет использовать описатель файла как стартовую точку.

Обмен данными между клиентом и сервером NFS

Типичный доступ к удаленной файловой системе можно описать следующей схемой:

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

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

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

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

• /etc/exports — основной конфигурационный файл, хранящий в себе конфигурацию экспортированных каталогов. Используется при запуске NFS и утилитой exportfs.
• /var/lib/nfs/xtab — содержит список каталогов, монтированных удаленными клиентами. Используется демоном rpc.mountd, когда клиент пытается смонтировать иерархию (создается запись о монтировании).
• /var/lib/nfs/etab — список каталогов, которые могут быть смонтированы удаленными системами с указанием всех параметров экспортированных каталогов.
• /var/lib/nfs/rmtab — список каталогов, которые не разэкспортированы в данный момент.
• /proc/fs/nfsd — специальная файловая система (ядро 2.6) для управления NFS сервером.
  • exports — список активных экспортированных иерархий и клиентов, которым их экспортировали, а также параметры. Ядро получает данную информацию из /var/lib/nfs/xtab.
  • threads — содержит число потоков (также можно изменять)
  • с помощью filehandle можно получить указатель на файл
  • и др…
• /proc/net/rpc — содержит «сырую» (raw) статистику, которую можно получить с помощью nfsstat, а также различные кеши.
• /var/run/portmap_mapping — информация о зарегистрированных в RPC сервисах

Прим: вообще, в интернете куча трактовок и формулировок назначения файлов xtab, etab, rmtab, кому верить — не знаю Даже на http://nfs.sourceforge.net/ трактовка не однозначна.

Настройка файла /etc/exports

В простейшем случае, файл /etc/exports является единственным файлом, требующим редактирования для настройки NFS-сервера.  Данный файл управляет следующими аспектами:

• Какие клиенты могут обращаться к файлам на сервере
• К каким иерархиям каталогов на сервере может обращаться каждый клиент
• Как пользовательские имена клиентов будут отображаться на локальные имена пользователей

Каждая строка файла exports имеет следующий формат:

точка_экспорта клиент1(опции) [клиент2(опции)  …]

, где точка_экспорта абсолютный путь экспортируемой иерархии каталогов, клиент1 — n имя одного или более клиентов или IP-адресов, разделенные пробелами, которым разрешено монтировать точку_экспорта. Опции описывают правила монтирования для клиента, указанного перед опциями.

Вот типичный пример конфигурации файла exports:

ARCHIV ~ # cat /etc/exports
/archiv1        files(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)

В данном примере компьютерам files и 10.0.0.1 разрешен доступ к точке экспорта /archiv1, при этом, хосту files на чтение/запись, а для хоста 10.0.0.1 и подсети 10.0.230.1/24 доступ только на чтение.

Описания хостов в /etc/exports допускается в следующем формате:

• Имена отдельных узлов описываются, как files или files.DOMAIN.local.
• Описание маски доменов производится в следующем формате: *DOMAIN.local включает все узлы домена DOMAIN.local.
• Подсети задаются в виде пар адрес IP/маска. Например: 10.0.0.0/255.255.255.0 включает все узлы, адреса которых начинаются с 10.0.0.
• Задание имени сетевой группы @myclients имеющей доступ к ресурсу (при использовании сервера NIS)

Общие опции экспорта иерархий каталогов

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

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

• в клиентской  файловой системе должен существовать объект ссылки
• необходимо экспортировать и смонтировать объект ссылки

Файл устройства относится к интерфейсу ядра Linux. При экспорте файла устройства экспортируется этот интерфейс. Если клиентская система  не имеет устройства такого же типа, то экспортированное устройство не будет работать. В клиентской системе, при монтировании NFS объектов можно использовать опцию nodev, чтобы файлы устройств в монтируемых каталогах не использовались.

Опции по умолчанию в разных системах могут различаться, их можно посмотреть в файле /var/lib/nfs/etab. После описания экспортированного каталога в /etc/exports и перезапуска сервера NFS все недостающие опции (читай: опции по-умолчанию) будут отражены в файле /var/lib/nfs/etab.

Опции отображения (соответствия) идентификаторов пользователей

Для большего понимания нижесказанного я бы посоветовал ознакомиться со статьей Управление пользователями Linux. Каждый пользователь Linux имеет свои UID и главный GID, которые описаны в файлах /etc/passwd и /etc/group. Сервер NFS считает, что операционная система удаленного узла выполнила проверку подлинности пользователей и назначила им корректные идентификаторы UID и GID. Экспортирование файлов дает пользователям системы клиента такой же доступ к этим файлам, как если бы они регистрировались напрямую на сервере. Соответственно, когда клиент NFS посылает запрос серверу, сервер использует UID и GID для идентификации пользователя в локальной системе, что может приводить к некоторым проблемам:

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

Следующие опции задают правила отображения удаленных пользователей в локальных:

• root_squash (no_root_squash) — При заданной опции root_squash, запросы от пользователя root отображаются на анонимного uid/gid, либо на пользователя, заданного в параметре anonuid/anongid.
• no_all_squash (all_squash) — Не изменяет UID/GID подключающегося пользователя. Опция all_squash задает отображение ВСЕХ пользователей (не только root), как анонимных или заданных в параметре anonuid/anongid.
• anonuid=UID и anongid=GID — Явно задает UID/GID для анонимного пользователя.
• map_static=/etc/file_maps_users — Задает файл, в котором можно задать сопоставление удаленных UID/GID — локальным UID/GID.

Пример использования файла маппинга пользователей:

ARCHIV ~ # cat /etc/file_maps_users
# Маппинг пользователей
# remote local comment
uid 0-50 1002 # сопоставление пользователей с удаленным UID 0-50 к локальному UID 1002
gid 0-50 1002 # сопоставление пользователей с/span удаленным GID 0-50 к локальному GID 1002

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

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

• nfsstat
• showmsecure (insecure)ount
• exportfs

nfsstat: статистика NFS и RPC

Утилита nfsstat позволяет посмотреть статистику RPC и NFS серверов. Опции команды можно посмотреть в man nfsstat.

showmount: вывод информации о состоянии NFS

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

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

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

FILES ~ # showmount --exports archiv
Export list for archiv:
/archiv-big   10.0.0.2
/archiv-small 10.0.0.2

Если указать в аргументе имя хоста/IP, то будет выведена информация о данном хосте:

ARCHIV ~ # showmount files
clnt_create: RPC: Program not registered
# данное сообщение говорит нам, что на хосте FILES демон NFSd не запущен

exportfs: управление экспортированными каталогами

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

Параметры exportfs:

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

Клиент NFS

Прежде чем обратиться к файлу на удалённой файловой системе клиент (ОС клиента) должен смонтировать её и получить от сервера указатель на неё. Монтирование NFS может производиться с помощью команды mount или с помощью одного из расплодившихся автоматических монтировщиков (amd, autofs, automount, supermount, superpupermount). Процесс монтирования хорошо продемонстрирована выше на иллюстрации.

На клиентах NFS никаких демонов запускать не нужно, функции клиента выполняет модуль ядра kernel/fs/nfs/nfs.ko, который используется при монтировании удаленной файловой системы. Экспортированные каталоги с сервера могут монтироваться на клиенте следующими способами:

• вручную, с помощью команды mount
• автоматически при загрузке, при монтировании файловых систем, описанных в /etc/fstab
• автоматически с помощью демона autofs

Третий способ с autofs в данной статье я рассматривать не буду, ввиду его объемной информации. Возможно в следующих статьях будет отдельное описание.

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

Пример использования команды mount представлен в посте Команды управления блочными устройствами. Тут я рассмотрю пример команды mount для монтирования файловой системы NFS:

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 с опциями по умолчанию (то есть для чтения и записи). Хотя команда mount в последних дистрибутивах умеет понимать какой  тип файловой системы используется и без указания типа, все же указывать параметр -t nfs желательно. Вторая команда монтирует экспортированный каталог /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 (индексных дескрипторах), такие как время модификации, размер, жесткие ссылки, владелец, обычно изменяются не часто для обычных файлов и еще реже — для каталогов. Многи программы, например ls, обращаются к файлам только для чтения и не меняют атрибуты файлов или содержимое, но затрачивают ресурсы системы на дорогостоящие сетевые операции. Чтобы избежать ненужных затрат ресурсов, можно кэшировать данные атрибуты.  Ядро использует время модификации файла, чтобы определить устарел ли кэш, сравнивая время модификации в кэше и время модификации самого файла. Кэш атрибутов периодически обновляется в соответствии с заданными параметрами:

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

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

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

• fg (bg) (foreground — передний план, background — задний план) — Производить попытки монтирования отказавшей NFS на переднем плане/в фоне.
• hard (soft) — выводит на консоль сообщение «server not responding» при достижении таймаута и продолжает попытки монтирования. При заданной опции soft — при таймауте сообщает вызвавшей операцию программе об ошибке ввода/вывода. (опцию 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 при загрузке (описание файловых систем в /etc/fstab)

Описание файла /etc/fstab я затрагивал в соответствующей статье. В текущем примере я рассмотрю несколько примеров монтирования файловых систем NFS с описанием опций:

FILES ~ # cat /etc/fstab | grep nfs
archiv:/archiv-small     /archivs/archiv-small  nfs     rw,timeo=4,rsize=16384,wsize=16384   0       0
nfs-server:/archiv-big   /archivs/archiv-big    nfs     rw,timeo=50,hard,fg                  0       0

Первый пример монтирует файловую систему /archiv-small с хоста archiv в точку монтирования /archivs/archiv-small, тип файловой системы указан nfs (всегда необходимо указывать для данного типа), файловая система монтирована с опцией для чтения, записи (rw). Хост archiv подключен по быстрому локальному каналу, поэтому для повышения производительности параметр timeo уменьшен и существенно увеличены значения rsize и wsize. Поля для программ dump и fsck заданы в ноль, чтобы данные программы не использовали файловую систему, примонтированную по NFS. Второй пример монтирует файловую систему /archiv-big с хоста nfs-server. Т.к. к хосту nfs-server мы подключены по медленному соединению, параметр timeo увеличен до 5 сек (50 десятых долей сек), а так же жестко задан параметр hard, чтобы NFS продолжала перемонтировать файловую систему после большого таймаута, так же задан параметр fg, чтобы при загрузке системы и недоступности хоста nfs-server не произошло зависания.

Прежде чем сохранять изменения в /etc/fstab, обязательно попробуйте смонтировать вручную и убедитесь, что всё работает!!!

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

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

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

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

Подобрать оптимальный timeo для определенного значения передаваемого пакета (значений rsize/wsize), можно с помощью команды ping:

FILES ~ # ping -s 32768 archiv
PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) bytes of data.
32776 bytes from archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0.931 ms
32776 bytes from archiv.domain.local (10.0.0.6): icmp_req=2 ttl=64 time=0.958 ms
32776 bytes from archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03 ms
32776 bytes from archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 time=1.00 ms
32776 bytes from archiv.domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1.08 ms
^C
--- archiv.DOMAIN.local ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 0.931/1.002/1.083/0.061 ms

Как видно, при отправке пакета размером 32768 (32Kb) время его путешествия от клиента до сервера и обратно плавает в районе 1 миллисекунды. Если данное время будет зашкаливать за 200 мс, то стоит задуматься о повышении значения timeo, чтобы оно превышало значение обмена в три-четыре раза. Соответственно, данный тест желательно делать во время сильной загрузки сети

Запуск NFS и настройка Firewall

Заметка скопипсчена с блога http://bog.pp.ru/work/NFS.html, за что ему огромное спасибо!!!

Запуск сервера NFS, монтирования, блокировки, квотирования и статуса с «правильными» портами (для сетевого экрана)

• желательно предварительно размонтировать все ресурсы на клиентах
• остановить и запретить запуск rpcidmapd, если не планируется использование NFSv4:

  chkconfig --level 345 rpcidmapd off 
  service rpcidmapd stop

• если нужно, то разрешить запуск сервисов portmap, nfs и nfslock:

  chkconfig --levels 345 portmap/rpcbind on 
  chkconfig --levels 345 nfs on 
  chkconfig --levels 345 nfslock on

• если нужно, то остановить сервисы nfslock и nfs, запустить portmap/rpcbind, выгрузить модули

  service nfslock stop
  service nfs stop
  service portmap start # service rpcbind start
  umount /proc/fs/nfsd 
  service rpcidmapd stop 
  rmmod nfsd 
  service autofs stop # где-то потом его надо запустить rmmod nfs rmmod nfs_acl rmmod lockd

• открыть порты в iptables
  • для RPC: UDP/111, TCP/111
  • для NFS: UDP/2049, TCP/2049
  • для rpc.statd: UDP/4000, TCP/4000
  • для lockd: UDP/4001, TCP/4001
  • для mountd: UDP/4002, TCP/4002
  • для rpc.rquota: UDP/4003, TCP/4003
• для сервера rpc.nfsd добавить в /etc/sysconfig/nfs строку

  RPCNFSDARGS="--port 2049"

• для сервера монтирования добавить в /etc/sysconfig/nfs строку

  MOUNTD_PORT=4002

• для настройки rpc.rquota для новых версий необходимо добавить в /etc/sysconfig/nfs строку

  RQUOTAD_PORT=4003

• для настройки rpc.rquota необходимо для старых версий (тем не менее, надо иметь пакет quota 3.08 или свежее) добавить в /etc/services

  rquotad 4003/tcp 
  rquotad 4003/udp

• проверит адекватность /etc/exports
• запустить сервисы rpc.nfsd, mountd и rpc.rquota (заодно запускаются rpcsvcgssd и rpc.idmapd, если не забыли их удалить)

  service nfsd start 
   или в новых версиях 
  service nfs start

• для сервера блокировки для новых систем добавить в /etc/sysconfig/nfs строки

  LOCKD_TCPPORT=4001 
  LOCKD_UDPPORT=4001

• для сервера блокировки для старых систем добавить непосредственно в /etc/modprobe[.conf]:

  options lockd nlm_udpport=4001 nlm_tcpport=4001

• привязать сервер статуса rpc.statd к порту 4000 (для старых систем в /etc/init.d/nfslock запускать rpc.statd с ключом -p 4000)

  STATD_PORT=4000

• запустить сервисы lockd и rpc.statd

  service nfslock start

• убедиться, что все порты привязались нормально с помощью «lsof -i -n -P» и «netstat -a -n» (часть портов используется модулями ядра, которые lsof не видит)
• если перед «перестройкой» сервером пользовались клиенты и их не удалось размонтировать, то придётся перезапустить на клиентах сервисы автоматического монтирования (am-utils, autofs)

Пример конфигурации NFS сервера и клиента

Конфигурация сервера

Если вы хотите сделать ваш разделённый NFS каталог открытым и с правом записи, вы можете использовать опцию all_squash в комбинации с опциями anonuid и anongid. Например, чтобы установить права для пользователя ‘nobody’ в группе ‘nobody’, вы можете сделать следующее:

ARCHIV ~ # cat /etc/exports
# Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя 99 с gid 99
/files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))
# Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя 99 с gid 99
/files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

Это также означает, что если вы хотите разрешить доступ к указанной директории, nobody.nobody должен быть владельцем разделённой директории:

# chown -R nobody.nobody /files

Конфигурация клиента

На клиенте необходимо примонтировать удаленный каталогудобным способом, например командой mount:

FILES ~ # mount -t nfs archiv:/files /archivs/files

Резюме

Фух… Статья завершена. Сегодня мы изучили что такое Network File System и с чем ее едят, в следующей статье попытаюсь сделать HOWTO с аутентификацией Kerberos. Надеюсь материал получился доходчивым и нужным. Буду рад Вашим дополнениям и комментариям!

Дополнительно можно почитать

NFS HOWTO, nfs.sourceforge, man nfs? man mount, man exports

RFC 1094 — NFSv1, v2
RFC 1813 — NFSv3
RFC 3530 — NFSv4
RFC 5661 — NFSv4.1
NFS HOWTO
nfs.sourceforge.net
man mount
man exports
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm — производительность NFS от IBM.

С Уважением, Mc.Sim!

Теги: network, NFS, настройка, основы

NFS allows a system to share directories and files with others over a network. By using NFS, users and programs can access files on remote systems almost as if they were local files.

Some of the most notable benefits that NFS can provide are:

• Local workstations use less disk space because commonly used data can be stored on a single machine and still remain accessible to others over the network.

• There is no need for users to have separate home directories on every network machine. Home directories could be set up on the NFS server and made available throughout the network.

• Storage devices such as floppy disks, CDROM drives, and USB Thumb drives can be used by other machines on the network. This may reduce the number of removable media drives throughout the network.

Installation

At a terminal prompt enter the following command to install the NFS Server:

sudo apt install nfs-kernel-server

To start the NFS server, you can run the following command at a terminal prompt:

sudo systemctl start nfs-kernel-server.service

Configuration

You can configure the directories to be exported by adding them to the /etc/exports file. For example:

/srv     *(ro,sync,subtree_check)
/home    *.hostname.com(rw,sync,no_subtree_check)
/scratch *(rw,async,no_subtree_check,no_root_squash)

Make sure any custom mount points you’re adding have been created (/srv and /home will already exist):

sudo mkdir /scratch

Apply the new config via:

sudo exportfs -a

You can replace * with one of the hostname formats. Make the hostname declaration as specific as possible so unwanted systems cannot access the NFS mount. Be aware that *.hostname.com will match foo.hostname.com but not foo.bar.my-domain.com.

The sync/async options control whether changes are gauranteed to be committed to stable storage before replying to requests. async thus gives a performance benefit but risks data loss or corruption. Even though sync is the default, it’s worth setting since exportfs will issue a warning if it’s left unspecified.

subtree_check and no_subtree_check enables or disables a security verification that subdirectories a client attempts to mount for an exported filesystem are ones they’re permitted to do so. This verification step has some performance implications for some use cases, such as home directories with frequent file renames. Read-only filesystems are more suitable to enable subtree_check on. Like with sync, exportfs will warn if it’s left unspecified.

There are a number of optional settings for NFS mounts for tuning performance, tightening security, or providing conveniences. These settings each have their own trade-offs so it is important to use them with care, only as needed for the particular use case. no_root_squash, for example, adds a convenience to allow root-owned files to be modified by any client system’s root user; in a multi-user environment where executables are allowed on a shared mount point, this could lead to security problems.

NFS Client Configuration

To enable NFS support on a client system, enter the following command at the terminal prompt:

sudo apt install nfs-common

Use the mount command to mount a shared NFS directory from another machine, by typing a command line similar to the following at a terminal prompt:

sudo mkdir /opt/example
sudo mount example.hostname.com:/srv /opt/example

Warning

The mount point directory /opt/example must exist. There should be no files or subdirectories in the /opt/example directory, else they will become inaccessible until the nfs filesystem is unmounted.

An alternate way to mount an NFS share from another machine is to add a line to the /etc/fstab file. The line must state the hostname of the NFS server, the directory on the server being exported, and the directory on the local machine where the NFS share is to be mounted.

The general syntax for the line in /etc/fstab file is as follows:

example.hostname.com:/srv /opt/example nfs rsize=8192,wsize=8192,timeo=14,intr

Advanced Configuration

NFS is comprised of several services, both on the server and the client. Each one of these services can have its own default configuration, and depending on the Ubuntu Server release you have installed, this configuration is done in different files, and with a different syntax.

Ubuntu Server 22.04 LTS (“jammy”)

All NFS related services read a single configuration file: /etc/nfs.conf. This is a INI-style config file, see the nfs.conf(5) manpage for details. Furthermore, there is a /etc/nfs.conf.d directory which can hold *.conf snippets that can override settings from previous snippets or from the nfs.conf main config file itself.

There is a new command-line tool called nfsconf(8) which can be used to query or even set configuration parameters in nfs.conf. In particular, it has a --dump parameter which will show the effective configuration including all changes done by /etc/nfs.conf.d/*.conf snippets.

For Ubuntu Server 20.04 LTS (“focal”) and earlier

Earlier Ubuntu releases use the traditional configuration mechanism for the NFS services via /etc/defaults/ configuration files. These are /etc/default/nfs-common and /etc/default/nfs/kernel-server, and are used basically to adjust the command-line options given to each daemon.

Each file has a small explanation about the available settings.

Warning

The NEED_* parameters have no effect on systemd-based installations, like Ubuntu 20.04 LTS (“focal”) and Ubuntu 18.04 LTS (“bionic”).
In those systems, to control whether a service should be running or not, use systemctl enable or systemctl disable, respectively.

Upgrading to Ubuntu 22.04 LTS (“jammy”)

The main change to the NFS packages in Ubuntu 22.04 LTS (“jammy”) is the configuration file. Instead of multiple files sourced by startup scripts from /etc/default/nfs-*, now there is one main configuration file in /etc/nfs.conf, with an INI-style syntax.
When upgrading to Ubuntu 22.04 LTS (“jammy”) from a release that still uses the /etc/defaults/nfs-* configuration files, the following will happen:

• a default /etc/nfs.conf configuration file will be installed
• if the /etc/default/nfs-* files have been modified, a conversion script will be run and it will create /etc/nfs.conf.d/local.conf with the local modifications.

If this conversion script fails, then the package installation will fail. This can happen if the /etc/default/nfs-* files have an option that the conversion script wasn’t prepared to handle, or a syntax error for example. In such cases, please file a bug using this link: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+filebug

You can run the conversion tool manually to gather more information about the error: it’s in /usr/share/nfs-common/nfsconvert.py and must be run as root.

If all goes well, as it should in most cases, the system will have /etc/nfs.conf with the defaults, and /etc/nfs.conf.d/local.conf with the changes. You can merge these two together manually, and then delete local.conf, or leave it as is. Just keep in mind that /etc/nfs.conf is not the whole story: always inspect /etc/nfs.conf.d as well, as it may contain files overriding the defaults.

You can always run nfsconf --dump to check the final settings, as it merges together all configuration files and shows the resulting non-default settings.

Restarting NFS services

Since NFS is comprised of several individual services, it can be difficult to determine what to restart after a certain configuration change.

The tables below summarize all available services, which “meta” service they are linked to, and which configuration file each service uses.

For example, systemctl restart nfs-server.service will restart nfs-mountd, nfs-idmapd and rpc-svcgssd (if running). On the other hand, restarting nfs-utils.service will restart nfs-blkmap, rpc-gssd, rpc-statd and rpc-svcgssd.

Of course, each service can still be individually restarted with the usual systemctl restart <service>.

The nfs.systemd(7) manpage has more details on the several systemd units available with the NFS packages.

NFSv4 with Kerberos

Kerberos with NFS adds an extra layer of security on top of NFS. It can be just a stronger authentication mechanism, or it can also be used to sign and encrypt the NFS traffic.

This section will assume you already have setup a Kerberos server, with a running KDC and admin services. Setting that up is explained elsewhere in the Ubuntu Server Guide.

NFS server (using kerberos)

The NFS server will have the usual nfs-kernel-server package and its dependencies, but we will also have to install kerberos packages. The kerberos packages are not strictly necessary, as the necessary keys can be copied over from the KDC, but it makes things much easier.

For this example, we will use:

• .vms DNS domain
• VMS Kerberos realm
• j-nfs-server.vms for the NFS server
• j-nfs-client.vms for the NFS client
• ubuntu/admin principal has admin privileges on the KDC

Adjust these names according to your setup.

First, install the krb5-user package:

sudo apt install krb5-user

Then, with an admin principal, let’s create a key for the NFS server:

$ sudo kadmin -p ubuntu/admin -q "addprinc -randkey nfs/j-nfs-server.vms"

And extract the key into the local keytab:

$ sudo kadmin -p ubuntu/admin -q "ktadd nfs/j-nfs-server.vms"
Authenticating as principal ubuntu/admin with password.
Password for ubuntu/admin@VMS:
Entry for principal nfs/j-nfs-server.vms with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal nfs/j-nfs-server.vms with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.

Confirm the key is available:

$ sudo klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 nfs/j-nfs-server.vms@VMS
   2 nfs/j-nfs-server.vms@VMS

Now install the NFS server:

$ sudo apt install nfs-kernel-server

This will already automatically start the kerberos-related nfs services, because of the presence of /etc/krb5.keytab.

Now populate /etc/exports, restricting the exports to krb5 authentication. For example, exporting /storage using krb5p:

/storage *(rw,sync,no_subtree_check,sec=krb5p)

Refresh the exports:

$ sudo exportfs -rav
exporting *:/storage

The security options are explained in the exports(5) manpage, but generally they are:

• krb5: use kerberos for authentication only (non-auth traffic is in clear text)
• krb5i: use kerberos for authentication and integrity checks (non-auth traffic is in clear text)
• krb5p: use kerberos for authentication, integrity and privacy protection (non-auth traffic is encrypted)

NFS client (using kerberos)

The NFS client has a similar set of steps. First we will prepare the client’s keytab, so that when we install the NFS client package it will start the extra kerberos services automatically just by detecting the presence of the keytab:

sudo apt install krb5-user

To allow the root user to mount NFS shares via kerberos without a password, we have to create a host key for the NFS client:

sudo kadmin -p ubuntu/admin -q "addprinc -randkey host/j-nfs-client.vms"

And extract it:

$ sudo kadmin -p ubuntu/admin -q "ktadd host/j-nfs-client.vms"

Now install the NFS client package:

$ sudo apt install nfs-common

And you should be able to do your first NFS kerberos mount:

$ sudo mount j-nfs-server:/storage /mnt

If you are using a machine credential, then the above mount will work without having a kerberos ticket, i.e., klist will show no tickets:

# mount j-nfs-server:/storage /mnt
# ls -l /mnt/*
-rw-r--r-- 1 root root 0 Apr  5 14:50 /mnt/hello-from-nfs-server.txt
# klist
klist: No credentials cache found (filename: /tmp/krb5cc_0)

Notice the above was done with root. Let’s try accessing that existing mount with the ubuntu user, without acquiring a kerberos ticket:

# sudo -u ubuntu -i
$ ls -l /mnt/*
ls: cannot access '/mnt/*': Permission denied

The ubuntu user will only be able to access that mount if they have a kerberos ticket:

$ kinit
Password for ubuntu@VMS: 
$ ls -l /mnt/*
-rw-r--r-- 1 root root 0 Apr  5 14:50 /mnt/hello-from-nfs-server.txt

And now we have not only the TGT, but also a ticket for the NFS service:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: ubuntu@VMS

Valid starting     Expires            Service principal
04/05/22 17:48:50  04/06/22 03:48:50  krbtgt/VMS@VMS
        renew until 04/06/22 17:48:48
04/05/22 17:48:52  04/06/22 03:48:50  nfs/j-nfs-server.vms@
        renew until 04/06/22 17:48:48
        Ticket server: nfs/j-nfs-server.vms@VMS

One drawback of using a machine credential for mounts done by the root user is that you need a persistent secret (the /etc/krb5.keytab file) in the filesystem. Some sites may not allow such a persistent secret to be stored in the filesystem. An alternative is to use rpc.gssds -n option. From rpc.gssd(8):

• -n: when specified, UID 0 is forced to obtain user credentials which are used instead of the local system’s machine credentials.

When this option is enabled and rpc.gssd restarted, then even the root user will need to obtain a kerberos ticket to perform an NFS kerberos mount.

Warning

Note that this prevents automatic NFS mounts via /etc/fstab, unless a kerberos ticket is obtained before.

In Ubuntu 22.04 LTS (“jammy”), this option is controlled in /etc/nfs.conf in the [gssd] section:

[gssd]
use-machine-creds=0

In older Ubuntu releases, the command line options for the rpc.gssd daemon are not exposed in /etc/default/nfs-common, therefore a systemd override file needs to be created. You can either run:

$ sudo systemctl edit rpc-gssd.service

And paste the following into the editor that will open:

[Service]
ExecStart=
ExecStart=/usr/sbin/rpc.gssd $GSSDARGS -n

Or manually create the file /etc/systemd/system/rpc-gssd.service.d/override.conf and any needed directories up to it, with the contents above.

After you restart the service with systemctl restart rpc-gssd.service, the root user won’t be able to mount the NFS kerberos share without obtaining a ticket first.

References

Linux NFS wiki
Linux NFS faq

Ubuntu Wiki NFS Howto
Ubuntu Wiki NFSv4 Howto

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

В этом материале мы рассмотрим, как провести настройку монтажа NFS на машине с Ubuntu 20.04.

Предварительные требования

В нашем примере используем пару серверов. С одного из них будем «транслировать» файловую систему на второй. Чтобы ускорить подготовку, арендуем пару виртуальных машин у провайдера Timeweb Cloud. Это позволит акцентировать внимание на функциях NFS.

Требования к ним:

1. Предустановленная Ubuntu 20.04.
2. Аккаунт без прав root и привилегиями sudo.
3. Настроенный брандмауэр UFW.

В статье будем использовать название «хост» для сервера, предоставляющего доступ к файловой системе, а «клиент» для того, куда будут смонтированы «внешние папки». Сразу выясните IP-адреса обоих серверов, их на практике подставите вместо host_ip и client_ip, которые мы применим здесь в качестве примера.

Загрузим и инсталлируем компоненты

Процедуру проведем последовательно на каждом сервере, чтобы подготовить их к дальнейшей работе.

Хост

Инсталлируем пакет nfs-kernel-server, открывающий доступ к директориям, размещенным во «внутренней» файловой системе. 

sudo apt update
sudo apt install nfs-kernel-server

По завершении инсталляции перейдем на клиентский сервер.

Клиент

На машину-клиент инсталлируем пакет nfs-common, организующий доступ к сторонним каталогам без дополнительных компонентов. Здесь также сначала обновим список пакетов для обеспечения актуальности всех установленных модулей:

sudo apt update
sudo apt install nfs-common

Теперь обе системы готовы к дальнейшей настройке.

Создадим на хосте общие каталоги

В качестве примера организуем доступ к паре папок, но зададим им разные настройки. Этим мы покажем разные варианты настройки монтажа NFS с использованием суперпользователя. Последние выполняют любые операции внутри системы, только вот смонтированные каталоги – это внешние ресурсы, которые «откажутся» работать без отдельного разрешения. Так, независимо от прав на машине суперпользователю не получится записать данные от имени root.

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

Пример №1. Экспортируем ресурс общего назначения

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

Создадим общую папку для пользователя root с правами sudo:

sudo mkdir /var/nfs/general –p
ls -la /var/nfs/general

Результат видим на экране:

drwxr-xr-x 2 root root 4096 May 24 19:16

Система безопасности, заложенная в NFS на клиенте, преобразует команды, исходящие от root, в операции nobody:nogroup. Поэтому изменим владельца папки, чтобы соответствовать применяемым учетным данным:

sudo chown nobody:nogroup /var/nfs/general

Теперь система готовка к экспорту общего ресурса.

Пример №2

Рассмотрим второй пример, где сделаем домашние каталоги, расположенные на хосте и доступные с клиентских серверов, включая их администраторов. Экспортируем на хост каталог /home, с ним проще работать, потому что он уже существует и на нем настроены необходимые права. Методика та же, что и в предыдущем примере, только клиент и хост «меняются местами».

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

sudo nano /etc/exports

Синтаксис внутри него выглядит так:

directory_to_share    client(share_option1,...,share_optionN)

Создадим строку для каждой папки, которую планируем использовать в общем доступе. Вместо client_ip подставьте свой реальный IP:

/var/nfs/general    client_ip(rw,sync,no_subtree_check)
/home               client_ip(rw,sync,no_root_squash,no_subtree_check)

Опции, используемые в настройках:

• rw – открывает доступ на чтение-запись в указанном томе;
• sync – включает принудительную запись изменений на диске;
• no_subtree_check – отключает проверку вложенного дерева;
• no_root_squash – активирует преобразование запросов root в запросы без привилегий.

Последнее необходимо для блокировки доступа суперпользователя к ресурсам сервера, кроме папки для общего доступа (смонтированные каталоги NFS). Отметим, что после внесения изменений в файл конфигурации необходимо сохранить их при закрытии. Следом обязательно перезагрузите сервер:

sudo systemctl restart nfs-kernel-server

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

Настроим брандмауэр на хосте

Перед внесением настроек проверим текущий статус:

sudo ufw status

Это необходимо, чтобы убедиться в активности сервиса:

Status: active
To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

В нашем примере разрешено подключение только по протоколу SSH, поэтому требуется вручную внести новое правило. Применим следующую команду, что открыть порт 2049:

sudo ufw allow from client_ip to any port nfs

Повторно проверим статус UFW:

sudo ufw status

Теперь мы видим разрешение для SSH и порта 2049:

Status: active
To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                 
2049                       ALLOW       203.0.113.24        
OpenSSH (v6)               ALLOW       Anywhere (v6)

Создадим точки монтирования каталогов на клиенте

Как только хост будет настроен и способен обслуживать общие ресурсы, подготовим клиента. Для этого смонтируем папки, которые планируется расшарить, в клиентских пустых каталогах. Важно учитывать, что при подобном использовании NFS в Ubuntu содержимое директорий окажется недоступным (файлы и папки станут скрытыми).

Создадим две папки:

sudo mkdir -p /nfs/general
sudo mkdir -p /nfs/home

Смонтируем общие ресурсы при помощи IP хоста:

sudo mount host_ip:/var/nfs/general /nfs/general
sudo mount host_ip:/home /nfs/home

Приведенные команды подключат выделенные ресурсы хоста к клиентской системе. Проверим успешность процедуры монтирования:

df –h

Вывод на экран:

Filesystem                       Size  Used Avail Use% Mounted on
udev                             474M     0  474M   0% /dev
tmpfs                             99M  936K   98M   1% /run
/dev/vda1                         25G  1.8G   23G   8% /
tmpfs                            491M     0  491M   0% /dev/shm
tmpfs                            5.0M     0  5.0M   0% /run/lock
tmpfs                            491M     0  491M   0% /sys/fs/cgroup
/dev/vda15                       105M  3.9M  101M   4% /boot/efi
tmpfs                             99M     0   99M   0% /run/user/1000
10.132.212.247:/var/nfs/general   25G  1.8G   23G   8% /nfs/general
10.132.212.247:/home              25G  1.8G   23G   8% /nfs/home

Смонтированные ресурсы отображаются в самом низу. При помощи команды du посмотрим, какой объем занимает конкретная точка монтирования. К ней укажем прямой путь до каталога и опцию -s для отображения сводной информации, без детализации по каждому файлу. Если еще добавить опцию -h, то вывод будет представлен в более удобной для чтения форме:

du -sh /nfs/home

Результат:

36K /nfs/home

Каталог home первоначально занимает всего 36 Кбайт.

Протестируем доступ NFS

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

Пример №1

Произведем запись тестового файла в каталог /var/nfs/general:

sudo touch /nfs/general/general.test

Проверим права владельца:

ls -l /nfs/general/general.test

Результат на экране:

-rw-r--r-- 1 nobody nogroup 0 Aug  1 13:31 /nfs/general/general.test

Мы ранее меняли владельца root на nobody:nogroup, он и отображается. Суперпользователи не могут пользоваться общим ресурсом как администраторы. Например, у них не получится создать новую папку для группы аккаунтов или изменить владельца файла. 

Пример №2

Создадим по аналогичной схеме файл, но уже в общем каталоге /nfs/home:

sudo touch /nfs/home/home.test

Проверим его владельца:

ls -l /nfs/home/home.test

Результат на экране:

-rw-r--r-- 1 root root 0 Aug  1 13:32 /nfs/home/home.test

Мы здесь создали файл home.test с владельцем root по аналогии с ранее приведенным примером, где был создан general.test. Но в данном случае мы позволяем пользователям с доступом root на клиенте запускать операции без ограничений. Это удобно, т.к. не требуется отдельно открывать доступ root к системе хоста.

Монтируем удаленные каталоги NFS при запуске

Ресурсы, открытые для общего доступа, «отваливаются» после перезагрузки системы. Но ситуацию легко исправить – добавим команду в файл /etc/fstab, расположенный на клиенте. Сначала откроем редактор:

sudo nano /etc/fstab

Перейдем в конец файла и внесем по строке на каждый из организованных ресурсов:

. . .
host_ip:/var/nfs/general    /nfs/general   nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
host_ip:/home               /nfs/home      nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

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

man nfs

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

Отключим расшаренный доступ

Как только общий каталог перестал быть востребованным его лучше отключить:

cd ~
sudo umount /nfs/home
sudo umount /nfs/general

Система удалит удаленные ресурсы и сохранит локальные хранилища.

df -h

Результат на экране:

Filesystem                       Size  Used Avail Use% Mounted on
udev                             474M     0  474M   0% /dev
tmpfs                             99M  936K   98M   1% /run
/dev/vda1                         25G  1.8G   23G   8% /
tmpfs                            491M     0  491M   0% /dev/shm
tmpfs                            5.0M     0  5.0M   0% /run/lock
tmpfs                            491M     0  491M   0% /sys/fs/cgroup
/dev/vda15                       105M  3.9M  101M   4% /boot/efi
tmpfs                             99M     0   99M   0% /run/user/1000

Чтобы запретить повторное подключение после запуска, требуется внести изменения в /etc/fstab (удалить ранее внесенные строки или закомментировать их символом # вначале каждой). Работать с вручную смонтированными ресурсами можно без ограничений.

Выводы

В этом материале мы разобрались, как установить сервер NFS на Ubuntu 20.04, настроить его для расшаривания ресурсов или подключения к «внешним». Важно понимать, что протокол файловой системы не применяет шифрование, поэтому он не актуален для критических направлений вроде промышленных предприятий. Или одновременно организуют подключение по зашифрованному туннелю VPN.

Сетевая файловая система NFS или Network File System, это популярный протокол сетевой файловой системы, который позволяет пользователям подключать удаленные сетевые каталоги на своей машине и передавать файлы между серверами. Вы можете использовать дисковое пространство на другой машине для своих файлов и работать с файлами, расположенными на других серверах. По сути, это альтернатива общего доступа Windows для Linux, в отличие от Samba реализована на уровне ядра и работает более стабильно.

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

Немного теории

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

Перед тем как мы сможем работать с NFS, нам придется установить несколько программ. На машину, которая будет сервером нужно установить пакет nfs-kernel-server, с помощью которого будет выполнено открытие шары nfs в ubuntu 16.04. Для этого выполните:

sudo apt install nfs-kernel-server

Теперь давайте проверим правильно ли установился сервер. Сервис NFS слушает соединения как для TCP, так и для UDP на порту 2049. Посмотреть действительно ли сейчас используются эти порты можно командой:

rpcinfo -p | grep nfs

Также важно проверить поддерживается ли NFS на уровне ядра:

cat /proc/filesystems | grep nfs

Видим, что работает, но если нет, нужно вручную загрузить модуль ядра nfs:

modprobe nfs

Давайте еще добавим NFS в автозагрузку:

sudo systemctl enable nfs-server

На клиентском компьютере вам нужно установить пакет nfs-common, чтобы иметь возможность работать с этой файловой системой. Вам необязательно устанавливать компоненты сервера, достаточно будет только этого пакета:

sudo apt install nfs-common

Вот и все, дальше настройка NFS в Ubuntu.

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

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

sudo mkdir /var/nfs

Дальше нас интересует настройка ubuntu nfs server. Все общие папки и другие настройки nfs находятся в файле /etc/exports. Синтаксис записи папки такой:

адрес_папки клиент(опции)

Адрес папки — это та папка, которую нужно сделать доступной по сети. Клиент — ip адрес или адрес сети, из которой могут получить доступ к этой папке. А вот с опциями немного сложнее. Рассмотрим некоторые из них:

• rw — разрешить чтение и запись в этой папке;
• ro — разрешить только чтение;
• sync — отвечать на следующие запросы только тогда, когда данные будут сохранены на диск (по умолчанию);
• async — не блокировать подключения пока данные записываются на диск;
• secure — использовать для соединения только порты ниже 1024;
• insecure — использовать любые порты;
• nohide — не скрывать поддиректории при, открытии доступа к нескольким директориям;
• root_squash — подменять запросы от root на анонимные, используется по умолчанию;
• no_root_squash — не подменять запросы от root на анонимные;
• all_squash — превращать все запросы в анонимные;
• subtree_check — проверять не пытается ли пользователь выйти за пределы экспортированной папки;
• no_subtree_check — отключить проверку обращения к экспортированной папке, улучшает производительность, но снижает безопасность, можно использовать когда экспортируется раздел диска;
• anonuid и anongid — указывает uid и gid для анонимного пользователя.

Например, для нашей папки, если вы хотите разрешить к ней подключаться только с определённого IP адреса, эта строка может выглядеть вот так:

sudo vi /etc/exports

/var/nfs 127.0.0.1(rw,sync,no_subtree_check)


Можно разрешить только нужную подсеть, например:

/var/nfs 192.168.0.0/24(rw,sync,no_subtree_check)

Для того чтобы разрешить все адреса используйте подсеть 0.0.0.0/0 или символ *.

Открытие шары NFS в Ubuntu почти завершено. Осталось разобраться с правами. Кроме ограничений IP адреса работает обычная система полномочий UNIX, поэтому если вы хотите чтобы определённый пользователь мог получить доступ к папке, то на сервере должен существовать пользователь с таким же UID и эта папка должна принадлежать ему или группе в которой он состоит.

Кроме того, обратите внимание на то, что все подключения от имени пользователя root считаются по умолчанию анонимными (nfsnobody), чтобы это отключить добавьте опцию монтирования no_root_squash, но это не безопасно, потому что любой root пользователь сможет получить доступ на запись ко всем файлам. Теперь попытаемся настроем клиента и попытаемся ее примонтировать.

Для того чтобы все пользователи могли получить доступ ко всем файлам можно создать пользователя с UID 1001 и попросить NFS все запросы считать запросами от анонимного пользователя, а анонимному пользователю присвоить UID 1001. Это делается такими опциями:

/var/nfs 127.0.0.1(rw,sync,all_squash,root_squash,anonuid=1001,anongid=1001)

Когда все будет настроено, останется только обновить таблицу экспорта NFS:

sudo exportfs -a

Если на вашем сервере используется брандмауэр, то следует открыть порты 111 и 2049:

sudo ufw allow 111
sudo ufw allow 2049

Подключение NFS

Мы не будем подробно останавливаться на этом вопросе в сегодняшней статье. Это довольно большая тема, заслуживающая отдельной статьи. Но пару слов я все же скажу. Чтобы подключить сетевую папку вам не нужен никакой nfs клиент ubuntu, достаточно использовать команду mount:

 sudo mount 127.0.0.1:/var/nfs/ /mnt/

Теперь вы можете попытаться создать файл в подключенной директории:

touch /mnt/test

Также мы посмотрите подключенные файловые системы с помощью df:

df -h

127.0.0.1:/var/nfs 30G 6,7G 22G 24% /mnt

Чтобы отключить эту файловую систему достаточно использовать стандартный umount:

sudo umount /mnt/

Выводы

В этой статье была рассмотрена настройка NFS в Ubuntu 20.04, как видите, все делается очень просто и прозрачно. Подключение NFS шары выполняется в несколько кликов, с помощью стандартных команд, а открытие шары NFS ненамного сложнее подключения. Если у вас остались вопросы, пишите в комментариях!

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

NFS(Network File System) –это сетевая файловая система, позволяющая пользователям обращаться к файлам и каталогам, расположенным на удалённых компьютерах, как если бы эти файлы и каталоги были локальными. Главным преимуществом такой системы является то, что отдельно взятые рабочие станции могут использовать меньше собственного дискового пространства, так как совместно используемые данные хранятся на отдельной машине и доступны для других машин в сети. NFS – это клиент-серверное приложение. Т.е. в системе пользователя должен быть установлен NFS-клиент, а на компьютерах, которые предоставляют свое дисковое пространство – NFS-сервер.

Установка

sudo apt-get install nfs-kernel-server nfs-common

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

sudo nano /etc/exports

/data 192.168.1.1/255.255.255.0(rw,insecure,nohide,all_squash,anonuid=1000,anongid=1000,no_subtree_check)

id <имя_пользвателя>

sudo /etc/init.d/nfs-kernel-server restart

sudo exportfs -a

Настройка клиента

mkdir ~/Общедоступная

Монтирование вручную

sudo mount -t nfs -O uid=1000,iocharset=utf-8 192.168.1.2:/data ~/Общедоступные

Монтирование с записью в fstab

sudo mkdir /media/Общедоступные

192.168.1.1:/data /media/Общедоступные nfs user,rw,noauto 0 0

Проблемы

Использование на ноутбуке

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

Монтирование с помощью autofs

cd /nfs/server/

Установка

sudo apt-get install autofs

Настройка

/nfs /etc/auto.nfs --timeout=60

sudo touch /etc/auto.nfs && sudo mkdir /nfs

server  -rw,soft,intr,rsize=8192,wsize=8192 192.168.1.2:/path_to_share

sudo service autofs restart

Проблемы

Недоступность удаленного сервера

MOUNT_WAIT=10

NEGATIVE_TIMEOUT=10

Использование

Проблемы

Проблемы с гибернацией или выключением

Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0)

dmesg | grep -A 2 refuse
[32467.560058] Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0):
[32467.560115] nfs D 0000000000000000 0 2065 1 0x00800004

dmesg | grep -A 2 refuse
[32467.560058] Freezing of tasks failed after 20.00 seconds (1 tasks refusing to freeze):
[32467.560115] updatedb.mloc D ffff88008e907578 0 9268 9261 0x00800004

Причина №1: пакет NFS

 sudo mv /usr/lib/pm-utils/sleep.d/55NetworkManager /usr/libg/pm-utils/sleep.d/old.55NetworkManager

Причина №2: пакет updatedb.mloc

wget http://ftp.ru.debian.org/debian/pool/main/m/mlocate/mlocate_0.23.1-1_i386.deb
sudo dpkg -i mlocate*

Ссылки