Файловый сервер медленно открывает папки: не лечить «сеть» вслепую

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

Медленное открытие каталога — не то же, что «нет доступа». Замерьте: по \\IP\share vs \\FS01.contoso.example\data, с отключённым первым сканированием антивируса на клиенте и сервере в тест-окне, размер каталога и Access-Based Enumeration. Часто виноваты таймауты DNS/PTR, перечисление ACL, DFS-реферал, не «гигабит сломался».

Полный отказ SMB — другая статья.

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

• Проводник крутится 20–90 секунд на \\contoso.example\dfs\data.
• dir \\FS01\data в cmd тоже медленный — не только оболочка.
• По IP мгновенно — почти наверняка имя/DFS/Kerberos/SPN, не диск.

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

1. Клиент ждёт PTR/имя сервера (суффикс, WINS нет, DNS таймаут).
2. Антивирус на лету на шаре (особенно архивы, много мелких файлов).
3. ABE + глубокое дерево + медленный DC для групп.
4. Каталог на сотни тысяч inode без индекса.
5. DFS Namespace: мёртвый таргет, долгий реферал.
6. SMB signing + слабый CPU на мелких файлах (реже на 2022/2025).
7. Short name / 8.3 на огромных папках.
8. Сеть: дуплекс, потери; проверяется после исключения 1–5.

Диагностика

Get-SmbShare -CimSession FS01 | Format-Table Name, Path, FolderEnumerationMode, CachingMode
Get-SmbConnection
Resolve-DnsName FS01.contoso.example
Resolve-DnsName 10.0.10.10 -ErrorAction SilentlyContinue

Сравните время:

Measure-Command { Get-ChildItem '\\FS01.contoso.example\data' | Select-Object -First 50 }
Measure-Command { Get-ChildItem '\\10.0.10.10\data' | Select-Object -First 50 }

DFS:

dfsdiag /testreferral /dfspath:\\contoso.example\public\data

ABE: FolderEnumerationMode AccessBased vs Unrestricted. Журнал SMB-клиента на WS-042:

Get-WinEvent -LogName 'Microsoft-Windows-SMBClient/Connectivity' -MaxEvents 20 -ErrorAction SilentlyContinue

На сервере: CPU Defender при открытии папки (Task Manager / Performance). Не отключайте AV навсегда — тест с исключением пути в окно.

Решение

Сценарий A. Имя медленное, IP нет

Почините DNS/суффикс клиента, PTR если приложения его ждут, SPN HOST/FS01.contoso.example. Не учите пользователей ходить по IP как норме.

Сценарий B. Антивирус

Исключения по рекомендации вендора для шары (не весь C:). На DC не отключайте Defender. Сравните до/после Measure-Command.

Сценарий C. ABE и ACL

ABE полезен, но на папке с тысячами уникальных ACE каждый List = запросы. Упростите группы, не «Everyone Full на NTFS». См. эффективные права.

Сценарий D. DFS

Мёртвый folder target даёт таймаут. См. пространство имён и backlog DFSR.

Сценарий E. Огромный каталог

Дробить дерево, не «оптимизировать SMB1». SMB1 не включать.

Сценарий F. Секундомер, PTR и перечисление

Снимите три замера с WS-042 (холодный кэш: новый сеанс или klist purge не обязателен, важнее не открывать папку перед тестом):

Measure-Command { Get-ChildItem '\\FS01.contoso.example\data' | Select-Object -First 100 }
Measure-Command { Get-ChildItem '\\10.0.10.10\data' | Select-Object -First 100 }
Get-SmbShare -CimSession FS01 -Name data | Format-List Name, Path, FolderEnumerationMode

Если FQDN на 20+ секунд медленнее IP — смотрите DNS-суффикс, таймаут форвардера на несуществующем PTR, DFS. Resolve-DnsName FS01.contoso.example должен быть мгновенным; если A-запись идёт через внешний форвардер, чините DNS домена.

ABE: каждый ListDir для пользователя без прав на соседние папки — запрос к ACL и часто к DC за группами. На каталоге с тысячами уникальных ACE это секунды. Сравните того же пользователя с временным Unrestricted на тестовой шаре.

Антивирус: смотрите CPU процесса защиты в момент открытия. Исключение — путь шары по гайду Microsoft File Server, не C:\Windows. После теста верните полную проверку.

8.3: на огромных каталогах fsutil 8dot3name query D: — если создание коротких имён включено, создание файла тормозит; для существующих List это слабее, но на смешанных нагрузках заметно. Не выключайте 8.3 вслепую на томе, где зависят старые приложения.

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

Повторите Measure-Command с WS-042 по FQDN. Первый и второй заход приемлемы по вашему SLO. С другого сайта — отдельно (DFS site costing). Антивирус Enabled. Пользователь открывает ту же папку в проводнике.

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

• Только Office/Excel: блокировки файлов, не ListDir.
• VPN без DNS суффикса — таймауты имени.
• Кластер / CSV под нагрузкой — смотрите диск, не SMB-подпись первой.
• Редирект папок на тот же медленный корень — двойной удар.

Снимите трассу только метаданных: Measure-Command на Get-ChildItem без копирования гигабайт. Если большой файл копируется быстро, а папка из 50 тысяч имён — нет, вы в перечислении/ABE/AV, не в «гигабите». Проверьте, не указывает ли ярлык на DFS с мёртвым таргетом. На DC не отключайте Defender ради теста шары SYSVOL.

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

• Мониторинг времени List на эталонной папке.
• Исключения AV по гайду Microsoft для file server role.
• DFS: здоровые таргеты, не один мёртвый в списке.
• Не складывать миллион файлов в один каталог.
• DNS AD-зоны без таймаутов до внешних форвардеров на внутренние имена.
• Эталонная папка для замера: несколько сотен файлов, не корень с сотней тысяч. После изменений AV или ABE повторяйте холодный Measure-Command с WS-042, не с консоли FS01.

FAQ

Почему второй клик быстрый?

Кэш реферала DFS, кэш SMB, кэш AV. Диагностируйте холодный заход.

Отключить ABE?

Как тест — да. Как постоянный фикс — только если понимаете, что пользователи увидят чужие имена папок.

Сетевая карточка 100 Мбит виновата?

При List мелких метаданных чаще CPU/AV/DC, не канал. Измеряйте копию большого файла отдельно.

Нужно ли SMB1 для «старых сканеров»?

Отдельный риск и другая статья. На скорость проводника современного клиента SMB1 не ответ.

Get-SmbShare не показывает ABE?

Смотрите FolderEnumerationMode и свойства шары в оснастке. PowerShell модуль Storage/SmbShare должен быть загружен.

Почему по IP быстро, а по DFS-имени нет?

Реферал, DNS и SPN, не «диск FS01». Сверьте Measure-Command к \\FS01\data и к \\contoso.example\public\data. Если прямой UNC быстрый, чините DFS, не антивирус на томе. Холодный замер делайте в новом сеансе, иначе кэш SMB врёт.