NFS (Network File System) решает классическую задачу администратора: отдать каталог с сервера так, чтобы на десятках машин он выглядел как обычная локальная папка. Домашние каталоги пользователей, общие сборочные артефакты, образы для гипервизоров - все это часто живет на одном NFS-сервере. В этом уроке разберем, как объявить экспорт через /etc/exports, чем NFSv4 отличается от NFSv3 по портам и архитектуре, как смонтировать ресурс на клиенте и автоматизировать монтирование, и почему idmapd и опции вроде root_squash напрямую влияют на безопасность.
Как это работает
NFS - это сетевая файловая система поверх RPC (Remote Procedure Call). Клиент не качает файл целиком, а отправляет на сервер удаленные вызовы: открой, прочитай блок со смещением, запиши, получи атрибуты. Ядро на обеих сторонах делает вид, что все локально, а трафик идет по сети.
Ключевая разница версий - в количестве сетевых служб. NFSv3 опирается на отдельные демоны и портовый брокер rpcbind (порт 111): сначала клиент спрашивает у rpcbind, на каком порту слушает mountd, потом отдельно работает блокировка через lockd/statd. Из-за разброса портов NFSv3 неудобен для файрвола. NFSv4 - современный стандарт по умолчанию в 2026 - собрал все в один протокол на TCP-порту 2049. Ему не нужны rpcbind, mountd и отдельный демон блокировок: монтирование, lock, ACL идут одним каналом. Поэтому для нового сервера открываете ровно один порт.
Еще одно отличие - модель имен. В NFSv3 владелец файла передается числовым UID/GID, и если на сервере пользователь maria имеет UID 1001, а на клиенте 1005, файлы окажутся чужими. NFSv4 умеет работать с именами вида user@domain, и сопоставлением занимается демон nfsidmap (служба idmapd, настройка в /etc/idmapd.conf). Важный нюанс 2026 года: при доступе через AUTH_SYS (обычный экспорт без Kerberos) современные ядра все равно гоняют числовые id, и idmapd реально включается в работу в основном с krb5. Несовпадение домена в idmapd.conf - классическая причина, когда все файлы видны как nobody:nobody.
Опции экспорта определяют права и режим записи. root_squash (по умолчанию) превращает удаленного root в анонимного пользователя - чтобы клиентский админ не стал админом на вашем сервере. sync заставляет сервер подтверждать запись только после реального сброса на диск (надежно, но медленнее), async быстрее, но рискует потерей данных при сбое.
Команды и примеры
Установка пакетов. Debian/Ubuntu:
Код: Выделить всё
apt install nfs-kernel-server # сервер
apt install nfs-common # клиентКод: Выделить всё
dnf install nfs-utils # и сервер, и клиент в одном пакетеКод: Выделить всё
/srv/share 192.168.10.0/24(rw,sync,root_squash)
/srv/ro 10.0.0.5(ro,sync) 10.0.0.6(ro,sync)
/export/home *.lab.local(rw,sync,no_subtree_check)Код: Выделить всё
exportfs -ra # перечитать /etc/exports
exportfs -v # показать активные экспорты
exportfs -u 192.168.10.0/24:/srv/share # снять конкретный экспортКод: Выделить всё
systemctl enable --now nfs-server # RHEL/Fedora
systemctl enable --now nfs-kernel-server # Debian/UbuntuКод: Выделить всё
showmount -e 192.168.10.1 # список экспортов (использует mountd, NFSv3-стиль)
nfsstat -m # какие точки уже примонтированы и с какой версиейКод: Выделить всё
mount -t nfs -o vers=4.2 192.168.10.1:/srv/share /mnt/shareКод: Выделить всё
192.168.10.1:/srv/share /mnt/share nfs vers=4.2,_netdev,rw,hard,intr 0 0Автомонтирование по требованию через autofs - монтирует при первом обращении и отмонтирует после простоя:
Код: Выделить всё
# /etc/auto.master
/mnt/auto /etc/auto.nfs --timeout=60
# /etc/auto.nfs
share -fstype=nfs4,rw 192.168.10.1:/srv/shareЧастые грабли
- Пробел перед скобкой в /etc/exports: запись 'host (rw)' экспортирует каталог хосту host с опциями по умолчанию, а опции rw отдает ВСЕМ. Пишите 'host(rw)' слитно.
- Все файлы показываются как nobody:nobody - почти всегда несовпадение домена idmapd на клиенте и сервере либо забытый nfsidmap. Проверьте Domain в /etc/idmapd.conf с обеих сторон.
- Открыли только порт 2049, а монтирование по NFSv3 не идет - v3 еще требует rpcbind (111) и mountd. Либо явно используйте vers=4, либо откройте порты v3.
- no_root_squash на боевом экспорте - дыра: root на клиенте становится root на сервере. Включайте только осознанно и для доверенных машин.
- Опция soft при записи может молча терять данные при таймауте. Для важных данных - hard.
- Забыли _netdev в fstab - на загрузке монтирование падает, потому что сети еще нет.
- subtree_check на современных ядрах считается ненадежным - явно ставьте no_subtree_check.
- На сервере создайте каталог: mkdir -p /srv/share и положите туда тестовый файл.
- Добавьте в /etc/exports строку с вашей клиентской подсетью, опциями rw,sync,root_squash,no_subtree_check.
- Примените: exportfs -ra и убедитесь через exportfs -v.
- С клиента проверьте видимость: showmount -e <ip_сервера>.
- Смонтируйте: mount -t nfs -o vers=4.2 <ip>:/srv/share /mnt/share и запишите файл.
- Проверьте через nfsstat -m, что используется именно NFSv4.2.
- Сделайте монтирование постоянным через /etc/fstab с _netdev и перезагрузитесь для проверки.
- На каком TCP-порту работает NFSv4 и какие службы он делает ненужными по сравнению с NFSv3?
- Что делает опция root_squash и чем она отличается от no_root_squash с точки зрения безопасности?
- В чем разница между sync и async при экспорте и какой риск несет async?
- Почему файлы на NFSv4-клиенте могут отображаться как nobody:nobody и где это чинится?
- Чем поведение клиента с опцией hard отличается от soft при недоступности сервера?
- Как добавить новый экспорт и применить его без перезапуска службы nfs-server?
