Установка и настройка NFS сервера и NFS клиента. Network File System (NFS) - сетевая файловая система

Когда речь идет о компьютерных сетях, зачастую можно услышать упоминание NFS. Что такое означает эта аббревиатура?

Это протокол распределенной файловой системы, первоначально разработанный компанией Sun Microsystems в 1984 году, позволяющий пользователю на клиентском компьютере получать доступ к файлам через сеть, подобно доступу к локальному хранилищу. NFS, как и многие другие протоколы, основывается на системе Open Network Computing Remote Procedure Call (ONC RPC).

Другими словами, что такое NFS? Это открытый стандарт, определенный в Request for Comments (RFC), позволяющий любому реализовать протокол.

Версии и вариации

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

NFS v2

Версия 2 первоначально работала только по протоколу User Datagram Protocol (UDP). Ее разработчики хотели сохранить серверную сторону без блокировки, реализованной за пределами основного протокола.

Интерфейс виртуальной файловой системы позволяет выполнять модульную реализацию, отраженную в простом протоколе. К февралю 1986 года были продемонстрированы решения для таких операционных систем, как System V release 2, DOS и VAX/VMS с использованием Eunice. NFS v2 позволял считывать только первые 2 ГБ файла из-за 32-разрядных ограничений.

NFS v3

Первое предложение по разработке NFS версии 3 в Sun Microsystems было озвучено вскоре после выпуска второго дистрибутива. Главной мотивацией была попытка смягчить проблему производительности синхронной записи. К июлю 1992 года практические доработки позволили решить многие недостатки NFS версии 2, оставив при этом лишь недостаточную поддержку файлов (64-разрядные размеры и смещения файлов).

  • поддержку 64-битных размеров и смещений файлов для обработки данных размером более 2 гигабайт (ГБ);
  • поддержку асинхронной записи на сервере для повышения производительности;
  • дополнительные атрибуты файлов во многих ответах, позволяющие избежать необходимости их повторного извлечения;
  • операцию READDIRPLUS для получения данных и атрибутов вместе с именами файлов при сканировании каталога;
  • многие другие улучшения.

Во время введения версии 3 поддержка TCP как протокола транспортного уровня начала увеличиваться. Использование TCP в качестве средства передачи данных, выполненного с использованием NFS через WAN, стало позволять передавать большие размеры файлов для просмотра и записи. Благодаря этому разработчики смогли преодолеть пределы ограничений в 8 КБ, налагаемые протоколом пользовательских дейтаграмм (UDP).

Что такое NFS v4?

Версия 4, разработанная под влиянием Эндрской файловой системы (AFS) и блока сообщений сервера (SMB, также называемая CIFS), включает в себя повышение производительности, обеспечивает лучшую безопасность и вводит протокол с соблюдением установленных условий.

Версия 4 стала первым дистрибутивом, разработанным в Целевой группе Internet Engineering Task Force (IETF) после того, как Sun Microsystems передала разработку протоколов сторонним специалистам.

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

Новейший протокол файловой системы - NFS 4.2 (RFC 7862) - был официально выпущен в ноябре 2016 года.

Другие расширения

С развитием стандарта появились и соответствующие инструменты для работы с ним. Так, WebNFS, расширение для версий 2 и 3, позволяет протоколу сетевого доступа к файловым системам легче интегрироваться в веб-браузеры и активировать работу через брандмауэры.

Различные протоколы сторонних групп стали также ассоциироваться с NFS. Из них наиболее известными выступают:

  • Network Lock Manager (NLM) с поддержкой протокола байтов (добавлен для поддержки API-блокировки файлов UNIX System V);
  • удаленной квоты (RQUOTAD), который позволяет пользователям NFS просматривать квоты на хранение данных на серверах NFS;
  • NFS через RDMA - адаптация NFS, которая использует дистанционный прямой доступ к памяти (RDMA) в качестве средства передачи;
  • NFS-Ganesha - сервер NFS, работающий в пользовательском пространстве и поддерживающий CephFS FSAL (уровень абстракции файловой системы) с использованием libcephfs.

Платформы

Network File System часто используется с операционными системами Unix (такими как Solaris, AIX, HP-UX), MacOS от Apple и Unix-подобными ОС (такими как Linux и FreeBSD).

Он также доступен для таких платформ, как Acorn RISC OS, OpenVMS, MS-DOS, Microsoft Windows, Novell NetWare и IBM AS/400.

Альтернативные протоколы удаленного доступа к файлам включают в себя блок сообщений сервера (SMB, также называемый CIFS), протокол передачи Apple (AFP), базовый протокол NetWare (NCP) и файловую систему сервера OS/400 (QFileSvr.400).

Это связано с требованиями NFS, которые ориентированы по большей части на Unix-подобные «оболочки».

При этом протоколы SMB и NetWare (NCP) применяются чаще, чем NFS, в системах под управлением Microsoft Windows. AFP наиболее широко распространен в платформах Apple Macintosh, а QFileSvr.400 наиболее часто встречается в OS/400.

Типичная реализация

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

  • Сервер реализует процессы Network File System, запущенные по умолчанию как nfsd, чтобы сделать свои данные общедоступными для клиентов. Администратор сервера определяет, как экспортировать имена и параметры каталогов, обычно используя файл конфигурации/etc/exports и команду exportfs.
  • Администрирование безопасности сервера гарантирует, что он сможет распознавать и утверждать проверенного клиента. Конфигурация его сети гарантирует, что соответствующие клиенты могут вести переговоры с ним через любую систему брандмауэра.
  • Клиентская машина запрашивает доступ к экспортированным данным, как правило, путем выдачи соответствующей команды. Она запрашивает сервер (rpcbind), который использует порт NFS, и впоследствии подключается к нему.
  • Если все происходит без ошибок, пользователи на клиентской машине смогут просматривать и взаимодействовать с установленными файловыми системами на сервере в пределах разрешенных параметров.

Следует обратить внимание и на то, что автоматизация процесса Network File System также может иметь место - возможно, с использованием etc/fstab и/или иных подобных средств.

Развитие на сегодняшний день

К 21-му столетию протоколы-конкуренты DFS и AFS не достигли какого-либо крупного коммерческого успеха по сравнению с Network File System. Компания IBM, которая ранее приобрела все коммерческие права на вышеуказанные технологии, безвозмездно передала большую часть исходного кода AFS сообществу свободных разработчиков программного обеспечения в 2000 году. Проект Open AFS существует и в наши дни. В начале 2005 года IBM объявила о завершении продаж AFS и DFS.

В свою очередь, в январе 2010 года компания Panasas предложила NFS v 4.1 на основе технологии, позволяющей улучшить возможности параллельного доступа к данным. Протокол Network File System v 4.1 определяет метод разделения метаданных файловой системы из местоположения определенных файлов. Таким образом, он выходит за рамки простого разделения имен/данных.

Что такое NFS этой версии на практике? Вышеуказанная особенность отличает его от традиционного протокола, который содержит имена файлов и их данных под одной привязкой к серверу. При реализации Network File System v 4.1 некоторые файлы могут распределяться между многоузловыми серверами, однако участие клиента в разделении метаданных и данных ограничено.

При реализации четвертого дистрибутива протокола NFS-сервер представляет собой набор серверных ресурсов или компонентов; предполагается, что они контролируются сервером метаданных.

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

N FS (Network File System ) в основном разработана для совместного использования файлов и папок между /Unix систем от компании Sun Microsystems в 1980 году . Она позволяет монтировать локальные файловые системы по сети и удаленных хостов, для взаимодействия с ними так, как будто они установлены локально на той же системе. С помощью NFS , мы можем настроить общий доступ к файлам между Unix в Linux системе и Linux для системы Unix .

Преимущества NFS

  1. NFS создает локальный доступ к удаленным файлам.
  2. Он использует стандартную архитектуру клиент /сервер для обмена файлами между всеми машинами на базе * NIX .
  3. С помощью NFS не нужно, чтобы обе машины работали на той же ОС .
  4. С помощью NFS мы можем настроить решение централизованного хранения .
  5. Пользователи получают свои данные независимо от их физического расположения.
  6. Автоматическое обновление для новых файлов.
  7. Более новая версия NFS поддерживает монтирование acl , pseudo под root.
  8. Может быть защищен брандмауэрами и Kerberos .

Услуги NFS

Cервис System V-launched . Серверный пакет NFS включает в себя три средства, входящие в состав пакетов portmap и nfs-Utils .

  1. portmap : отображает вызовы, сделанные из других машин к правильной службе RPC (не требуется с NFSv4 ).
  2. nfs : преобразует удаленные запросы общего доступа к файлам в запросы на локальной файловой системе.
  3. rpc.mountd : эта служба отвечает за монтирование и размонтирования файловых систем.

Важные файлы конфигурации для NFS

  1. /etc/exports : его основной конфигурационный файл NFS , все экспортируемые файлы и каталоги , которые определены в этом файле и на конечном сервере NFS .
  2. /etc/fstab : Для того, чтобы смонтировать каталог NFS на вашей системе без перезагрузок , нам нужно сделать запись в /etc/fstab .
  3. /etc/sysconfig/nfs : Конфигурационный файл NFS для управления, на котором порт RPC и другие услуги прослушивания .

Настройка и монтирование NFS на сервере Linux

Для настройки монтирования NFS , мы будем нуждаться по крайней мере, в двух машинах Linux /Unix . Вот в этом учебнике, мы будем использовать два сервера.

  1. Сервер NFS : nfsserver.example.ru с IP – 192.168.0.55
  2. Клиент NFS : nfsclient.example.ru с IP – 192.168.0.60

Установка сервера NFS и клиента NFS

Нам нужно установить пакеты NFS на нашем сервере NFS , а также на машине клиента NFS . Мы можем установить его с помощью “ ” (Red Hat Linux) и установочный пакет “apt-get ” (Debian и Ubuntu ).

# yum install nfs-utils nfs-utils-lib # yum install portmap (not required with NFSv4) # apt-get install nfs-utils nfs-utils-lib

Теперь запустите службы на обеих машинах.

# /etc/init.d/portmap start # /etc/init.d/nfs start # chkconfig --level 35 portmap on # chkconfig --level 35 nfs on

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

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

Сначала настроим сервер NFS .

Настройка каталога экспорта

# mkdir /nfsshare

Теперь нам нужно сделать запись в “/etc/exports ” и перезапустить службы, чтобы сделать наш каталог разделяемыми в сети.

# vi /etc/exports /nfsshare 192.168.0.60(rw,sync,no_root_squash)

В приведенном выше примере, есть каталог, в разделе / под названием “nfsshare “, в настоящее время совместно с клиентом IP “192.168.0.60 ” с привилегиями чтения и записи (RW ), вы можете также использовать имя хоста клиента вместо IP в приведенном выше примере.

Параметры NFS

Некоторые другие варианты мы можем использовать в файлы “/etc/exports ” для совместного использования файлов выглядит следующим образом.

  1. ro : С помощью этой опции мы можем предоставить доступ только для чтения к общим файлам, то есть клиент будет только в состоянии прочитать .
  2. rw : Эта опция позволяет клиент – серверу доступ для обоих для чтения и записи в пределах общего каталога.
  3. sync : Синхронизация подтверждает запросы к общему каталогу только после того, как изменения были совершены.
  4. no_subtree_check : Эта опция предотвращает проверку поддерева . Когда общий каталог является подкаталогом большей файловой системы, NFS выполняет сканирование каждой директории над ним, чтобы проверить свои разрешения и детали. Отключение проверки поддерева может повысить надежность NFS , но снижают безопасность .
  5. no_root_squash : Эта фраза позволяет root , подключиться к определенной папке.

Для большего количества вариантов с “/etc/exports “, рекомендуется прочитать страницы руководства для экспорта .

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

После настройки NFS -сервера, нам необходимо смонтировать этот общий каталог или раздел на клиентском сервере.

Монтирование общих каталогов на клиенте NFS

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

# showmount -e 192.168.0.55 Export list for 192.168.0.55: /nfsshare 192.168.0.60

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

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

# mount -t nfs 192.168.0.55:/nfsshare /mnt/nfsshare

Приведенная выше команда установит общий каталог в “/mnt/nfsshare ” на сервере клиента. Вы можете проверить его следующей командой.

# mount | grep nfs sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) 192.168.0.55:/nfsshare on /mnt type nfs (rw,addr=192.168.0.55)

Выше команда mount монтирует на NFS совместно используемый каталог на NFS клиента временно, чтобы смонтировать каталог NFS постоянно на вашей системе вне зависимости от перезагрузок, нам нужно сделать запись в “/etc/fstab “.

# vi /etc/fstab

Добавьте следующую новую строку, как показано ниже.

192.168.0.55:/nfsshare /mnt nfs defauls 0 0

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

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

На стороне сервера nfsserver

Мы создали новый текстовый файл с именем “nfstest.txt ” в этом общем каталоге.

# cat > /nfsshare/nfstest.txt This is a test file to test the working of NFS server setup.

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

Перейдите в общий каталог на сервере клиента и вы обнаружите общий файл без какого-либо ручного обновления или службы перезагрузки.

# ll /mnt/nfsshare total 4 -rw-r--r-- 1 root root 61 Sep 21 21:44 nfstest.txt root@nfsclient ~]# cat /mnt/nfsshare/nfstest.txt This is a test file to test the working of NFS server setup.

Удаление монтирования NFS

Если вы хотите размонтировать этот общий каталог с сервера после того, как вы закончите с обменом файлами, вы можете просто размонтировать этот конкретный каталог с помощью команды “umount “. Смотрите этот пример ниже.

Root@nfsclient ~]# umount /mnt/nfsshare

Вы можете видеть, что монтирование было удалено в файловой системе.

# df -h -F nfs

Вы увидите, что эти общие каталоги не доступны больше.

Важные команды для NFS

Некоторые более важные команды для NFS .

  1. showmount -e : Показывает доступные расшаренные объекты на локальном компьютере
  2. showmount -e : Список доступных расшаренных объектов на удаленном сервере
  3. showmount -d : Список всех поддиректорий
  4. exportfs -v : Отображает список расшаренных файлов и опций на сервере
  5. exportfs -a : Экспорт всех доступных объектов, перечисленных в /etc/exports , или имя
  6. exportfs -u : Реэкспорт всех доступных объектов, перечисленные в /etc/exports , или имя
  7. exportfs -r : Обновить список сервера после изменения /etc/exports

Это все про монтирование NFS на данный момент, если интересно, можете прочитать гид о том . Оставляйте свои

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

В роли сервера возьмем Ubuntu 12.04.
В качестве клиентов будем использовать и тестировать Centos и Winows 7.

Master server: 192.168.2.213 (Ubuntu)

Clients: 192.168.2.72 (Centos), 192.168.2.180 (Windows)

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

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

Root@ubuntu:~# apt-get install nfs-kernel-server

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

… Creating config file /etc/idmapd.conf with new version Creating config file /etc/default/nfs-common with new version …

В первом файле описан user (созданный при установке пакета) и group , для участия в mapping-e (идентификации пользователей).

Root@ubuntu:~# cat /etc/idmapd.conf Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs # set your own domain here, if id differs from FQDN minus hostname # Domain = localdomain Nobody-User = nobody Nobody-Group = nogroup

Как мы знаем, в Linux каждый файл принадлежит конкретному пользователю, у которого есть свой (UID,GID), но у Windows системах схема немного другая. И в связи с этим был придуман механизм mapping, который делает трансляцию разных пользователей с различных ОС в понятный для файловой системы Linux вид.
Второй файл нужен для настройки идентификации Kerberos и настройке нестандартного порта, на котором будет слушаться демон. Он пока нам не нужен. Об настройке Kerberos речь пойдет в следующей статье.

Root@ubuntu:~# cat /etc/default/nfs-common # If you do not set values for the NEED_ options, they will be attempted # autodetected; this should be sufficient for most people. Valid alternatives # for the NEED_ options are "yes" and "no". # Do you want to start the statd daemon? It is not needed for NFSv4. NEED_STATD= # Options for rpc.statd. # Should rpc.statd listen on a specific port? This is especially useful # when you have a port-based firewall. To use a fixed port, set this # this variable to a statd argument like: "--port 4000 --outgoing-port 4001". # For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS STATDOPTS= # Do you want to start the gssd daemon? It is required for Kerberos mounts. NEED_GSSD=

Теперь продолжим настройку.
Все директории для шаринга нужно прописывать в файле /etc/exports. Для начала создадим 2 папки в домашней директории и закинем в них файлы. Дерево каталогов и файлов для экспорта:

Root@ubuntu:~# tree /home/alex/ /home/alex/ ├── nfs_dir1 │ ├── file1_dir1 │ ├── file2_dir1 │ └── file3_dir1 ├── nfs_dir2 ├── file1_dir2 ├── file2_dir2 └── file3_dir2

Теперь нужно присвоит юзера и группу для этих каталогов (берем с файла /etc/idmapd.conf).

Root@ubuntu:~# chown –R nobody:nogroup nfs_dir1/ root@ubuntu:~# chown –R nobody:nogroup nfs_dir2/

Для начала сделаем экспорт директории nfs_dir1 для конкретного IP. Редактируем файл /etc/exprots.

Root@ubuntu:~# vim /etc/exports # Для конкретного хоста (Windows) /home/alex/nfs_dir1 192.168.2.180(rw,sync,all_squash,no_subtree_check,insecure) # Для любого хоста подсети /home/alex/nfs_dir2 192.168.2.0/24(rw,no_root_squash,sync,no_subtree_check)

Здесь наведен минимальный набор опций для корректной работы хранилища с ОС Windows.

  • /home/alex/nfs_dir1 – путь к папке, для которой раздается доступ;
  • 192.168.2.180 – IP-адрес, которому раздается доступ к папке(можно указать всю сеть, тогда запись примет вид 192.168.2.0/24)
  • (rw,sync,all_squash,no_subtree_check) – набор опций.

Популярные опции:

  • rw –чтение/запись(может принимать значение ro-только чтение);
  • no_root_squash – по умолчанию пользователь root на клиентской машине не будет иметь доступа к разделяемой директории сервера. Этой опцией мы снимаем это ограничение. В целях безопасности этого лучше не делать;
  • sync – синхронный режим доступа(может принимать обратное значение — async );
  • noaccess – запрещает доступ к указанной директории. Может быть полезной, если перед этим вы задали доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям.
  • all_squash – подразумевает, что все подключения будут выполнятся от анонимного пользователя (нужно для Windows клиента)
  • anonuid= 1000 – привязывает анонимного пользователя к «местному» пользователю;
  • anongid= 1000 – привязывает анонимного пользователя к группе «местного» пользователя.
  • no_subtree_check(subtree_check) –если экспортируется подкаталог файловой системы, но не вся файловая система, сервер проверяет, находится ли запрошенный файл в экспортированном подкаталоге. Отключение проверки уменьшает безопасность, но увеличивает скорость передачи данных.
  • Обычно, Linux (и другие Unix-подобные операционные системы) резервируют TCP и UDP порты от 1-1023 (так называемые безопасные порты) для использования процессами пользователя root. Чтобы удостовериться, что именно root инициировал удаленное подключение NFS, сервер NFS обычно требует, чтобы удаленные клиенты использовали безопасные порты. Это соглашение, однако, не соблюдается некоторыми операционными системами (например Windows). В таких случаях опция insecure позволяет клиенту NFS использовать любой порт TCP/UDP. Обычно она требуется при обслуживании клиентов Windows.

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

Root@ubuntu:~# exportfs –a

Теперь проверяем что у нас экспортировалось.

Root@ubuntu:~# exportfs -v /home/alex/nfs_dir1 192.168.2.180(rw,wdelay,all_squash,no_subtree_check,insecure) /home/alex/nfs_dir2 192.168.2.0/24(rw,wdelay,no_root_squash,no_subtree_check)

Сервер настроен.

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

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

Если не было сообщений об ошибке. Можно приступить к монтирование на клиентской стороне.
Для начала, нужно добавить сервис (службу-клиента) NFS. Для этого переходив в Пуск —> Панель управления —> Программы и компоненты и нажимаем на пункт меню слева Включение или отключение компонентов Windows . В появившимся окне выбираем Клиент для NFS и жмем ОК (рис. 1).


Рисунок 1

Далее нужно смонтировать диск. Для этого можно использовать командную строку или же просто щелкнуть правой кнопкой мыши на Мой компьютер и выбрать Подключение сетевого диска . И ввести строку \\192.168.2.213\home\alex\nfs_dir1 . Это IP сервера и путь к папке (рис. 2).


Рисунок 2

Если все ок, мы увидим диск (рис. 3).


Рисунок 3

То же можно проделать, используя командную строку (рис. 4).


Рисунок 4

Возможные ошибки:

Вы не сможете подключить сетевой NFS диск к Windows OS (рис. 5), если
1. Не установлен клиент NFS
2. Включен (не настроен) фаэрвол
3. Нет сетевого доступа к серверу
4. Неверно введены параметры монтирования
5. Не настроен (не применены настройки) экспорт на сервере.
6. Добавить опцию insecure в настройках экспорта


Рисунок 5 – Ошибка подключения сетевого NFS диска

Вы не сможете добавить файл в смонтированную файловую систему (рис. 6) , если:
1. На сервере не выставлены права на папку (nobody:nogroup)
2. Не выставлена опция all_squash в настройках экспорта
3. Не выставлена опция rw в настройках экспорта


Рисунок 6 – Ошибка при добавлении файла на NFS диска

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

Настройка линукс систем довольно проста и безболезненна. Нужно просто установить нужные пакеты и смонтировать диск. Для Centos нужны следующие пакеты

# yum install nfs-utils nfs-utils-lib

# mkdir -p /mnt/nfs # mount 192.168.2.213:/home/alex/nfs_dir1 /mnt/nfs # mount /dev/mapper/vg_slave-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0") /dev/sda1 on /boot type ext4 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) 192.168.2.213:/home/alex/nfs_dir1 on /mnt/nfs type nfs (rw,vers=4,addr=192.168.2.213,clientaddr=192.168.2.72)

В данном случае мы можем добавлять любой файл и директорию в смонтированную nfs_dir1 папку от имени любого пользователя системы (all_squash ). Но если мы смонтируем вторую папку nfs_dir2, то в нее может записывать ТОЛЬКО root, так как там стоит опция no_root_squash . Проверяем.

# mkdir /mnt/dir1 # mkdir /mnt/dir2 # mount 192.168.2.213:/home/alex/nfs_dir1 /mnt/dir1 # mount 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 или # mount -t nfs4 -o rw,hard,intr,bg 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 # echo "Hello" > /mnt/dir1/file1 # echo "Hello" > /mnt/dir2/file1 # su alex $ echo "Hello" > /mnt/dir1/file1 $ echo "Hello" > /mnt/dir2/file1 bash: /mnt/dir2/file1: Permission denied

Возможные флаги монтирования.

Флаг Описание
rw Монтирование файловой системы для чтения/записи (она должна экспортировать­ся сервером в режиме чтения/записи)
го Монтирование файловой системы только для чтения
bg Если смонтировать файловую систему не удается (сервер не отвечает), следует перевести операцию в фоновый режим и продолжить обработку других запросов на монтирование
hard Если сервер отключился, операции, которые пытаются получить к нему доступ, блокируются до тех пор, пока сервер не включится вновь
soft Если сервер отключился, операции, которые пытаются получить к нему доступ, завершаются выдачей сообщения об ошибке. Этот флаг полезно устанавливать для того, чтобы предотвратить зависание процессов в случае неудачного монтирова­ния не очень важных файловых систем
intr Позволяет прерывать с клавиатуры заблокированные операции (будут выдаваться сообщения об ошибке)
nointr Не позволяет прерывать с клавиатуры заблокированные операции
retrans=n Указывает, сколько раз нужно повторить запрос, прежде чем будет выдано со­общение об ошибке (для файловых систем, смонтированных с флагом soft)
timeo=n Задает интервал тайм-аута для запросов (в десятых долях секунды)
rsize=n Задает размер буфера чтения равным n байт
wsize=fl Задает размер буфера записи равным n байт
sec=режим Задает режим безопасности
vers=n Задает версию протокола NFS
proto = протокол Выбирает транспортный протокол; им должен быть протокол tcp для версии NVS 4

Так же можно проверить с консоли, правильно ли сервер экспортировал файловую систему.

Root@centos ~# showmount -e 192.168.2.213 Export list for 192.168.2.213: /home/alex/nfs_dir2 192.168.2.0/24 /home/alex/nfs_dir1 192.168.2.180

Добавляем монтирование в автозагрузку

# cat /etc/fstab ... 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 nfs4 rw,bg,intr,hard,nodev,nosuid 0 0

Root@centos ~# mount -a -t nfs4

Возможные ошибки.

Root@centos ~# mount -a -t nfs4 mount.nfs4: mount point /mnt/dir2 does not exist root@centos ~# mount -a -t nfs4 mount.nfs4: remote share not in "host:dir" format

В первом случаи нужно создать папку. Во втором — синтаксические ошибки в fstab.
Если возникли ошибки при монтировании NFS разделов – пройдитесь по списку Возможные ошибки из предыдущего раздела.
Для монтирования NFS разделов можно также использовать autofs. О чем пойдет речь в .

Вот , а что дальше? Как посмотреть фильмы и прослушать музыкальные файлы, которые скачались? Неужели нужно записывать их на диски и переносить их таким образом на компьютер с GUI? Или придётся копировать их по медленному SFTP? Нет! На помощь приходит NFS! Нет, это не серия гоночных игр, а Network File System (Сетевая Файловая Система).
Network File System (NFS) - это сетевая файловая система, позволяющая пользователям обращаться к файлам и каталогам, расположенным на удалённых компьютерах, как если бы эти файлы и каталоги были локальными. Главным преимуществом такой системы является то, что отдельно взятые рабочие станции могут использовать меньше собственного дискового пространства, так как совместно используемые данные хранятся на отдельной машине и доступны для других машин в сети. NFS — это клиент-серверное приложение. То есть в системе пользователя должен быть установлен NFS-клиент, а на компьютерах, которые предоставляют свое дисковое пространство - NFS-сервер.

Установка и настройка NFS-сервера (192.168.1.2)

1. Устанавливаем. Соединившись по SSH с компьютером сервером или же просто в его консоли вводим:

Sudo apt-get install nfs-kernel-server nfs-common portmap

Это установит NFS-сервер, а также необходимый пакет portmap.

2. Настраиваем. Для настройки списка дирректорий которые мы хотим открыть и списка кому мы хотим их открыть отредактируем файл /etc/exports :

Sudo nano /etc/exports /data 192.168.1.1/24(rw,no_root_squash,async)

В указанном выше примере мы открыли на сервере директорию /data и её поддиректории в совместное пользование всем компьютерам с IP: 192.168.1.1 - 192.168.1.255 с правами чтения и записи.

Ещё пример:

/home/serg/ 192.168.1.34(ro,async)

Этот пример делает доступной домашнюю директорию пользователя serg в режиме только чтение для компьютера с IP 192.168.1.34. Все остальные компьютеры сети к этой директории доступа иметь не будут.

Доступные опции:

  • ro — права только на чтение. Можно и не указывать, так как она установлена по умолчанию;
  • rw — дает клиентам право на запись;
  • no_root_squash — по-умолчанию пользователь root на клиентской машине не будет иметь доступа к открытым директориям на сервере. Этой опцией мы снимаем это ограничение. В целях безопасности этого лучше не делать;
  • noaccess — запрещает доступ к указанной директории. Может быть полезной, если перед этим вы задали доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям.

Теперь нужно перезапустить nfs-kernel-server:

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

Если после этого вы захотите поменять что-нибудь в файле /etc/exports , то для того, чтобы изменения вступили в силу, достаточно выполнить следующую команду:

Sudo exportfs -a

Всё. NFS-сервер установлен и настроен. Можно переходить к NFS клиенту.

Установка и настройка NFS-клиент

1. Установка. Выполняем в терминале компьютера, который будет подключаться следующее:

Sudo apt-get install portmap nfs-common

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

Cd ~ mkdir data

Монтировать можно двумя способами — каждый раз вручную или прописав опции монтирования в файл /etc/fstab .

Способ 1. Монтирование вручную
Создаём на рабочем столе или в какой-либо другой папке текстовый файл:

Nano ~/Рабочий\ стол/nfs-server-connect

Пишем в него:

#! /bin/bash sudo mount -t nfs -o ro,soft,intr 192.168.1.2:/data ~/data

Делаем его исполняемым:

Chmod +x ~/Рабочий\ стол/nfs-server-connect

Теперь когда необходимо присоединиться к серверу я выполняю этот сценарий в терминале для того чтобы можно было ввести пароль для sudo.

Способ 2. Добавление в /etc/fstab
Открываем /etc/fstab:

Sudo nano /etc/fstab

И дописываем строчку в конце файла:

192.168.1.2:/data ~/data nfs rw,hard,intr 0 0

Внимание! Вместо 192.168.1.2:/data впишите IP или имя сервера и путь к директории совместного пользования. Опции монтирования можно изменить.

Опция hard жёстко привязывает дирректорию на клиенте к серверу и если сервер отвалится, то может зависнуть и ваш компьютер. Опция soft , как понятно из её названия, не такая категоричная.

После сохранения файла можно монтировать удалённую папку.

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

NFS сервер

Так как у нас NFS - это сетевая файловая система, то необходимо . (Так же можно почитать статью ). Далее необходимо . В 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 в (то есть в файле /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:

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

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

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

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

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

Для большего понимания нижесказанного я бы посоветовал ознакомиться со статьей . Каждый пользователь 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

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 может производиться с помощью или с помощью одного из расплодившихся автоматических монтировщиков (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 - Данная опция запрещает исполнять программы из смонтированного каталога.
  • 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

Атрибуты файлов , хранящиеся в (индексных дескрипторах), такие как время модификации, размер, жесткие ссылки, владелец, обычно изменяются не часто для обычных файлов и еще реже - для каталогов. Многи программы, например 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)

Подобрать оптимальный 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
  • открыть порты в
    • для 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 должен быть владельцем разделённой директории:

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!