Сравнение протоколов файлового доступа SMB, NFS, AFP и WebDAV: выбор для смешанных сред Windows, Linux и macOS

Для смешанной среды, где в одной сети работают Windows, Linux и macOS, рабочая схема выбора такая: SMB 3.1.1 как основной протокол, NFSv4.1 или NFSv4.2 там, где преобладают Linux-клиенты и кластерные задачи, WebDAV для доступа через интернет и веб-интеграций. AFP из списка кандидатов на новые проекты выпадает: Apple перевела общий доступ к файлам на SMB ещё в OS X 10.9 Mavericks, а AFP-серверы остались ради обратной совместимости со старыми клиентами и старыми NAS.

Порядок решения практический. Сначала инвентаризация клиентов и версий их ОС, затем требования к аутентификации (Kerberos и Active Directory против локальных UID/GID), потом режим доступа (LAN, VPN, WAN) и профиль нагрузки: офисные документы, медиафайлы, бэкапы, диски виртуальных машин. Смена протокола на действующем хранилище обходится дороже, чем выбор на старте, потому что ACL, идентификаторы пользователей и семантика блокировок не переносятся один к одному.

Ключевые критерии выбора протокола файлового доступа

Сравнивать протоколы имеет смысл по восьми параметрам, и каждый из них может стать решающим.

• Парк клиентов. Windows, Linux, macOS, мобильные устройства, встраиваемые сканеры с SMB-загрузкой. Если в сети есть устройство, умеющее только SMB1, это отдельная проблема безопасности, а не повод включать SMB1 на сервере.
• Версии протокола и статус поддержки. SMB 3.1.1, NFSv4.2 и WebDAV по RFC 4918 развиваются, SMB1 и AFP 3.x заморожены.
• Аутентификация. Kerberos и LDAP дают единый вход для смешанного парка; NTLMv2 и AUTH_SYS работают локально, но не масштабируются на несколько площадок.
• Модель прав. Windows оперирует SID и ACL, Unix оперирует UID/GID и POSIX-битами. Для смешанной среды нужен маппинг идентичностей, иначе один и тот же файл будет доступен одному пользователю и закрыт другому.
• Блокировка файлов. От неё зависит, что произойдёт, когда два клиента из разных ОС откроют один документ.
• Пропускная способность и работа с большими файлами. Медиатека, образы дисков и бэкапы чувствительны к размеру блока, числу параллельных потоков и накладным расходам на файл.
• Сетевые требования. NFSv3 требует portmapper (111/tcp,udp), mountd, statd и lockd; NFSv4 и SMB обходятся предсказуемым набором портов, что упрощает правила firewall.
• Диагностика. Наличие утилит вроде smbstatus, nfsstat или curl с методом PROPFIND напрямую влияет на скорость разбора инцидентов.

Сводная таблица по этим критериям выглядит так.

Если хранилище проектируется вместе с блочным доступом, полезно сверить файловые протоколы с iSCSI и Fibre Channel по задержкам и стоимости: разбор протоколов доступа к СХД с примерами настройки target и initiator закрывает этот срез задачи.

SMB/CIFS: универсальный протокол для Windows и не только

SMB прошёл путь от SMB1 (он же CIFS) до SMB 3.1.1, и разница между версиями принципиальная. SMB1 в 2014 году признан Microsoft устаревшим, а начиная с Windows 10 версии 1709 и Windows Server версии 1709 он больше не устанавливается по умолчанию; в виртуальных машинах Windows Server, подготовленных Microsoft для Azure Marketplace, двоичные файлы SMB1 отсутствуют и включить его нельзя (SMBv1 не установлен по умолчанию в Windows). SMB 3.0 принёс сквозное шифрование данных SMB, SMB Multichannel и SMB Direct (RDMA) для высокоскоростного доступа с низкими задержками; SMB 3.1.1 добавил согласование криптоалгоритма на уровне соединения с AES-128-GCM по умолчанию (в Windows Server 2022 и Windows 11 доступны также AES-256-GCM и AES-256-CCM) и механизм preauthentication integrity, который защищает от понижения соединения с SMB 3.1.1 до SMB 2.x (SMB security enhancements). Важная оговорка: от понижения до SMB 1.0 эта защита не спасает, поэтому SMB1 нужно отключать отдельно. Для нового хранилища имеет смысл оставлять только SMB2 и SMB3, задавая минимальную версию явно, например параметром server min protocol = SMB2_10 в Samba.

Совместимость у SMB самая широкая из четырёх протоколов: Windows работает с ним нативно, macOS использует его как протокол общего доступа по умолчанию с 2013 года, Linux подключается через Samba и модуль cifs.ko. Аутентификация закрывает корпоративные требования: NTLMv2 для локальных учётных записей, Kerberos для домена Active Directory, LDAP для каталогов без домена. Производительность на 10GbE и выше упирается в дисковую подсистему, а не в протокол, и SMB Multichannel позволяет объединить несколько сетевых карт без LACP, а SMB Direct снимает нагрузку с CPU при копировании больших файлов (обзор общего доступа к файлам по протоколу SMB 3).

Слабые места SMB проявляются там, где смешиваются платформы. Клиент Windows активно кэширует данные и берёт oplock или lease, а Linux-клиент, обращающийся к тому же каталогу по NFS, о такой блокировке не узнает. Единая точка входа для всех клиентов по SMB снимает этот риск: macOS и Linux прекрасно работают с SMB-шарой.

Настройка SMB-сервера на Linux с аутентификацией Kerberos и LDAP

Сценарий: Ubuntu или Debian в домене Active Directory, пользователи входят по SSO, права берутся из AD. Порядок шагов следующий.

1. Синхронизация времени. Kerberos отклоняет запрос при расхождении часов больше допустимого окна (по умолчанию 5 минут). Настройте chrony или systemd-timesyncd и проверьте: timedatectl, chronyc tracking.
2. Файл /etc/krb5.conf. Укажите default_realm = EXAMPLE.COM, dns_lookup_kdc = true, dns_lookup_realm = true. Проверка: kinit Administrator@EXAMPLE.COM, затем klist должен показать выданный TGT.
3. Файл /etc/samba/smb.conf. Минимальный набор для домена: workgroup = EXAMPLE, realm = EXAMPLE.COM, security = ads, kerberos method = secrets and keytab, server min protocol = SMB2_10, а также map acl inherit = yes и vfs objects = acl_xattr, если ACL Windows должны храниться на файлах.
4. Маппинг идентичностей. Без него Linux не поймёт, кто такой доменный пользователь. Рабочий вариант: idmap config * : backend = tdb, idmap config * : range = 3000-7999, idmap config EXAMPLE : backend = ad, idmap config EXAMPLE : range = 10000-999999, а в /etc/nsswitch.conf для passwd и group добавьте winbind.
5. Ввод в домен. net ads join -k создаёт машинную учётную запись и keytab. Проверки: wbinfo -t (доверие домена), wbinfo -u (список пользователей), getent passwd user@example.com (работа nsswitch и winbind).
6. Проверка доступа к шаре. smbclient -L //fileserver -k покажет список ресурсов по Kerberos, smbclient //fileserver/data -k -c 'ls' проверит чтение каталога. Логи ищут в /var/log/samba/, конфигурацию валидируют через testparm -s.

Клиенты монтируют шару командой mount -t cifs //fileserver/data /mnt/data -o sec=krb5,vers=3.1.1,cruid=1000,multichannel (для Kerberos нужен действующий билет в ccache), а во fstab добавляют _netdev и x-systemd.automount, чтобы монтирование переживало перезагрузку. В macOS подключение выполняется через Finder и адрес smb://fileserver/data, билет Kerberos берётся из SSO при входе в домен. Состояние сессий и активные блокировки смотрят через smbstatus, сетевой обмен - через tcpdump по порту 445.

Отдельная ловушка вне домена: при работе Samba с OpenLDAP без AD сопоставление UID и GID приходится вести вручную через idmap_ldap. Если UID на сервере и на NFS- или SMB-клиентах расходятся, права на файлы «поедут» при первой же миграции данных.

NFS: производительность и простота для Linux/Unix

NFSv3 остаётся в эксплуатации из-за простоты, но у него есть структурные минусы: отсутствие состояния, отдельные службы portmapper, mountd, statd и lockd, а аутентификация по умолчанию AUTH_SYS, где клиент просто сообщает UID и GID и доверие строится на адресе клиента. Подделать такой запрос из доверенной подсети технически несложно, поэтому в корпоративной сети NFSv3 без Kerberos - компромисс.

NFSv4 решает большую часть этих задач: один порт 2049, встроенные блокировки и ACL, обязательная поддержка RPCSEC_GSS с уровнями krb5 (аутентификация), krb5i (целостность) и krb5p (шифрование трафика). Версия 4.2, описанная в RFC 7862, добавила server-side clone and copy, поддержку разреженных файлов (sparse files) и новый атрибут sec_label для хранения MAC-меток на файлах (labeled NFS), который клиент получает и использует для контроля доступа (RFC 7862: NFS Version 4 Minor Version 2). Совместимость: Linux и Unix работают с NFS нативно, macOS монтирует через mount_nfs или Finder по адресу nfs:// с опцией vers=4.2, а Windows требует включения компонента «Службы NFS» и доступен только в редакциях Pro, Enterprise и Education. В домене Windows маппинг идентичностей для NFS настраивается через ADLookup, вне домена чаще выбирают анонимный доступ с фиксированным UID, что почти всегда создаёт проблемы с правами.

Производительность NFS на локальной сети высокая, но конкретные значения размера блока и число параллельных соединений зависят от версии протокола, ядра и настроек монтирования - их стоит проверять по документации своей платформы, а не переносить из общих обзоров. Обратная сторона - чувствительность к задержкам: чем больше RTT, тем заметнее просадка на мелких операциях, поэтому WAN для NFS подходит плохо даже через VPN. Настройки root_squash и no_root_squash заслуживают отдельного контроля: второй вариант даёт root-доступ на экспорте и открывает хранилище для клиента с compromised-учёткой. Синхронизация UID/GID на сервере и клиентах критична, и решается она через LDAP или SSSD, а не через правку /etc/passwd на каждой машине.

Практические параметры монтирования, диагностика ошибок доступа и сравнение с SMB по правам и совместимости разобраны в материале NFS или SMB/CIFS: сравнение и выбор сетевого файлового протокола - это хорошая отправная точка перед выбором между двумя основными вариантами.

AFP: устаревший протокол для macOS - когда ещё используется

AFP (Apple Filing Protocol) был основным сетевым протоколом Apple до 2013 года, когда общий доступ в macOS переключили на SMB. Начиная с OS X 10.9 Mavericks Apple использует SMB2 вместо AFP как основной протокол удалённого доступа к файлам, а с macOS 11.0 Big Sur серверы AFP больше не поддерживаются (Apple Filing Protocol). С тех пор развитие AFP остановилось: Apple поддерживает клиентскую часть для доступа к старым хранилищам, серверную часть в актуальных системах не развивает, а сторонние NAS-платформы постепенно вычищают поддержку. На Linux AFP-сервер поднимают через Netatalk, и здесь важно отслеживать обновления безопасности: исторически у Netatalk находили критические уязвимости, а исправления выходят медленнее, чем у Samba.

Сильные стороны AFP исторически связаны с macOS: нативная поддержка resource forks, расширенных атрибутов и метаданных Finder, а также режим резервного копирования Time Machine. В SMB те же данные передаются через потоки и расширенные атрибуты, а совместимость обеспечивает модуль vfs_fruit в Samba с параметрами fruit:metadata=stream, fruit:resource=xattr и fruit:encoding=native. Проверять метаданные нужно после копирования: если параметры fruit заданы неверно, теги Finder и вложения почты теряются, а это выясняется уже на этапе восстановления из бэкапа.

Для Time Machine AFP больше не нужен: резервные копии по SMB работают, если на шаре включён соответствующий флаг (fruit:time machine = yes) и выделен отдельный датасет под спарс-бандлы. Практический план миграции: зафиксировать список клиентов с AFP, включить SMB на том же файловом сервере, перенести данные с сохранением прав и метаданных, дать период параллельной работы и только после этого отключить AFP-службу. Как выбирать саму платформу хранилища под такую миграцию, разобрано в руководстве как выбрать систему хранения данных: критерии сравнения и практический алгоритм.

WebDAV: файловый доступ через HTTP/HTTPS

WebDAV описан в RFC 4918 и работает поверх HTTP или HTTPS на портах 80 и 443. Класс 1 совместимости покрывает чтение свойств (PROPFIND), класс 2 добавляет блокировки (LOCK и UNLOCK). Помимо обычных GET и PUT, протокол умеет создавать коллекции (MKCOL), копировать и перемещать ресурсы (COPY, MOVE) и править метаданные (PROPPATCH). Такая модель даёт главное преимущество: трафик проходит через прокси, балансировщики и WAF, а доступ можно выдать пользователю из интернета без VPN.

Ограничения тоже конкретные. Накладные расходы HTTP и по одному запросу на файл делают WebDAV медленным на каталогах с тысячами мелких файлов, а мультиплексирования каналов, аналогичного SMB Multichannel, здесь нет. Клиент WebClient в Windows по умолчанию ограничивает размер передаваемого файла значением параметра FileSizeLimitInBytes, равным 50 000 000 байт (50 МБ), что важно учитывать при обмене большими документами (использование перенаправления WebDAV). Finder в macOS подключается к WebDAV из меню «Подключиться к серверу», но поведение записи зависит от версии системы, поэтому перед запуском в продакшн стоит проверить создание, переименование и сохранение файла именно на клиентских версиях. В Linux работают клиенты davfs2, cadaver и curl с методом PROPFIND.

Аутентификация в WebDAV варьируется: Basic допустим только под TLS, Digest устарел и слаб, Kerberos (Negotiate) настраивают на IIS и Apache через модули GSSAPI, OAuth обычно добавляют на уровне обратного прокси. Для публикации документов и синхронизации с веб-приложениями WebDAV уместен, а роль замены SMB или NFS в локальной сети он не выполняет. Если задача сводится к хранению файлов для веб-приложений, имеет смысл сравнить подход с объектным хранилищем: объектное, блочное и файловое хранилище: как выбрать и не ошибиться.

Настройка WebDAV-сервера на Nginx или Apache

В Nginx за WebDAV отвечает модуль ngx_http_dav_module. Пример блока location для каталога /dav/:

location /dav/ {
root /srv/webdav;
dav_methods PUT DELETE MKCOL COPY MOVE;
dav_access user:rw group:rw all:r;
create_full_put_path on;
client_max_body_size 0;
auth_basic "WebDAV";
auth_basic_user_file /etc/nginx/.htpasswd;
}

Файл паролей создаётся утилитой htpasswd. Ключевое ограничение: модуль Nginx поддерживает PUT, DELETE, MKCOL, COPY и MOVE, но не реализует LOCK и UNLOCK. Без блокировок одновременное редактирование одного документа двумя сотрудниками приведёт к перезаписи изменений, поэтому для работы с офисными файлами чаще берут Apache.

В Apache включают модули dav, dav_fs и dav_lock, затем в конфигурации виртуального хоста задают Dav On, путь к базе блокировок DavLockDB /var/lock/apache2/DavLock, каталог через Alias /dav /srv/webdav и правило LimitExcept для методов GET, HEAD, OPTIONS и PROPFIND с требованием require valid-user. База блокировок должна лежать на локальном диске, а не на сетевой файловой системе.

Монтирование на клиентах: в Linux команда mount -t davfs https://files.example.com/dav/ /mnt/dav с учётными данными в /etc/davfs2/secrets, в macOS подключение через Finder, в Windows - «Подключить сетевой диск» с HTTPS-адресом. Быстрая проверка сервера выполняется командой curl -u user -X PROPFIND -H 'Depth: 1' https://files.example.com/dav/. Без TLS пароль Basic уходит в открытом виде, а монтирование через WebDAV образов виртуальных машин и медиатеки почти всегда заканчивается таймаутами и неполными копиями.

Сравнение производительности и блокировки файлов в смешанной среде

Пропускная способность на локальной сети у SMB 3.1.1 и NFSv4 сопоставима, когда сеть не стала узким местом: обе реализации упираются в дисковую подсистему и пропускную способность канала. Разницу создают настройки. В SMB это SMB Multichannel, объединяющий несколько сетевых карт, и SMB Direct для RDMA-адаптеров. В NFS - увеличенные rsize и wsize и опция nconnect до 16 соединений. WebDAV остаётся самым медленным вариантом: TLS добавляет нагрузку на CPU, а каждый файл тянет отдельные HTTP-запросы, что особенно заметно на мелких файлах. Для больших последовательных операций, например копирования бэкапов или образов, выбирайте SMB 3 с Multichannel либо NFSv4.2 с server-side copy, если копирование идёт внутри одного сервера.

Блокировки устроены по-разному, и от этого зависит стабильность сервиса.

• SMB. Oplocks в SMB1 и SMB2, leases в SMB2 и SMB3, плюс диапазонные блокировки байтов. Клиент кэширует чтение и запись, сервер ломает lease при конфликте. Активные блокировки видны в smbstatus.
• NFSv4. Блокировки отслеживаются сервером через stateid, состояние привязано к lease (в Linux значение по умолчанию 90 секунд, там же задаётся grace period после рестарта). При обрыве связи клиент пытается восстановить состояние, а не терять данные.
• NFSv3. Блокировки вынесены в отдельные службы lockd и statd, которые должны быть доступны через firewall; это дополнительная точка отказа.
• WebDAV. LOCK и UNLOCK работают только при поддержке сервером и корректной реализации на клиенте. Ряд серверов и клиентов блокировки игнорируют.

Главный риск смешанной среды - не сам протокол, а одновременный доступ к одному файлу через разные протоколы. Windows-клиент откроет документ по SMB и получит lease, Linux-клиент по NFS об этом не узнает и спокойно перезапишет файл. Общего менеджера блокировок между SMB и NFS в типовой конфигурации нет, поэтому правило простое: один протокол на один ресурс. Если на одном сервере подняты и Samba, и NFS, разделите их по разным наборам данных. Приложения с собственной файловой логикой (SQLite, Microsoft Access, PST-файлы) на сетевой шаре не работают надёжно ни по одному протоколу: их место на локальном диске или на блочном томе.

Практические рекомендации по выбору протокола

Готовые решения под типовые сценарии:

1. Преимущественно Windows плюс домен Active Directory. SMB 3.1.1 с Kerberos, SMB1 отключён, минимальная версия задана параметром server min protocol. macOS и Linux подключаются к той же шаре по SMB.
2. Преимущественно Linux, Kubernetes, HPC. NFSv4.1 или 4.2 с sec=krb5p, если в сети есть требования к защите трафика. Тома RWX для Kubernetes удобнее отдавать через NFS CSI-драйвер.
3. Смешанный парк без домена. Либо SMB с локальными учётными записями Samba, либо NFSv4 с LDAP. Единый источник идентичностей обязателен в обоих случаях, иначе UID и SID разъедутся и права станут неуправляемыми.
4. Обмен документами через интернет. WebDAV по HTTPS на Apache с включёнными LOCK, отдельная зона хранения и квоты. Для публикации больших объёмов файлов для веб-приложений объектное хранилище дешевле в эксплуатации.
5. AFP. Только для устаревших macOS-клиентов, с планом миграции на SMB и переносом Time Machine на SMB-шару с поддержкой fruit:time machine.
6. Медиатека и бэкапы больших файлов в LAN. SMB 3 с Multichannel или NFSv4.2. WebDAV для этих задач не подходит.
7. Виртуализация. NFS для датасторов VMware, SMB 3 для Hyper-V. Критерии выбора между NAS и SAN с оценкой TCO разобраны в статье NAS или SAN: выбор сетевого хранилища для инфраструктуры.

Чек-лист перед запуском файлового сервиса:

• Собран список ОС и версий клиентов, включая периферию вроде сканеров и МФУ, которые пишут в шару напрямую.
• Выбран единый источник идентичностей (AD или LDAP) и проверен маппинг UID/GID и SID на тестовом пользователе из каждой ОС.
• На каждый ресурс назначен ровно один протокол, смешанный доступ исключён на уровне конфигурации.
• Для SMB задана минимальная версия протокола и, при требовании, включены подпись и шифрование; для NFS выбран уровень sec.
• Для WebDAV включён HTTPS и проверены LOCK, монтирование и запись на клиентах Windows, macOS и Linux.
• Проверено поведение блокировок: два клиента из разных ОС открывают один файл, результат фиксируется в тестовом протоколе.
• Составлен план миграции AFP-клиентов и проверено сохранение метаданных macOS после переноса данных.

Матрицы поддержки версий и поведение клиентов меняются от выпуска к выпуску, поэтому перед продакшном сверяйтесь с документацией Microsoft, Apple, Samba и разработчиков NFS, а не с сохранёнными ранее заметками. Самый быстрый способ снизить риск - стенд из двух клиентов разных ОС и сценарий с одновременным редактированием одного файла: он показывает больше, чем любая таблица характеристик.