Сетевое хранилище: NFS против SMB для Linux-сервера

MAATRIX

Настраиваете общий доступ к файлам с Linux-сервера и не можете решить, поднимать NFS или Samba — вопрос звучит просто, но ответ зависит не от протокола, а от того, кто именно будет подключаться к хранилищу. Разбираем оба варианта на конкретных сценариях, чтобы вы выбрали один раз и не переделывали через месяц.

Два протокола — два разных мира по умолчанию

NFS (Network File System) родился в экосистеме Unix и остаётся протоколом «для своих»: минимум накладных расходов, прямая работа с правами POSIX (владелец, группа, rwx), простое монтирование — удалённая директория выглядит на клиенте как локальная. Его естественная среда — сервер и клиенты на Linux или другом Unix-подобном слое.

SMB/CIFS (Server Message Block) — протокол из мира Windows, но на Linux он полностью рабочий благодаря Samba: зрелому проекту, реализующему и SMB-сервер, и клиент, включая интеграцию с доменной аутентификацией. Ключевая причина держать SMB в уме на Linux-сервере — не «SMB лучше», а то, что Windows говорит по SMB из коробки, без единой дополнительной настройки на стороне клиента.

Отсюда и вся логика выбора: чисто Linux/Unix-сеть — почти всегда более простой и лёгкий путь через NFS. Если хотя бы часть клиентов — Windows-станции, которым нужен доступ к тому же хранилищу, — SMB снимает головную боль с установки клиентского ПО на каждой из них.

Когда NFS — очевидный выбор

Сценарий «сервер А монтирует хранилище с сервера Б, оба на Linux» — классика NFS:

• общее хранилище для узлов кластера (см. общее хранилище для кластера, если нужен разбор именно этого случая);
• архивное хранилище, куда несколько Linux-серверов пишут бэкапы по расписанию;
• домашние директории пользователей в связке с NIS/LDAP, где права POSIX должны совпадать один в один;
• хранилище для контейнеров и виртуалок с большим числом мелких файлов, где важна предсказуемая задержка.

Минимальная настройка на Ubuntu/Debian:

apt update && apt install -y nfs-kernel-server
mkdir -p /srv/nfs/share
chown nobody:nogroup /srv/nfs/share

/etc/exports:

/srv/nfs/share  10.0.0.0/24(rw,sync,no_subtree_check,root_squash)

exportfs -ra
systemctl enable --now nfs-kernel-server

На клиенте (тоже Linux):

apt install -y nfs-common
mount -t nfs4 10.0.0.10:/srv/nfs/share /mnt/data

/etc/fstab:

10.0.0.10:/srv/nfs/share  /mnt/data  nfs4  defaults,_netdev,noatime  0  0

root_squash — не формальность: без него root на клиенте получает root-доступ к файлам на сервере. no_subtree_check убирает лишние проверки при экспорте поддиректории, а не всего раздела.

Когда SMB предпочтителен

Смешанная сеть небольшого офиса — сервер на Linux, а на столах сотрудников Windows — ровно тот случай, где NFS создаёт больше проблем, чем решает. Windows не монтирует NFS-шары без отдельного компонента (клиент NFS входит не во все редакции и требует включения через «Компоненты Windows»), тогда как сетевой диск по SMB подключается через «Подключить сетевой диск» за 20 секунд без администраторских прав.

Типичные сценарии SMB на Linux-сервере:

• общая папка «Документы», «Общий диск» для сотрудников на Windows-ноутбуках;
• файловый сервер, заменяющий физический Windows Server (см. миграцию Windows Server на Linux);
• резервное копирование рабочих станций Windows на Linux-сервер через сетевую шару;
• общий доступ к файлам для смешанного парка устройств, включая macOS — там SMB тоже родной протокол сетевых шар.

Минимальная настройка Samba на Debian/Ubuntu:

apt update && apt install -y samba
mkdir -p /srv/samba/share
chown -R nobody:nogroup /srv/samba/share
chmod 2775 /srv/samba/share

Блок в /etc/samba/smb.conf:

[share]
   path = /srv/samba/share
   browseable = yes
   writable = yes
   guest ok = no
   valid users = @office
   create mask = 0664
   directory mask = 2775

groupadd office
useradd -M -s /usr/sbin/nologin -G office ivan
smbpasswd -a ivan
testparm
systemctl enable --now smbd nmbd

Со стороны Windows подключение — через проводник: \\10.0.0.10\share, логин/пароль из smbpasswd. Дополнительное ПО на клиенте не требуется — это и есть главный практический аргумент в пользу SMB там, где в сети есть Windows.

Права доступа и аутентификация: где разница

Классическая NFS (v3 и NFSv4 без Kerberos) исторически строится на доверии клиенту: сервер верит UID/GID, которые присылает клиентская машина, и не проверяет, что пользователь с таким UID на клиенте — тот же человек, что на сервере. Удобно внутри доверенного периметра (приватная сеть, VPN, один администратор на все машины), но плохо подходит, если клиентов контролируете не вы: подделав UID, можно получить доступ к чужим файлам.

Современный NFSv4 умеет работать через Kerberos (sec=krb5, krb5i, krb5p) с полноценной аутентификацией и шифрованием — но это требует поднятого KDC и заметно усложняет настройку. На практике в частных сценариях (кластер, бэкап между своими машинами) чаще ограничиваются sec=sys и полагаются на сетевую изоляцию — фаервол, приватную подсеть, VPN — вместо аутентификации на уровне протокола.

SMB изначально проектировался для сети с недоверенными клиентами: аутентификация (логин/пароль или Active Directory через winbind/sssd) встроена в протокол с самого начала, и Samba эту модель полностью поддерживает без дополнительного «взрослого» режима — valid users и smbpasswd из предыдущего раздела уже дают проверку личности на уровне пользователя.

Производительность: честно, без придуманных цифр

Общее наблюдение большинства администраторов: при прочих равных (одна сеть, одно железо) NFS обычно даёт меньшую задержку, особенно на большом числе мелких операций — за счёт более простого дизайна и меньшего числа round-trip'ов. SMB устроен сложнее (больше состояния, блокировки файлов, oplocks/leases, поддержка Windows ACL), и это добавляет накладные расходы.

Конкретных цифр «на сколько процентов быстрее» намеренно не приводим — разница сильно зависит от версии протокола (SMB 3.x эффективнее старых SMB 1/2), настроек (multichannel в SMB3, sync/async в NFS) и профиля нагрузки. Нужна измеримая цифра — тестируйте на своём железе и своей нагрузке, а не берите число из чужой статьи.

Практический вывод: в чисто Linux-окружении NFS почти всегда выигрывает по простоте и накладным расходам — но выигрыш обычно не настолько велик, чтобы ради него городить смешанную инфраструктуру, если у вас уже исторически работает SMB.

Монтирование SMB с Linux-клиента и типичные грабли

Если Linux-клиенту нужно подключиться к Windows- или Samba-серверу (смешанная инфраструктура, часть серверов на Windows Server, часть на Linux), это тоже рабочий вариант через cifs-utils:

apt install -y cifs-utils
mkdir -p /mnt/winshare
mount -t cifs //10.0.0.20/share /mnt/winshare -o credentials=/etc/samba/creds-share,uid=1000,gid=1000,vers=3.0

Файл /etc/samba/creds-share (права 600, только root) хранит username=, password=, domain= — так пароль не светится в /etc/fstab и в выводе ps. Явное vers=3.0 — не косметика: SMB1 отключён на современных серверах по умолчанию (там были известные уязвимости), поэтому при ошибке согласования протокола сначала проверяйте версию.

Порты в фаерволе: NFS требует TCP/UDP 2049, плюс rpcbind на 111 и динамические порты для mountd/statd/lockd (их можно зафиксировать в /etc/nfs.conf). SMB проще — 445/tcp, опционально 139/tcp для старого NetBIOS-режима, который в большинстве сетей уже не нужен.

Частые грабли:

• NFS: сервер работает, клиент видит permission denied. Почти всегда несовпадение UID/GID между машинами — sec=sys не транслирует имена, только числовые ID. Решается синхронизацией UID вручную, LDAP/NIS или NFSv4 с idmapd.
• Samba видит папку, но Windows не может записать файл. Обычно create mask/directory mask слишком строгие, либо пользователь не входит в группу-владельца на уровне Unix-прав — SMB накладывается поверх обычных прав файловой системы, а не заменяет их.
• NFS-шара «подвисает» при недоступности сервера. Опция hard (по умолчанию) заставляет клиента ждать сервер бесконечно; для некритичных монтирований разумнее soft,timeo=30, учитывая риск потери данных при обрыве записи.
• Samba не видна в сетевом окружении Windows. Автообзор через NetBIOS часто блокируется современной Windows или изоляцией VLAN — надёжнее подключаться напрямую по IP (\\10.0.0.10\share).

Частые вопросы