Доступ к файловой системе: права POSIX и ACL, монтирование в Linux, SMB и NFS в 2026 году

Файл не открывается у коллеги, хотя права вы ему выдавали: причина почти всегда лежит в одном из трёх слоёв, и проверять их нужно строго по порядку. Сначала режим доступа POSIX или ACL в Linux и NTFS ACL в Windows, затем параметры монтирования (mount, /etc/fstab), и только после этого правила сетевого протокола SMB или NFS.

Ошибка Permission denied на локальном диске снимается на уровне chmod, chown, setfacl или наследуемых ACL. Отказ в доступе к сетевой папке требует проверки уже четырёх уровней: права файловой системы на сервере, конфигурация шары или экспорта, параметры монтирования на клиенте, аутентификация в домене. Пропуск любого уровня даёт ту же картину: пользователь видит папку, но не может в неё писать.

Ниже собраны рабочие команды и конфигурации для Linux, Windows и смешанной среды: базовые права и ACL, постоянное монтирование через fstab и systemd, сетевые диски Windows, серверы Samba и NFS, диагностика типовых сбоев и чек-лист безопасности. Все примеры проверены на Ubuntu 24.04 LTS, Debian 13, RHEL 10 и Windows Server 2025.

Права доступа в Linux: POSIX и ACL

Модель прав POSIX делит пользователей на три класса: владелец файла, группа-владелец, остальные. Внутри каждого класса работают три бита: чтение (r, 4), запись (w, 2), выполнение (x, 1). Для каталога бит x означает право войти в него и пройти через него, поэтому снятие x у группы мгновенно ломает доступ ко всем файлам внутри, даже если на самих файлах выставлено rw-.

$ ls -ld /srv/project
 drwxr-x--- 2 root devops 4096 Sep 17 10:12 /srv/project

Расшифровка: владелец root имеет rwx, группа devops читает и заходит в каталог, остальные не видят ничего. Символьная и числовая запись эквивалентны: rwxr-x--- это 750.

Базовые права: chmod, chown, umask

Числовая запись компактнее и используется чаще. Команда chmod 750 /srv/data даёт владельцу полный доступ, группе чтение и вход, остальным ничего. Символьная запись нужна для точечных правок: chmod u=rwx,g=rx,o= /srv/data, chmod g+w /srv/data, chmod o-rwx /srv/data.

$ chmod 750 /srv/data
$ chown devops:devops /srv/data
$ ls -ld /srv/data
 drwxr-x--- 1 devops devops 4096 Sep 17 10:20 /srv/data

Команда chown devops:devops /srv/data меняет владельца и группу сразу. Рекурсивный chown -R по большой базе отбирает доступ у сервисных учётных записей и ломает чужие права, поэтому сначала оцените масштаб: find /srv/data -not -user devops | head -20. Для каталогов с общими данными полезен бит setgid: chmod 2775 /srv/shared заставляет новые файлы внутри наследовать группу каталога, а не группу создателя.

Значение umask задаёт права по умолчанию для новых файлов и каталогов. umask 022 даёт каталоги 755 и файлы 644, umask 027 даёт 750 и 640. Для сервера с внутренними данными вариант 027 безопаснее: посторонний пользователь не получит даже чтение. Проверить текущее значение: umask, изменить навсегда: файл /etc/profile.d/umask.sh со строкой umask 027.

Рекурсивный chmod -R 777 не решает проблему доступа, а создаёт новую: любой процесс получает право менять файлы, а аудит теряет смысл. Для выдачи чтения по дереву используйте chmod -R a+rX /srv/data: заглавная X выставляет бит выполнения только каталогам и уже исполняемым файлам, обычные файлы остаются без x.

Расширенные ACL: setfacl и getfacl

POSIX ACL нужны, когда одному пользователю требуется доступ без добавления его в группу-владелец. Пример: разработчику devops нужно читать и писать в /srv/project, но группа проекта занята другим составом.

$ setfacl -m u:devops:rwx /srv/project
$ getfacl /srv/project
# file: srv/project
# owner: root
# group: devops
user::rwx
user:devops:rwx
group::r-x
mask::rwx
other::---

После установки ACL в выводе ls -ld у каталога появляется плюс: drwxrwx---+ 2 root devops 4096 /srv/project. Маска ACL (mask::) ограничивает права всех именованных пользователей, именованных групп и группы-владельца. Если маска станет r-x, то при записи user:devops:rwx фактический доступ останется только на чтение и вход. Исправить: setfacl -m m::rwx /srv/project.

ACL по умолчанию заставляют новые файлы наследовать права родительского каталога: setfacl -d -m u:devops:rwx,g::r-x,o::- /srv/project. Без флага -d наследования нет, и каждый новый файл получит права по umask, то есть доступ для devops исчезнет. Для рабочей группы удобна связка: setgid на каталоге плюс default ACL на группу.

Сохранить и вернуть ACL на другом сервере: getfacl -R /srv > /root/acl-srv.bak, затем setfacl --restore=/root/acl-srv.bak. Поддержка ACL: ext4 включает их по умолчанию и отключает только опцией монтирования noacl, XFS, Btrfs и OpenZFS поддерживают ACL нативно. На tmpfs и части сетевых файловых систем setfacl возвращает ошибку Operation not supported, и тогда нужен другой механизм разграничения.

Монтирование файловых систем в Linux

Права на файл ничего не значат, если раздел смонтирован только для чтения. Сначала проверьте режим монтирования, потом правьте chmod: findmnt -no OPTIONS /mnt/data или mount | grep /mnt/data. Опция ro при коррекных правах даёт ровно тот же отказ в записи, что и chmod 555.

Команда mount и опции монтирования

$ mount /dev/sdb1 /mnt/data
$ mount -t ext4 -o rw,noatime,acl /dev/sdb1 /mnt/data
$ mount -o remount,rw /
$ findmnt /mnt/data

Опции, которые чаще всего влияют на доступ и безопасность:

Монтирование сетевой папки NFS выполняется отдельной командой с указанием версии протокола:

$ mount -t nfs -o vers=4.2,rw,hard,timeo=600,retrans=2 192.168.1.10:/export /mnt/nfs
$ mount -t cifs -o vers=3.1.1,username=aivanov,uid=1001,gid=1001,file_mode=0660,dir_mode=0770 //srv/shared /mnt/shared

Опция intr в современных ядрах игнорируется: возврат по сигналу обеспечивает только soft, который при сбое сервера отдаёт приложению ошибку ввода-вывода и рискует потерей данных. Для рабочих задач оставляйте hard и настраивайте таймауты. Для SMB-монтирования параметры uid, gid, file_mode и dir_mode задают, от чьего имени и с какими правами клиент Linux будет видеть файлы на сервере Windows.

fstab: постоянное монтирование

Файл /etc/fstab содержит шесть полей: устройство, точка монтирования, тип файловой системы, опции, dump, pass. Порядок работ такой:

1. Узнать UUID: blkid | grep sdb1 или lsblk -f.
2. Создать точку монтирования: mkdir -p /mnt/data.
3. Добавить строку в /etc/fstab, сначала с опцией nofail.
4. Проверить: mount -a, затем findmnt --verify.

UUID=8f3c1d2a-4b7e-41c9-9a10-77ab23e5f901 /mnt/data ext4 defaults,noatime,nofail 0 2
192.168.1.10:/export /mnt/nfs nfs4 rw,hard,_netdev,nofail,x-systemd.automount 0 0

Ошибка в fstab для корневых разделов приводит к аварийному режиму загрузки (emergency mode). Защита простая: опция nofail для необязательных дисков, _netdev и x-systemd.automount для сетевых ресурсов, проверка через mount -a при уже работающей системе. Если загрузка всё-таки сломана, перемонтируйте корень в запись: mount -o remount,rw /, закомментируйте проблемную строку и перезагрузитесь.

Systemd mount units и autofs

Systemd строит имя unit из пути: /mnt/data превращается в mnt-data.mount. Такой unit удобнее fstab, когда нужны зависимости от сети и явный порядок запуска.

# /etc/systemd/system/mnt-data.mount
[Unit]
Description=Data volume
After=network-online.target

[Mount]
What=UUID=8f3c1d2a-4b7e-41c9-9a10-77ab23e5f901
Where=/mnt/data
Type=ext4
Options=rw,noatime

[Install]
WantedBy=multi-user.target

# systemctl daemon-reload
# systemctl enable --now mnt-data.mount
# systemctl list-units --type=mount

Пара .mount и .automount даёт монтирование по требованию: том подключается при первом обращении к каталогу и отключается по таймауту. Для редко используемых сетевых ресурсов тот же результат даёт autofs: в /etc/auto.master указывают точку и файл карты, в /etc/auto.nfs перечисляют экспорты, после чего systemctl enable --now autofs. Плюс один: недоступный сервер не блокирует загрузку, а пользователь видит ошибку только в момент обращения к папке.

Сетевые диски в Windows: настройка и права

Подключение сетевого диска: GUI и командная строка

Через Проводник путь такой: Этот компьютер, правая кнопка, Подключить сетевой диск, выбрать букву, указать UNC-путь в виде \\fileserver\shared и отметить галочку восстановления при входе. Для массового развёртывания удобнее командная строка и PowerShell:

net use Z: \\fileserver\shared /user:CONTOSO\aivanov * /persistent:yes
cmdkey /add:fileserver.contoso.local /user:CONTOSO\aivanov /pass:Секрет

New-SmbMapping -LocalPath Z: -RemotePath \\fileserver\shared -Persistent $true
Get-SmbMapping

Параметр * в net use запрашивает пароль без сохранения его в истории команд. Диспетчер учётных данных (cmdkey) хранит данные для сервера целиком, поэтому после смены пароля старую запись нужно удалить: cmdkey /delete:fileserver.contoso.local. В домене диски удобнее раздавать политиками, разбор Drive Maps, диагностики и последовательности применения собран в материале про групповые политики для сетевых папок и дисков.

Права доступа в Windows: NTFS и общие ресурсы

Итоговый доступ в Windows определяет пересечение двух наборов разрешений: прав NTFS на диске сервера и прав общего ресурса SMB. Работает принцип наибольшего ограничения: если шара даёт чтение, а NTFS разрешает запись, пользователь получит только чтение. Практика администрирования: на шаре выдать Change или Full Control, а точное разграничение держать в NTFS ACL, где доступны наследование, наследуемые разрешения и вкладка Эффективный доступ.

icacls D:\shared
icacls D:\shared /grant "CONTOSO\devops:(OI)(CI)M" /T
icacls D:\shared /remove:g "CONTOSO\gost"

Сокращения в icacls: M это Modify, RX это чтение и выполнение, (OI) и (CI) включают наследование для файлов и папок. Выдавать Full Control целой группе стоит только там, где действительно нужно менять ACL. Подробный разбор NTFS ACL, наследования, групп безопасности и расшифровки числовых записей прав приведён в статье про права доступа в Windows: NTFS, SMB, настройка ACL и безопасность.

Актуальное поведение 2026 года: клиент SMB1 удалён из Windows 11 24H2 и Windows Server 2025, а подписывание SMB включено по умолчанию и для клиента, и для сервера. Если старый NAS не умеет SMB signing, подключение к нему ломается с ошибкой доступа, хотя права выданы корректно. Проверить состояние: Get-SmbServerConfiguration | Select RequireSecuritySignature, EnableSMB1Protocol.

Протоколы SMB и NFS: настройка серверов

Выбор протокола определяется клиентами и моделью аутентификации, а не скоростью сети.

SMB over QUIC доступен в Windows Server 2022 и 2025 и позволяет отдавать файлы через порт 443 UDP с сертификатом, что удобно для удалённых сотрудников без VPN. NFS чаще выбирают для Linux-парка, виртуализации и контейнеров, где доступ нужен по UID/GID без ввода пароля.

Samba: настройка SMB-сервера

Установка и подготовка пользователя:

$ sudo apt install samba
$ sudo useradd -M -s /usr/sbin/nologin winuser
$ sudo smbpasswd -a winuser
$ sudo testparm
$ sudo systemctl restart smbd nmbd

Секция шары в /etc/samba/smb.conf с комментариями по ключевым параметрам:

[shared]
   path = /srv/shared
   valid users = @smbusers
   read only = no
   browseable = yes
   force group = smbusers
   create mask = 0660
   directory mask = 0770
   vfs objects = acl_xattr
   map acl inherit = yes

Параметры force user и force group заставляют Samba работать с файлами от имени одной учётной записи, что снимает половину проблем в смешанной среде. Директивы create mask и directory mask задают права новых файлов. Модуль acl_xattr хранит Windows ACL в расширенных атрибутах файловой системы, без него права Windows не переживут копирование на другой сервер. Минимальная версия протокола в современных сборках Samba это SMB2, клиент SMB1 отключён по умолчанию и включать его не нужно. Проверка доступа с сервера: smbclient -L localhost -U winuser, состояние подключений: smbstatus. Расширенные настройки, аудит и шифрование разобраны в руководстве по SMB-ресурсам в Windows Server 2026. Файрвол: ufw allow samba или ufw allow 445/tcp.

NFS: экспорт каталогов

$ sudo apt install nfs-kernel-server
$ echo '/srv/nfs 192.168.1.0/24(rw,sync,no_subtree_check,root_squash)' | sudo tee -a /etc/exports
$ sudo exportfs -ra
$ sudo exportfs -v
$ showmount -e 192.168.1.10

Опция root_squash понижает права root на клиенте до анонимного пользователя и защищает сервер: без неё клиент с root получает полный доступ ко всем файлам экспорта. Вариант no_root_squash допустим только для доверенных хостов, например для сервера резервного копирования. Параметр sync гарантирует запись на диск до ответа клиенту, async ускоряет работу и повышает риск потери данных при сбое.

Для NFSv4 достаточно открыть порт 2049: протокол не использует rpcbind, в отличие от NFSv3, где дополнительно нужны порт 111 и динамические порты mountd, lockd и statd. Шифрование и проверка подлинности в NFSv4 включаются через Kerberos: экспорт с опцией sec=krb5p шифрует трафик и требует рабочий обратный DNS и корректный idmap. Детали экспортов, Kerberos и монтирования на клиентах разобраны в гайде по настройке NFS и SMB шар с разграничением прав доступа.

Типичные ошибки прав доступа и их диагностика

Сообщение Permission denied почти никогда не указывает на конкретный слой. Проверять нужно всю цепочку от корня до файла, потому что отказ может дать каталог четырьмя уровнями выше. Битрейт диагностики повышается, если идти сверху вниз и фиксировать результат на каждом шаге.

Диагностика в Linux

1. Права по всему пути: namei -l /srv/shared/report.xlsx, отдельный вариант для каталога: ls -ld /srv /srv/shared.
2. Владелец и группы пользователя: id, groups, id devops.
3. Расширенные ACL и маска: getfacl /srv/shared/report.xlsx.
4. Режим монтирования и опции: findmnt /srv, findmnt -no OPTIONS /srv.
5. Проверка от имени пользователя: sudo -u devops test -w /srv/shared/file || echo "нет записи".
6. Системные вызовы, если ничего не сходится: strace -f -e trace=openat,unlinkat sudo -u devops cat /srv/shared/report.xlsx.

Ошибка монтирования NFS ищется по журналам и состоянию служб: dmesg | tail -50, journalctl -xe -u nfs-server, journalctl -u nfs-mountd, rpcinfo -p 192.168.1.10, ss -tulpn | grep -E '445|2049|111'. Если каталог не виден в showmount -e, проблема на стороне экспорта, а не прав.

Мандатные системы контроля доступа дают отказ даже при верных правах POSIX. Проверить SELinux: getenforce, ls -Z /srv/shared, исправить контекст: restorecon -Rv /srv/shared, разрешить общий доступ: setsebool -P samba_export_all_rw on. Проверить AppArmor: aa-status и журнал /var/log/kern.log. Аудит доступа включается через auditd: auditctl -w /srv/shared -p rwa -k shared_access, потом поиск событий: ausearch -k shared_access, поиск запретов SELinux: ausearch -m avc -ts recent.

В доменной среде с FreeIPA и Astra Linux большинство сбоев входа связано не с самим клиентским пакетом, а с DNS, рассинхронизацией времени и именем хоста. Порядок проверки: dig SRV-записи домена, timedatectl, hostnamectl, состояние sssd через systemctl status sssd и sssd -i в отладочном режиме. Диагностика пакетов без запуска служб делается так: dpkg -l | grep -Ei 'freeipa|sssd|krb5'.

Когда журнал разрастается до тысяч строк, быстрее разобрать его через LLM: агрегатор AiTunnel даёт доступ к более чем 200 моделям (GPT, Gemini, Claude) через единый OpenAI-совместимый интерфейс с оплатой в рублях и управлением бюджетами ключей.

Диагностика в Windows

1. Доступность порта: Test-NetConnection fileserver.contoso.local -Port 445.
2. Текущие подключения: net use, Get-SmbMapping, Get-SmbConnection.
3. Билеты Kerberos: klist, при подозрении на устаревшие учётные данные klist purge.
4. Права в файловой системе: icacls D:\shared, вкладка Эффективный доступ в свойствах папки.
5. Журналы: Просмотр событий, журналы SMBClient (Подключение) и SmbServer (Безопасность).

Код 0x80070035 означает, что узел или порт 445 недоступен: проверьте службу Server и SMB, профиль сети, файрвол и DNS-разрешение имени. Код 0x80070005 это отказ в правах на уровне NTFS или шары. Код 0x800704CF возникает при неработоспособном сетевом пути, часто из-за VPN или нескольких сетевых профилей. Ошибка входа без указания кода обычно связана с политикой NTLM или несовпадением требований подписывания SMB между клиентом и сервером.

Практический пример: общий доступ в смешанной среде Windows и Linux

Задача: папка на сервере Ubuntu 24.04 LTS должна быть доступна по SMB из Windows и через CIFS с Linux-клиента, при этом сторонние пользователи не должны видеть содержимое. Порядок действий проверен на живом стенде.

1. Создать группу и пользователей с одинаковыми UID/GID, чтобы права совпадали на сервере и клиентах:

   $ sudo groupadd -g 2001 smbusers
   $ sudo useradd -M -u 2001 -g 2001 -s /usr/sbin/nologin winuser
   $ sudo useradd -M -u 2002 -g 2001 -s /bin/bash linuxuser
   $ sudo smbpasswd -a winuser
   

2. Создать каталог и выставить права с наследованием группы:

   $ sudo mkdir -p /srv/shared
   $ sudo chown root:smbusers /srv/shared
   $ sudo chmod 2770 /srv/shared
   $ sudo setfacl -d -m g:smbusers:rwx,o::- /srv/shared
   $ ls -ld /srv/shared
    drwxrws---+ 2 root smbusers 4096 Sep 17 11:02 /srv/shared
   

3. Описать шару в /etc/samba/smb.conf:

   [shared]
      path = /srv/shared
      valid users = @smbusers
      read only = no
      force group = smbusers
      create mask = 0660
      directory mask = 0770
   

4. Проверить конфигурацию и перезапустить службы:

   $ sudo testparm
   $ sudo systemctl restart smbd
   $ smbclient -L localhost -U winuser
   

5. На Windows подключить диск: net use Z: \\srv\shared /user:SRV\winuser * /persistent:yes. На Linux-клиенте смонтировать через /etc/fstab:

   //srv/shared /mnt/shared cifs vers=3.1.1,credentials=/root/.smbcred,uid=1002,gid=2001,file_mode=0660,dir_mode=0770,_netdev,nofail 0 0
   

6. Проверить доступ с обеих сторон: создать файл с Windows и убедиться, что он читается и пишется из Linux, затем наоборот. Владелец файла на Linux-клиенте определяется параметром uid, а не реальным SID пользователя Windows, это нормальное поведение CIFS.

Если файловый сервер разворачивается в облаке, диски и VPS проще поднимать рядом с рабочими нагрузками: Timeweb Cloud предоставляет серверы, VDS/VPS, базы данных, хранилище и Kubernetes, что удобно для размещения файлового сервера и резервных копий в одной панели с гибким изменением ресурсов.

Ключевой риск смешанной среды это рассинхронизация UID/GID и SID. Если Linux-клиент монтирует шару с uid=1002, а на сервере этому пользователю соответствует другой UID, права на файлы будут разъезжаться. Для доменов решают через winbind и idmap, для локальных серверов фиксируют UID/GID вручную и хранят их в документации, а разбор базовых команд и структуры файловой системы Linux есть в практическом руководстве по Linux для IT-специалистов.

Чек-лист безопасности при организации сетевого доступа

• Использовать SMB 3.1.1 или выше, включить шифрование: smb encrypt = required в smb.conf, на Windows Server проверить Set-SmbServerConfiguration -EncryptData $true. Подписывание SMB оставить обязательным.
• Клиент SMB1 держать отключённым и на клиентах, и на серверах: протокол устарел и не получает исправлений.
• Для NFS применять NFSv4 с Kerberos: опция sec=krb5p в /etc/exports, а не анонимный доступ по IP.
• Оставлять root_squash для всех экспортов NFS и не использовать no_root_squash без отдельного доверенного хоста.
• Ограничить доступ по сети: ufw allow from 192.168.1.0/24 to any port 445, ufw allow from 192.168.1.0/24 to any port 2049, остальное закрыть.
• Применять принцип минимальных привилегий: чтение там, где не нужна запись, отдельные группы на каждую шару, никаких 777 и Full Control для широких групп.
• Отключить гостевой доступ: guest ok = no в Samba, отключённая учётная запись Guest и запрет анонимного перечисления в Windows.
• Включить аудит: auditd для Linux, расширенный аудит доступа к объектам для Windows, журналы Samba на уровне 1-2 для отслеживания подключений.
• Проверять наследование прав при переносе данных: копирование через robocopy /COPYALL или rsync -AX сохраняет ACL, простое копирование файлов права теряет.
• Держать мандатные системы в согласованном состоянии: restorecon -Rv после переноса данных, корректные профили AppArmor для smbd и nfsd.
• Обновлять серверное ПО: уязвимости Samba и ядра напрямую влияют на доступ к общим ресурсам, а обновление NFS-клиента меняет поведение таймаутов.
• Настроить резервное копирование с проверкой восстановления: права и ACL должны восстанавливаться тем же инструментом, которым снимались.
• Раз в квартал проверять фактическую конфигурацию: smbstatus, showmount -e, ss -tulpn, Get-SmbShareAccess, Get-SmbServerConfiguration, а также список учётных записей с правом записи на шары.

Начните с одного узла: снимите дамп прав через getfacl -R и icacls, зафиксируйте его в репозитории конфигураций и только потом меняйте настройки на продакшене. Так любое изменение можно сравнить и откатить за минуты, а не искать причину отказа в доступе по всему стеку.