Сценарий знаком многим. В офисе десяток компьютеров, на каждом - свои файлы. Иван редактирует договор на рабочей станции, Мария правит тот же документ у себя, через пару часов обе версии сталкиваются в совершенно несовместимом виде. История, повторяющаяся в любой организации, где нет централизованного хранилища. Решение придумано давно и называется сетевая файловая система. Именно NFS - Network File System - стала стандартом для такой задачи в мире Unix и Linux, и за три десятка лет существования так и не уступила пальму первенства более молодым конкурентам.
Что такое NFS и почему эта технология от Sun Microsystems остаётся фундаментом для обмена файлами в сетях Linux
NFS появился в 1984 году в недрах Sun Microsystems. Компания решала конкретную задачу - дать возможность пользователям рабочих станций работать с файлами, физически хранящимися на центральном сервере, так же просто, как с локальными. Идея сработала настолько хорошо, что протокол быстро вышел за пределы Sun и стал фактическим стандартом в Unix-мире. Сегодня NFS живёт уже в четвёртой версии и продолжает обновляться, хотя базовые принципы остались теми же.
Суть работы NFS изящно проста. На сервере публикуется (экспортируется) определённая директория. Клиент монтирует эту директорию в собственную файловую систему, и с этого момента все операции с файлами внутри выглядят обычными. Программы на клиенте даже не подозревают, что работают не с локальным диском, а с сетевым хранилищем. Открытие файла, его чтение, запись, удаление, переименование - всё это прозрачно перенаправляется по сети на сервер.
Основные применения такой схемы охватывают широчайший спектр задач. Централизованное хранение пользовательских домашних директорий, когда вход в любую рабочую станцию автоматически подтягивает файлы одного и того же пользователя. Общий репозиторий документов для рабочей группы с единой точкой резервного копирования. Раздача установочных файлов и образов систем в корпоративной сети. Разделяемое место для хранения логов от множества серверов. Архивное хранилище, куда ежедневно складываются резервные копии с разных машин.
Ubuntu 22.04 из коробки поставляется с полным набором компонентов для работы с NFS - и в роли сервера, и в роли клиента. Настройка занимает минуты, а не часы, как в былые времена. Практически все современные дистрибутивы Linux имеют пакеты NFS в своих репозиториях, причём с одинаковыми или очень близкими названиями утилит. Знание NFS - один из тех универсальных навыков системного администратора, которые не привязаны к конкретному дистрибутиву и работают везде, где есть Linux.
Подготовка сервера через SSH-подключение и установка пакетов NFS-сервера на Ubuntu
Работа начинается с подключения к серверу. Большинство серверных дистрибутивов Ubuntu управляются удалённо через SSH, и настройка NFS - не исключение.
ssh user@SERVER-IP
sudo su
Переключение в режим суперпользователя через sudo su - спорная практика, о которой стоит сказать отдельно. С одной стороны, это удобно - не нужно писать sudo перед каждой командой. С другой, долгая работа под root увеличивает риск катастрофической ошибки. Случайное rm с неправильным путём превращается в потерю данных, которую уже не отменишь. Альтернатива - сохранять привычку использовать sudo для каждой административной команды, что создаёт лишний барьер перед опасными действиями.
Перед установкой пакетов имеет смысл обновить списки из репозиториев. Свежая информация о версиях пакетов избавит от установки устаревших сборок с известными проблемами.
sudo apt update
Основной пакет для роли сервера называется nfs-kernel-server. Название прямо указывает на ключевую особенность - реализация NFS в Linux работает на уровне ядра, а не пользовательского пространства. Такой подход даёт максимальную производительность, поскольку файловые операции не требуют переключения контекста между ядром и приложением.
sudo apt install nfs-kernel-server
Установка тянет за собой несколько зависимостей - библиотеки поддержки RPC-протокола, утилиты командной строки, скрипты инициализации. Процесс занимает обычно меньше минуты на сервере с приличным каналом. После завершения служба автоматически запускается и настраивается на автозапуск при загрузке системы.
Проверка статуса службы - обязательный шаг. Никогда не стоит полагаться на предположение, что всё заработало правильно. Лучше убедиться явно.
sudo systemctl is-enabled nfs-server
sudo systemctl status nfs-server
Первая команда показывает, включён ли автозапуск службы при загрузке системы. Ответ enabled означает, что после перезагрузки сервера NFS поднимется сам. Вторая команда выдаёт развёрнутый статус - активна ли служба прямо сейчас, сколько времени она работает, какие процессы запущены, есть ли ошибки.
На Ubuntu 22.04 главный конфигурационный файл NFS находится в /etc/nfs.conf и содержит детальные настройки работы сервера. Дополнительные параметры живут в файлах /etc/default/nfs-*. Для базовой работы править их обычно не требуется - значения по умолчанию подобраны разумно.
По умолчанию современный NFS-сервер поддерживает сразу несколько версий протокола. Проверить это можно через виртуальный файл в procfs.
cat /proc/fs/nfsd/versions
-2 +3 +4 +4.1 +4.2
Знаки перед числами показывают статус каждой версии. Минус перед двойкой означает, что древняя вторая версия протокола отключена - и правильно, её уже не используют. Плюсы перед остальными номерами показывают, что поддерживаются NFSv3, NFSv4 базовая, NFSv4.1 и NFSv4.2. Клиенты могут подключаться по любой из этих версий, выбирая ту, которую поддерживают сами.
Создание общих директорий и настройка прав доступа для сетевых пользователей
Перед тем как что-то раздавать, нужно создать сами директории. В данном примере создаются две - одна для резервных копий, вторая для общих файлов рабочей группы.
sudo mkdir -p /srv/backups /mnt/shared
Выбор места для директорий не случаен. /srv - стандартный каталог для данных, предоставляемых сервером наружу. /mnt - точка монтирования временных и съёмных файловых систем, но часто используется и для разделов, отданных под общие ресурсы. В реальной работе можно выбирать любые пути, но следование традиционной структуре Linux упрощает понимание системы теми, кто будет её обслуживать после вас.
Настройка владельца и прав - один из самых тонких моментов в работе с NFS. Традиционная система прав Unix работает по числовым идентификаторам пользователей (UID) и групп (GID). Если на сервере пользователь ivan имеет UID 1001, а на клиенте тот же ivan - UID 1002, система запутается, и права будут работать непредсказуемо. Чтобы избежать этой головной боли, общие директории часто отдают специальному пользователю nobody и группе nogroup, которые существуют на всех Linux-системах с одинаковыми UID.
sudo chown -R nobody:nogroup /srv/backups /mnt/shared
sudo chmod 777 /srv/backups /mnt/shared
Права 777 выглядят пугающе для опытного администратора - полный доступ для всех. В контексте NFS это оправдано именно потому, что управление доступом происходит не через права файловой системы, а через конфигурацию экспорта. Кто имеет право монтировать директорию - тот и получает доступ к её содержимому. Неавторизованные клиенты просто не смогут добраться до файлов, поскольку NFS-сервер их не пустит.
Главная конфигурация NFS - файл /etc/exports. Это именно он определяет, какие директории доступны каким клиентам и с какими правами.
sudo nano /etc/exports
Внутри прописываются правила экспорта.
/srv/backups 192.168.5.100(rw,sync,no_subtree_check)
/mnt/shared 192.168.10.0/24(rw,sync,no_subtree_check)
Разбор синтаксиса проясняет логику работы. Слева указывается путь к экспортируемой директории на сервере. Справа через пробел - адрес клиента и параметры экспорта в скобках. Клиента можно задавать несколькими способами. Конкретный IP-адрес (как 192.168.5.100) даёт доступ только одному компьютеру. Сетевая маска в виде 192.168.10.0/24 разрешает подключения всей подсети с адресами от 192.168.10.0 до 192.168.10.255. Также поддерживаются имена хостов, подстановочные знаки вроде *.example.com и даже группы сетей.
Параметры в скобках тонко настраивают поведение. Флаг rw разрешает чтение и запись - без него клиент сможет только читать файлы. Параметр sync заставляет сервер подтверждать операции записи только после реального сохранения на диск. Это замедляет работу, но даёт гарантию целостности данных при сбое питания. Альтернатива async быстрее, но рискованнее - данные могут потеряться при внезапном отключении. No_subtree_check отключает проверку принадлежности файла поддереву экспорта, что устраняет проблемы с переименованием файлов и ускоряет работу на больших объёмах.
После редактирования /etc/exports изменения нужно применить. Команда exportfs делает именно это - перечитывает конфигурацию и активирует описанные правила.
sudo exportfs -a
Отсутствие сообщений об ошибках означает успех. Любые проблемы синтаксиса конфигурации exportfs сразу сообщает в stderr. Для полной уверенности имеет смысл рестартнуть службу.
sudo systemctl restart nfs-server
sudo systemctl status nfs-server
Проверить, что именно экспортируется и кому доступно, можно через ту же команду с флагом -v для подробного вывода.
sudo exportfs -v
В ответ приходит список всех активных экспортов с их параметрами. Это удобный способ быстро увидеть текущее состояние сервера без разбора конфигов.
Защита NFS-сервера через брандмауэр UFW и открытие нужных портов для конкретных клиентов
Работающий NFS-сервер сам по себе не обеспечивает безопасности. Без правил брандмауэра любой компьютер в сети, до которого есть сетевая доступность, может попытаться подключиться. Задачу защиты берёт на себя UFW - стандартный фронтенд к iptables в Ubuntu.
Логика правил должна соответствовать конфигурации exports. Директория отдаётся конкретному клиенту - значит, только этот клиент должен иметь возможность добраться до NFS-порта. Директория доступна целой подсети - значит, правило брандмауэра должно разрешать ту же подсеть.
sudo ufw allow from 192.168.5.100 to any port nfs
sudo ufw allow from 192.168.10.0/24 to any port nfs
Специальное имя nfs в последней части правила - удобный псевдоним для номера порта 2049, на котором работает NFS. Такая запись понятнее и безопаснее прямого указания числа - опечатка в имени вызовет ошибку, а опечатка в номере порта тихо откроет не тот порт.
Применение и проверка правил - стандартные действия.
sudo ufw reload
sudo ufw status
В выводе status должны быть видны добавленные правила. Каждое показывает источник, назначение и действие. Проверка наглядно демонстрирует, что сервер теперь отвечает на NFS-запросы только нужным клиентам, а всем остальным просто не виден.
Установка NFS-клиента на второй машине и первое монтирование общей директории
Клиентская часть настраивается проще серверной. Вход на клиентскую машину происходит как обычно.
ssh root@CLIENT-IP
Обновление пакетов перед установкой - тот же обязательный ритуал.
sudo apt update
Клиентский пакет называется nfs-common. Он содержит утилиты монтирования и поддержку протокола NFS на стороне клиента.
sudo apt install nfs-common
После установки клиент готов подключаться к любым NFS-серверам, к которым у него есть сетевой доступ. Никаких служб при этом не запускается в постоянном режиме - монтирование либо происходит разово через команду mount, либо автоматически через fstab.
Для монтирования нужна точка - пустая директория, в которую будет смонтирована удалённая файловая система. Классическое место для таких точек - внутри /mnt.
sudo mkdir -p /mnt/data
Само монтирование делается одной командой. Формат указания NFS-ресурса характерный - адрес сервера, двоеточие, путь к экспортированной директории.
sudo mount nfs_server_ip:/srv/backups /mnt/data
После выполнения команды файлы из удалённой директории становятся доступны через локальный путь /mnt/data так, словно они лежат прямо на жёстком диске клиента. Это одна из красивейших особенностей файловых систем в Unix - единое пространство имён, в которое можно смонтировать что угодно, оставаясь прозрачным для приложений.
Проверка результата делается стандартной командой df.
sudo df -h
В выводе среди локальных разделов появится строка с NFS-монтированием. Размер, занятое место, процент заполнения - всё отображается так же, как для обычных дисков. Приложения, работающие с файлами через /mnt/data, даже не узнают, что взаимодействуют с сетевым ресурсом.
Проверка работоспособности двусторонней связи через создание файла с клиента
Монтирование - только половина дела. Важно убедиться, что запись на общий ресурс действительно работает и что файлы, созданные клиентом, появляются на сервере.
echo "This file from client" > /mnt/data/write.txt
cat /mnt/data/write.txt
Первая команда создаёт простой текстовый файл с коротким содержимым. Вторая читает его обратно. Если обе операции прошли без ошибок - запись работает нормально. Теперь переходим на сервер и проверяем, что файл действительно появился там.
cat /srv/backups/write.txt
ls /srv/backups/
Если в выводе виден тот же текст и тот же файл в листинге директории - поздравляю, связка работает полностью. Клиент пишет, сервер принимает, файлы сразу становятся доступны обеим сторонам. Именно такое поведение и ждут от сетевой файловой системы.
На этом этапе стоит вспомнить про настройки владельца. Файл, записанный с клиента, будет на сервере принадлежать пользователю nobody, поскольку именно под этим пользователем NFS-сервер выполняет операции. Это нормально и ожидаемо для конфигурации с общим доступом. В более сложных настройках можно использовать механизмы idmapd для сопоставления пользователей между серверами и клиентами, но для базовых сценариев такая простая схема работает безупречно.
Автоматическое монтирование NFS-ресурса при загрузке системы через файл fstab
Ручное монтирование командой mount удобно для разовых задач, но непригодно для постоянной работы. После перезагрузки клиентской машины пришлось бы каждый раз вручную восстанавливать монтирование. Стандартное решение - прописать нужные точки в /etc/fstab, файл, который система читает при загрузке и автоматически монтирует всё указанное.
Перед правкой fstab сначала размонтируем ручное подключение, чтобы оно не мешало.
sudo umount /mnt/data
Открываем fstab в редакторе.
sudo nano /etc/fstab
Добавляем строку с описанием NFS-ресурса.
nfs_server_ip:/srv/backups /mnt/data nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
Разбор опций монтирования показывает, какой заряд знаний стоит за этой одной строкой.
- auto разрешает автоматическое монтирование при загрузке или по команде mount -a
- nofail предотвращает зависание загрузки системы если NFS-сервер временно недоступен
- noatime отключает обновление времени последнего доступа и снижает сетевую нагрузку
- nolock отключает блокировки файлов что важно при работе через некоторые сети
- intr разрешает прерывать операции ввода-вывода по сигналам что спасает от зависших процессов
- tcp заставляет использовать TCP вместо UDP для большей надёжности
- actimeo=1800 устанавливает время кэширования атрибутов в 1800 секунд
Два нуля в конце - параметры dump и fsck_pass. Для сетевых файловых систем они должны быть нулями, поскольку ни резервное копирование через dump, ни проверка через fsck для них не применяются.
Применение настроек без перезагрузки делается одной командой.
sudo mount -a
Эта команда монтирует все записи из fstab, которые ещё не смонтированы. Если конфигурация корректна, никаких сообщений не появится, а /mnt/data окажется смонтированной. Теперь можно проверять результат стандартным способом.
sudo df -h
В списке монтирований видна строка с NFS-ресурсом. После любой перезагрузки клиентской машины эта строка появится автоматически, без ручных действий.
Типичные проблемы с NFS и практические советы по их решению
Работа с NFS не всегда проходит гладко. Существует набор типичных сложностей, которые встречаются достаточно часто, чтобы о них знать заранее. Зависание клиентов при обрыве связи с сервером - классическая проблема, с которой сталкивался каждый, кто работал с NFS. Параметр intr в fstab как раз и служит противоядием - он позволяет прерывать зависшие операции сигналами.
Проблемы с правами на запись часто вызваны конфликтом идентификаторов пользователей между клиентом и сервером. Решение - либо унификация UID/GID на всех машинах через LDAP или NIS, либо использование общего пользователя nobody, как в приведённых примерах. Третий путь - настройка idmapd для маппинга пользователей, что сложнее, но даёт максимум гибкости.
Медленная работа часто связана с неоптимальными параметрами монтирования. Флаги rsize и wsize, задающие размер блоков чтения и записи, могут заметно влиять на производительность. Значения по умолчанию в современных NFS обычно адекватны, но на специфических нагрузках их подстройка даёт заметный выигрыш.
Безопасность - отдельная большая тема. Классический NFS не шифрует трафик, и любой, кто может перехватить пакеты в сети, увидит содержимое файлов. Для доверенных локальных сетей это приемлемо, для передачи конфиденциальных данных через публичные каналы категорически нет. Решения - тоннели через SSH или VPN, использование NFSv4 с Kerberos-аутентификацией и шифрованием, или вовсе отказ от NFS в пользу более защищённых протоколов.
Правильно настроенный NFS-сервер работает годами без единой проблемы. Такая надёжность объясняется зрелостью протокола, тщательной отладкой кода в ядре Linux и отсутствием сложной инфраструктуры. Никаких баз данных, никаких дополнительных служб, никаких плагинов. Просто сервер, файлы, клиенты и сеть. Элегантность, которая делает NFS одним из тех инструментов, где первое впечатление случайного пользователя о простоте обманчиво - за кажущейся тривиальностью скрываются десятилетия инженерной мысли и тысячи часов работы разработчиков ядра Linux. И именно эта проверенная временем надёжность делает NFS лучшим выбором, когда нужно просто и надолго организовать обмен файлами между машинами.
Канал сайта в Telegram
Канал сайта на YouTube