Короткий ответ

По сети действует пересечение прав шары и NTFS: кто Restricted на любом слое — тот и отказ. Локальный интерактивный логон на сервере шару не проходит, поэтому «на FS01 открывается, с WS-042 нет» — классика. Снимите Get-SmbShareAccess и Get-Acl, затем Effective Access для contoso\ivanov. Не ставьте Everyone Full Control на оба слоя.

445 и SMB живы — эта статья. Нет 445 — SMB.

Симптомы и как отличить

  • Access denied / код 5 после успешного подключения к \\FS01\data.
  • Админ с C:\data работает, пользователь по UNC — нет.
  • После добавления в группу «не помогло», пока не было нового логона.
СлойТипичная ошибка
Share Read, NTFS Modifyне может писать по сети
Share Full, NTFS Readне может писать
ABEпапка «пропала», не всегда denied
Нет 445не ACL

Возможные причины

  1. Шара Everyone Read, на NTFS пользователю Modify — запись отвалится.
  2. NTFS Everyone отсутствовал, шара Change — всё равно нет права на файл.
  3. Deny ACE (часто «Domain Users Deny Delete») бьёт Allow.
  4. Наследование сломано на подпапке.
  5. Share permissions на DFS-линке vs NTFS на таргете — смотрят оба, но путают объект.
  6. Администратор смотрит ACL, сидя под другой УЗ, Effective Access не запускал.
  7. UAC / Elevated vs сеть (сеть не даёт админский токен как локальная консоль).

Диагностика

Get-SmbShare -Name 'data' | Format-List Name, Path, SecurityDescriptor
Get-SmbShareAccess -Name 'data'
(Get-Acl 'D:\data').Access | Format-Table IdentityReference, FileSystemRights, AccessControlType, IsInherited

Effective Access в GUI: свойства папки → Security → Advanced → Effective Access → contoso\ivanov. Учтите: для сети дополнительно ограничит шара.

Проверка групп:

Get-ADUser 'ivanov' -Properties MemberOf | Select-Object -ExpandProperty MemberOf
Get-ADPrincipalGroupMembership 'ivanov' | Format-Table Name

После добавления в группу — новый логон на WS-042.

Список открытых сессий (кто чем пришёл):

Get-SmbSession | Format-Table ClientComputerName, ClientUserName, NumOpens
Get-SmbOpenFile | Where-Object Path -match 'data'

Решение

Модель

Рекомендуемая: шара = Authenticated Users Change (или Full для админов шары), детализация на NTFS группами. Не дублируйте пять уровней на шаре и NTFS разными людьми.

Сценарий A. Шара уже, NTFS узкий

Добавьте группу на NTFS Modify на D:\data. Не Everyone Full.

Сценарий B. NTFS широкий, шара Read

Поднимите share до Change для той же группы. Именно это «на сервере пишется, по сети нет».

Сценарий C. Deny

Найдите явный Deny. Удалите его, если он ошибочный; не маскируйте новым Allow — Deny побеждает.

Сценарий D. Наследование

icacls D:\data\subdir

Верните наследование, если подпапку «починили» вручную.

Сценарий E. Админ с сети

Remote UAC фильтрует локальных админов по сети. Для файлов используйте доменные группы на NTFS, не «локальный Administrators с WS-042».

Сценарий F. Как читать эффективный доступ по сети

Effective Access в проводнике на FS01 показывает NTFS локально. По UNC дополнительно режет шара. Поэтому админ на консоли пишет в D:\data, а ivanov с WS-042 получает код 5.

Сверьте слои одной таблицей:

Get-SmbShareAccess -Name 'data' | Format-Table Name, AccountName, AccessRight, AccessControlType
(Get-Acl 'D:\data').Access |
  Where-Object { $_.IdentityReference -match 'ivanov|Data-|Everyone|Authenticated' } |
  Format-Table IdentityReference, FileSystemRights, AccessControlType, IsInherited
Get-ADPrincipalGroupMembership 'ivanov' | Format-Table Name

Share Change ∩ NTFS Read = Read по сети. Share Full ∩ NTFS Modify + явный Deny Delete = не сможет удалить. Вложенность: группа ACL-Data-RW вложена в ACL-Data-RO с Deny — ищите nested.

Токен: добавили ivanov в группу пять минут назад — старый сеанс SMB держит старый токен. Нужны logoff и Get-SmbSession без залипшей сессии. net.exe use /delete на клиенте.

Наследование: icacls D:\data\project без (I) на ACE — кто-то снял наследование. Верните, если это не сознательный карантин проекта.

Как проверить, что проблема устранена

С WS-042 под ivanov (не админ):

New-Item '\\FS01.contoso.example\data\probe-ivanov.txt' -ItemType File -Value 'ok'
Remove-Item '\\FS01.contoso.example\data\probe-ivanov.txt'

Effective Access показывает ожидаемые биты. Шара не Everyone Full. Сосед, кто не в группе, по-прежнему denied.

Если не помогло

  • Только через DFS: права на folder target и на namespace (отдельно).
  • BitLocker / EFS: ключ, не NTFS Modify.
  • NFS-клиент — другая модель прав.
  • GPO Restricted Groups перетирает локальных. Computer GPO.

Проверьте, что тестируете того же ivanov, а не админа с сети: Remote UAC и фильтр администраторов путают картину. Сессия SMB могла остаться со старым токеном — Get-SmbSession и net.exe use /delete. Для DFS смотрите ACL на C:\DFSRoots\public и на D:\data отдельно. Если Effective Access «полный», а запись по UNC нет — ещё раз шара Change vs Read. Не чините это включением SMB1.

Профилактика

  • Группы ACL-Data-RW / ACL-Data-RO, только они на NTFS.
  • Шаблон шары одинаковый.
  • Документировать Deny.
  • Не выдавать права на имя пользователя, только группы.
  • После миграции DFS — проверить оба слоя.
  • Регламент: шара Change для Authenticated Users или группы отдела, детализация только на NTFS. Любой Everyone Full на проде — повод для ревизии ACL, не «так быстрее».

FAQ

Кто побеждает — шара или NTFS?

Никто «не побеждает»: берётся более строгое пересечение Allow, затем Deny.

Почему Everyone Full на шаре всё равно denied?

NTFS. Шара Full ∩ NTFS Read = Read.

Нужно ли Authenticated Users на NTFS, если есть группа отдела?

Нет обязаловки. Лучше только группы отдела + SYSTEM + Administrators.

CREATOR OWNER зачем?

Новые файлы получают владельца. Без Modify на каталоге пользователь не создаст объект, и OWNER не поможет.

icacls /reset безопасно?

Сбрасывает к наследованию родителя. На корне данных с уникальными ACE — потеря модели. Сначала backup ACL (icacls /save).

Почему админ пишет, а пользователь нет, хотя Everyone Full на шаре?

Потому что NTFS уже уже. Effective Access для contoso\ivanov плюс share Change. Не добавляйте второго Everyone на диск.