Настройка NFS и SMB шар для хранилища инструментов: разграничение прав доступа в 2026 году

NFS или SMB: что выбрать для хранилища инструментов в 2026 году

Для хранилища инструментов, где лежат скрипты, артефакты сборки, конфигурации и дистрибутивы, протокол выбирают по клиентам, а не по серверу. Linux-инфраструктура с CI/CD получает меньше трения на NFSv4.2, смешанная среда с Windows-разработчиками и Active Directory - на SMB 3.1.1. TrueNAS SCALE 24.04 и новее поднимает оба протокола на одном датасете ZFS, поэтому выбор сводится к модели прав: POSIX-права и NFSv4 ACL либо Windows ACL с наследованием.

Рабочее правило на 2026 год: если все потребители шар - Linux-хосты, берите NFSv4.2 с Kerberos. Если среди потребителей есть Windows, доменные группы и групповые политики, берите SMB 3.1.1. Открыть оба протокола на одном каталоге можно, но разграничение строится на одной модели прав, а вторая маппится поверх неё через ACL и idmapping.

Дальше по порядку: сравнение протоколов, пошаговая настройка /etc/exports и smb.conf, ACL и аутентификация, монтирование на клиентах, разбор ошибок Permission denied и Access is denied, требования безопасности и итоговый чек-лист.

Ключевые различия NFS и SMB в 2026 году

Практические выводы из таблицы. NFSv4.2 в ядре 6.x закрывает задачи хранилища инструментов без внешних демонов: серверные копирования экономят трафик при копировании больших артефактов, pNFS помогает при нескольких площадках, разреженные файлы не раздувают образы и бэкапы. SMB 3.1.1 даёт шифрование на уровне протокола, SMB Multichannel складывает пропускную способность нескольких сетевых карт, а SMB Direct на RDMA-сетях снимает нагрузку с процессора.

Блокировки упрощают firewall: NFSv4 работает по одному TCP-порту 2049, тогда как NFSv3 требует rpcbind и отдельные порты NLM, что заметно усложняет правила nftables на границе сегментов.

Права различаются сильнее, чем принято думать. NFSv4 ACL структурно ближе к Windows ACL: поддерживает deny-записи, наследование и маску. POSIX ACL ограничен тремя классами с расширениями и не умеет явный запрет. В Samba Windows ACL хранятся в расширенных атрибутах файловой системы, поэтому настройка сводится к одной модели прав для обеих платформ.

Сценарии применения: когда NFS, когда SMB

• Linux-кластер с CI/CD (Jenkins, GitLab Runner, агенты в Kubernetes). Оптимален NFSv4.2: сервисные учётные записи получают собственные UID, каталоги артефактов монтируются одинаково на всех агентах, а права читаются из NFSv4 ACL. Для сборочных узлов, которым нужен доступ к корню каталога без подмены пользователя, экспорт открывают с no_root_squash строго по IP агентов.
• Смешанная среда, где разработчики работают на Windows, а сборка идёт на Linux. Выбирайте SMB 3.1.1 с Windows ACL: доменные группы из Active Directory управляют доступом, Linux-хосты монтируют шару через cifs-utils и видят те же ACL. Так права не приходится дублировать в двух моделях.
• Хранилище артефактов (Docker registry, Nexus, зеркало apt и pypi). Registry с несколькими репликами проще держать на NFS, а Nexus в компании с Windows-администраторами удобнее отдать по SMB, чтобы права назначались привычными инструментами домена.

Если хранилище инструментов разворачивается на арендованной инфраструктуре, серверы и дисковое пространство удобно брать в облаке с оплатой за фактические ресурсы, например в Timeweb Cloud: виртуальная машина под файловый сервер и отдельный том под датасет ZFS поднимаются за несколько минут, а firewall и приватная сеть настраиваются до установки NFS и Samba.

Настройка NFS-сервера и разграничение прав доступа

Базовая последовательность для Debian 12 и Ubuntu Server 24.04: установка пакета nfs-kernel-server, подготовка каталога, экспорт, применение настроек и проверка. Полный разбор сборки файлового сервера с нуля, включая firewall и тюнинг производительности, собран в руководстве про настройку NFS и SMB на минимальном файловом сервере Linux.

apt install nfs-kernel-server
mkdir -p /srv/tools/ci
chown root:devops /srv/tools
chmod 2775 /srv/tools

Бит setgid (2775) на каталоге заставляет новые файлы наследовать группу devops, и это снимает половину будущих обращений в поддержку о правах доступа.

Базовая конфигурация /etc/exports

/srv/tools 192.168.1.0/24(rw,sync,no_subtree_check,root_squash)
/srv/tools/ci 10.10.0.0/24(rw,sync,no_subtree_check,no_root_squash)

Разбор опций: rw разрешает чтение и запись; sync подтверждает запись на диск до ответа клиенту, что важно для артефактов сборки; no_subtree_check отключает проверку поддерева и убирает ложные ошибки при переименовании файлов; root_squash подменяет uid 0 на анонимного пользователя и не даёт клиентскому root менять владельцев файлов.

Для NFSv4 корень псевдофайловой системы задают отдельным экспортом с fsid=0, а подкаталоги подключают через bind mount. Тогда клиент видит короткий путь server:/tools вместо длинной цепочки каталогов.

Применить и проверить: exportfs -ra; exportfs -v; showmount -e localhost. Число потоков nfsd задаётся в /etc/nfs.conf в секции [nfsd] параметром threads; для хранилища с десятками агентов сборки 16-32 потока покрывают нагрузку, а фактическое значение видно в /proc/fs/nfsd/threads.

Настройка NFSv4 ACL и маппинг пользователей

nfs4-acl-tools даёт прямой доступ к NFSv4 ACL: nfs4_setfacl -R -m 'A:g:devops@corp.local:rxtncy' /srv/tools, проверка через nfs4_getfacl /srv/tools.

Расшифровка записи: A означает разрешение (в отличие от D, запрета), g задаёт группу, набор rxtncy покрывает чтение, выполнение, запись, наследование новых файлов (n), наследование подкаталогов (c) и наследование прав (y). Запись D:g:contractors@corp.local:wa блокирует запись для группы подрядчиков, и это то, чего не умеет POSIX ACL.

Маппинг имён настраивается в /etc/idmapd.conf: параметр Domain = corp.local и метод nsswitch. При одинаковых именах пользователей на сервере и в домене Kerberos обычно достаточно домена и синхронизированного времени.

Главная ловушка: при подключении без Kerberos сервер доверяет числовым UID и GID с клиента. Если на клиенте пользователь с UID 1000, а на сервере файл принадлежит UID 1001, вы получите Permission denied при визуально верных правах. Решение - NFSv4 idmapping по именам пользователей либо централизованные UID из LDAP или AD.

Настройка SMB-шары и ACL в Samba

Сценарии Windows-среды с NTFS и SMB permissions подробно разобраны в отдельной инструкции про настройку и управление SMB-ресурсами в Windows Server 2026, здесь же собран вариант на Samba для смешанной среды.

Конфигурация smb.conf для хранилища инструментов

[tools]
path = /srv/tools
browseable = yes
writable = yes
valid users = @devops @ci
write list = @ci
create mask = 0660
directory mask = 0770
force group = devops
vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes
smb encrypt = required
server min protocol = SMB3_11

Что делает каждая строка: valid users ограничивает доступ двумя доменными или локальными группами; write list оставляет право записи только сборочной группе, а разработчики получают чтение; create mask и directory mask задают права новых файлов и каталогов; force group гарантирует единую группу независимо от того, под кем пришёл пользователь.

Ключевой момент для Windows ACL: vfs objects = acl_xattr хранит NTFS-совместимые права в расширенных атрибутах, а map acl inherit переносит наследование Windows на файловую систему Linux. Без этих двух строк icacls на клиенте вернёт ошибку записи ACL, хотя файлы будут читаться.

Проверка конфигурации: testparm -s, затем systemctl reload smbd. Список шар с клиента проверяется командой smbclient -L localhost -N, а подключение под конкретным пользователем - smbclient //server/tools -U devops.

Windows ACL и их настройка через icacls и smbcacls

С Windows-клиента: icacls \\server\tools /grant "CORP\devops:(OI)(CI)M" /T. Флаги (OI) и (CI) включают наследование объектами и контейнерами, буква M даёт изменение без смены владельца, параметр /T применяет правило рекурсивно.

С Linux тот же результат даёт smbcacls //server/tools /srv/tools -a 'ACL:ALLOWED/0x001F01FF/DEVOP' для полного доступа группы и отдельная запись с маской чтения для второй группы. Если удобнее работать на уровне файловой системы, используйте setfacl -R -m g:devops:rwx /srv/tools и setfacl -R -d -m g:devops:rwx /srv/tools для наследования по умолчанию.

Разница между моделями и порядок вычисления эффективных прав разобраны в материале про права доступа в Windows: NTFS, SMB, настройка ACL. Коротко о главном: разрешение на шаре и разрешение NTFS перемножаются, побеждает более строгое, а explicit deny перекрывает любой allow.

Монтирование сетевых шар на Linux и Windows клиентах

Монтирование NFS в Linux: fstab и autofs

Разовая проверка: mount -t nfs -o vers=4.2,sec=krb5p server:/srv/tools /mnt/tools.

Постоянное монтирование в /etc/fstab:
server:/srv/tools /mnt/tools nfs4 vers=4.2,sec=krb5p,_netdev,noauto,x-systemd.automount,hard,timeo=600,retrans=2,nconnect=4 0 0

Опции подобраны под боевую эксплуатацию. _netdev монтирует шарy после поднятия сети, noauto не тормозит загрузку, x-systemd.automount подключает ресурс при первом обращении, hard с timeo и retrans не теряет данные при кратком сетевом сбое, nconnect=4 открывает четыре TCP-соединения и поднимает пропускную способность на одном канале.

Альтернатива для больших парков: autofs. В /etc/auto.master строка /mnt/tools /etc/auto.tools --timeout=300, а в /etc/auto.tools запись tools -vers=4.2,sec=krb5p server:/srv/tools. Точка монтирования создаётся при обращении и размонтируется после простоя, что экономит ресурсы на сотнях хостов.

Подключение сетевого диска Windows SMB

Из командной строки: net use Z: \\server\tools /user:CORP\user * /persistent:yes. Звёздочка запрашивает пароль без его сохранения в истории команд, /persistent:yes восстанавливает подключение после перезагрузки.

Через графический интерфейс: «Этот компьютер» → «Подключить сетевой диск» → путь \\server\tools → галочка «Восстанавливать подключение при входе в систему». Для парка машин удобнее назначать диски централизованно, порядок настройки сетевых дисков через групповые политики с разбором UNC-путей и диагностикой описан в статье про групповые политики для сетевых папок и дисков.

Для Linux-клиента SMB монтируется через cifs-utils: mount -t cifs -o credentials=/etc/smbcreds,vers=3.1.1,sec=krb5 //server/tools /mnt/tools. Файл с учётными данными хранится с правами 600, а при доменной аутентификации вместо логина и пароля достаточно действующего Kerberos-билета.

Отдельное предупреждение: подключение с гостевыми правами к шаре с Windows ACL почти всегда заканчивается отказом в доступе к части файлов. Используйте доменную учётную запись даже для чтения.

Диагностика ошибок прав доступа: Permission denied и Access is denied

Типовые ошибки NFS и их решение

• mount.nfs: access denied by server while mounting. Проверьте /etc/exports, примените exportfs -ra и убедитесь, что IP клиента попадает в разрешённую подсеть. Частая причина - клиент выходит в сеть с другим адресом через NAT.
• Permission denied при записи. Сравните UID и GID владельца файла на сервере с учётной записью на клиенте. Если запись идёт от root и стоит root_squash, сервер подменит его анонимным пользователем.
• Stale file handle. Возникает после перезапуска сервера или смены экспорта. Помогает umount -f на клиенте и повторное монтирование; при массовой проблеме проверьте, что fsid у экспорта не меняется между перезапусками.
• Медленная запись артефактов. Проверьте опции rsize и wsize, режим sync и число потоков nfsd. Для мелких файлов добавьте nconnect, для крупных архивов поможет server-side copy.

Инструменты NFS-диагностики: showmount -e server, exportfs -v, cat /proc/fs/nfsd/exports, nfsidmap -d, journalctl -u nfs-server, dmesg | grep -i nfs.

Типовые ошибки SMB и их решение

• Access is denied. По очереди проверьте членство в группе из valid users, разрешения NTFS и разрешения шары, а также сохранённые в диспетчере учётных данных старые пароли.
• The account is not authorized to log in from this station. Ограничение задано в свойствах доменной учётной записи (список рабочих станций), а не в Samba.
• mount error(13): Permission denied на Linux-клиенте. Проверьте файл с учётными данными, параметры vers и sec, а также опции uid, gid и forceuid при подключении к шаре с ACL.
• Пользователь входит, но не видит файлы. Часто виновата неполная синхронизация winbind: группа в smb.conf указана как @devops, а служба ещё не отдала её состав.

Инструменты SMB-диагностики: testparm, smbstatus с активными сессиями и блокировками, smbclient -L //server -U user, wbinfo -u и wbinfo -g, klist для проверки Kerberos-билета, journalctl -u smbd. Сквозной алгоритм поиска причины отказа, от DNS и NTP до ACL и Active Directory, разобран в статье про диагностику ошибки аутентификации в NAS и файловых сервисах.

Правило безопасной диагностики: сначала собирайте факты (exportfs -v, smbstatus, логи), и только потом меняйте конфигурацию. Правка root_squash или валидных пользователей на работающем хранилище инструментов ломает сборки быстрее, чем помогает.

Безопасность и актуальность версий ПО в 2026 году

Аутентификация NFS Kerberos: настройка и проверка

Порядок работ: установить krb5-user, прописать в /etc/krb5.conf realm домена и адреса KDC, создать keytab для принципала nfs/server.corp.local через msktutil или ktutil, затем добавить sec=krb5p в /etc/exports.

Уровни защиты различаются: sec=krb5 только аутентифицирует, sec=krb5i добавляет контроль целостности, sec=krb5p шифрует трафик. Для хранилища с исходным кодом и ключами доступа выбирайте krb5p.

Проверка: kinit user@CORP.LOCAL, klist, затем монтирование с sec=krb5p. Условия, без которых схема не работает: точное время по NTP на всех узлах, корректный прямой и обратный DNS, права 600 на файле keytab и владелец root.

Шифрование SMB и отключение устаревших протоколов

Минимальный безопасный набор в smb.conf: server min protocol = SMB3_11, smb encrypt = required, ntlm auth = ntlmv2-only, server signing = mandatory. Шифрование SMB 3.1.1 использует AES-128-GCM, а на новых сборках Windows доступен и AES-256-GCM.

Факт шифрования подтверждается не только настройкой: смотрите smbstatus по активным сессиям и логи smbd при log level = 10, где видно согласование cipher. В дампе трафика в этом режиме SMB2-структуры не читаются открытым текстом.

По версиям ПО ориентиры на 2026 год: ядро Linux 6.x с NFSv4.2, Samba 4.20 и новее с SMB 3.1.1 и шифрованием, TrueNAS SCALE 24.04+ с NFSv4.2, SMB 3.1.1 и ACL в веб-интерфейсе. no_root_squash держите только для доверенных подсетей сборки, а обновления безопасности Samba и nfs-utils проверяйте по CVE до планового окна, а не после инцидента.

Чек-лист и типовые сценарии для хранилища инструментов DevOps

1. Определите потребителей шар: Linux-хосты, Windows-рабочие места, CI/CD-агенты.
2. Выберите протокол: NFSv4.2 для Linux, SMB 3.1.1 для Windows и смешанной среды.
3. Настройте сервер: /etc/exports с rw, sync, no_subtree_check и root_squash либо секцию [tools] в smb.conf с acl_xattr.
4. Разграничьте права: NFSv4 ACL для групп разработчиков на чтение, группа CI на запись; Windows ACL с наследованием (OI)(CI)M для доменных групп.
5. Включите аутентификацию: Kerberos sec=krb5p для NFS, NTLMv2 или Kerberos с обязательным шифрованием для SMB.
6. Смонтируйте на клиентах: fstab с _netdev и x-systemd.automount для NFS, net use с persistent или групповые политики для Windows.
7. Проверьте доступ от имени каждой роли и настройте мониторинг: журналы nfsd и smbd, метрики задержки записи, алерты на ошибки монтирования.

Типовой сценарий: хранилище скриптов и артефактов для CI/CD. Каталог /srv/tools с двумя подкаталогами, шара NFSv4.2 с sec=krb5p отдана Jenkins и агентам сборки, права на запись закреплены за группой ci, чтение за devops, а для Windows-разработчиков открыта та же файловая система по SMB 3.1.1 с шифрованием и Windows ACL. Все изменения прав проходят через одну модель, поэтому расхождений между платформами не возникает. На TrueNAS SCALE этот же результат собирается встроенными шаблонами шар без ручной правки smb.conf.

Отдельная мелочь, которая экономит время: в каталоге конфигураций часто лежат скрипты с ключами внешних сервисов. Если среди них есть вызовы языковых моделей, удобно держать один ключ агрегатора, например AiTunnel с доступом к десяткам моделей и оплатой в рублях, и выдавать его только группе ci. Тогда ротация ключей затрагивает один файл, а права на него остаются в рамках уже настроенных ACL.

Сохраните этот чек-лист рядом с конфигами хранилища и прогоните каждый пункт на тестовом датасете ZFS перед применением на боевом: снапшот занимает секунды, а откат после неверно выставленного no_root_squash или valid users проходит без остановки сборочных процессов.