Сетевая папка Windows Server через SMB: настройка общего доступа

«Сетевая папка не открывается, мы не можем работать!» - бухгалтерия в панике, отдел продаж подтягивается. Вы проверяете сервер - служба работает, диск на месте, NTFS-права в порядке. А потом находите: коллега из ИБ закрыл порт 445 «для безопасности» после пятничного аудита. Знакомо?

За этим портом стоит SMB - Server Message Block. Тот протокол, через который Windows Server раздаёт сетевые папки, принтеры и всё, что привыкли видеть в «Сетевом окружении». Протокол, который появился в 1983 году в лабораториях IBM и с тех пор прошёл путь от неуклюжего CIFS до зашифрованного, сжатого и работающего через QUIC транспорта.

Если вы зашли за одним конкретным ответом - вот он. SMB - сетевой протокол, по которому Windows отдаёт файлы и принтеры другим машинам. «Сетевая папка», «шара», «общий ресурс», «SMB-сервер» - это всё про него. Основной порт - TCP 445, актуальная версия протокола - SMB 3.1.1 с шифрованием AES-256. Первую версию, SMBv1, включать не надо: именно через неё в 2017-м расползся WannaCry.

SMB отвечает за всё, что связано с сетевым доступом к файлам в Windows-среде: от маппинга сетевых дисков до DFS-пространств имён и кластерных хранилищ. Даже Hyper-V использует SMB для live migration виртуальных машин между хостами. Когда говорят «сетевая папка на Windows Server» - подразумевают именно SMB, даже если не произносят этого вслух. Про то, как работает файловый сервер целиком, у нас есть отдельный разбор; здесь - про протокол и настройку.

Разберёмся, как настроить общий доступ к папкам, не наступить на грабли с правами и не оставить дыр в безопасности.

От CIFS до SMB 3.1.1: что изменилось и почему это важно

Когда Барри Фейгенбаум написал первую реализацию SMB для IBM PC DOS, протокол умел базовые вещи - открыть файл, прочитать, закрыть. К моменту, когда Microsoft переименовала SMBv1 в CIFS (1996 год), протокол раздулся до сотни с лишним команд. Работало это ровно так, как звучит - медленно и непредсказуемо, особенно через WAN.

SMB 2.0 в Windows Server 2008 стал радикальным упрощением: 100+ команд сжались до 19. Появилась конвейерная обработка запросов, и работа через VPN-каналы перестала вызывать желание перейти на FTP.

SMB 3.0 принёс Multichannel - агрегацию нескольких сетевых интерфейсов без настройки bonding. А SMB 3.1.1, актуальная версия, добавила pre-authentication integrity (защита от downgrade-атак), сжатие трафика и шифрование AES-256-GCM.

Если ваш парк серверов - Windows Server 2016 и новее, все клиенты будут согласовывать минимум SMB 3.0. Версия протокола выбирается автоматически: сервер и клиент обмениваются списком поддерживаемых диалектов при установке сессии и останавливаются на высшем общем. Проверить, какая версия используется в конкретном соединении, можно командой Get-SmbConnection на клиенте - столбец Dialect покажет 3.1.1, 3.0.2 или что-то менее приятное.

Какие порты использует SMB: 445, 139 и наследие NetBIOS

Порт 445 знают все. Проблема в том, что у SMB он не один, и когда шара не открывается, разбираться приходится со всеми.

Порты 137-139 - наследие эпохи, когда SMB ездил поверх NetBIOS, а имена машин разрешались широковещательными запросами по локальному сегменту. Начиная с Windows 2000 протокол умеет работать напрямую по TCP 445, так что при живом DNS три NetBIOS-порта обычно закрывают безболезненно. Оговорка одна: если у вас рабочая группа без DNS-сервера и машины ищут друг друга по именам через широковещание, после закрытия 137-138 они перестанут видеться в сетевом окружении - сначала проверьте на одной, потом раскатывайте. Держат эти порты открытыми чаще всего из-за старых МФУ, сканеров и NAS - тех же кандидатов, которые тянут за собой SMBv1.

Проверка доступности с клиента:

Test-NetConnection -ComputerName fs01 -Port 445

Если TcpTestSucceeded : False, дальше копать в шаре бессмысленно - разбирайтесь с файрволом, маршрутизацией или самой службой. За разрешение отвечает встроенная группа правил Windows Firewall «File and Printer Sharing (SMB-In)», включить её можно одной командой:

Enable-NetFirewallRule -DisplayGroup "File and Printer Sharing"

Мелочь, на которой спотыкается половина: имя группы локализуется. На русской Windows команда выше молча ничего не найдёт, потому что группа называется «Общий доступ к файлам и принтерам». Если не хотите гадать - подставьте вместо имени группы её системный идентификатор: Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28502". Он одинаковый на любой локали.

Правило для 445-го простое: внутри периметра - пожалуйста, наружу - ни при каких обстоятельствах (почему именно так, разбираем в разделе про безопасность). Многие провайдеры режут этот порт на своей стороне ещё до вас, и это тот редкий случай, когда стоит сказать им спасибо. Нужен доступ снаружи - VPN или SMB over QUIC. Подробнее про то, какие порты нужны файловому серверу помимо SMB, - в отдельном материале.

Зачем отключать SMBv1 и как это сделать

EternalBlue эксплуатирует ошибку в обработке пакетов SMBv1-сервером. Атакующий отправляет специально сформированный пакет на порт TCP 445 - и получает выполнение произвольного кода с системными привилегиями. Никакой аутентификации не требуется.

Microsoft отключила SMBv1 по умолчанию начиная с Windows Server 2019 и Windows 10 версии 1709. Но если вы работаете с legacy-инфраструктурой или обновляли сервер «на месте» с предыдущих версий, протокол мог остаться активным.

Проверка:

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Отключение:

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

А ещё полезная привычка - проверять, не установлена ли роль SMB 1.0/CIFS File Sharing Support в компонентах Windows. На серверах, мигрировавших с 2012 R2, она иногда остаётся как призрак прошлого.

Если SMBv1 всё-таки нужен

Ситуация знакомая: сканер на ресепшене умеет складывать документы только в SMBv1-шару, а менять его никто не будет ещё года три. Раз такое случается, разберём по порядку - как включить и чем за это придётся заплатить.

На Windows Server 2019 и новее компонента в системе физически нет, её надо доставить:

Install-WindowsFeature FS-SMB1

Если сервер не видит источник компонентов, укажите путь к установочному образу через параметр -Source. Учтите, что установка потребует перезагрузки - планируйте её на окно обслуживания, а не на среду в полдень. На клиентских Windows тот же результат даёт:

Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

После установки компонента протокол ещё нужно разрешить на уровне службы:

Set-SmbServerConfiguration -EnableSMB1Protocol $true -Force

А вот к чему включение обязывает. Вынесите такие устройства в отдельный VLAN и не поднимайте SMBv1 на том сервере, где лежат данные бухгалтерии и договоры - пусть с первой версией живёт отдельная машина с одной папкой под сканы. Включите аудит обращений (команда в разделе про безопасность ниже): через месяц будет видно, кто реально стучится по первой версии, а кто просто числится в списке по инерции. И загляните в прошивку самого устройства - у МФУ и сканеров SMB2 нередко появляется в обновлении, а у моделей, где не появился, обычно есть обходные пути вроде сканирования в SFTP или на почту.

Включать SMBv1 на файловом сервере ради одного принтера - размен так себе. Но если выбор стоит между «включить в изолированном сегменте» и «остановить работу отдела», решение очевидно, и делать вид, что такой развилки не бывает, - лукавство.

Создаём сетевую папку: Server Manager vs PowerShell

Роль File and Storage Services есть в Windows Server по умолчанию. Если нужен полный набор инструментов - добавьте компонент File Server через Server Manager → Add Roles and Features. Там же можно доставить File Server Resource Manager (FSRM) - штука полезная, если хотите квотировать дисковое пространство или блокировать сохранение .exe и .mp3 на файловых шарах.

Через GUI путь простой: Server Manager → File and Storage Services → Shares → Tasks → New Share. Wizard проведёт через выбор профиля (SMB Share - Quick или Advanced), указание пути, настройку прав. Профиль Quick создаёт шару с базовыми настройками, Advanced - позволяет сразу задать квоты, классификацию файлов и Access-Based Enumeration. На выходе - готовая шара с автоматически созданной папкой.

Но если серверов у вас пять, десять, двадцать - wizard начинает раздражать на втором. PowerShell:

# Создаём папку
New-Item -Path "D:\SharedData\Finance" -ItemType Directory

# Создаём шару с правами
New-SmbShare -Name "Finance" `
    -Path "D:\SharedData\Finance" `
    -FullAccess "DOMAIN\IT-Admins" `
    -ChangeAccess "DOMAIN\Finance-Team" `
    -ReadAccess "DOMAIN\Auditors" `
    -EncryptData $true `
    -FolderEnumerationMode AccessBased

Параметр -FolderEnumerationMode AccessBased включает Access-Based Enumeration: пользователь видит только те папки и файлы, к которым у него есть доступ. Мелочь, а избавляет от вопросов «почему мне показывает папку, которую я не могу открыть?».

Как подключиться к сетевой папке

Шара создана - теперь её надо отдать людям. Способов несколько, и выбирают по числу клиентов и по тому, что у этих клиентов за операционная система.

Разово, руками. UNC-путь в адресную строку Проводника: \\fs01\Finance. Работает всегда, ничего не настраивая, и это первое, чем стоит проверять новую шару.

Постоянный сетевой диск на одной машине. Проводник → «Этот компьютер» → «Подключить сетевой диск», либо из командной строки:

net use Z: \\fs01\Finance /persistent:yes

В PowerShell то же самое делает New-PSDrive -Name Z -PSProvider FileSystem -Root \\fs01\Finance -Persist.

Массово, на весь отдел. Логон-скрипты с net use живут в инфраструктуре десятилетиями, но правильный инструмент - групповые политики: User Configuration → Preferences → Windows Settings → Drive Maps. Диск подключается по членству в группе безопасности, отваливается вместе с ней и не требует правки скрипта при каждом кадровом изменении.

macOS. Finder → Переход → Подключение к серверу (Cmd+K) → smb://fs01/Finance. Тот же UNC-путь, только слэши в другую сторону.

Linux. Нужен пакет cifs-utils, дальше монтирование обычным mount:

sudo mount -t cifs //fs01/Finance /mnt/finance \
  -o username=ivanov,vers=3.1.1,iocharset=utf8,uid=1000,gid=1000

Параметр vers=3.1.1 стоит указывать явно: без него ядро иногда договаривается на версию ниже, чем хотелось бы. Для постоянного монтирования - запись в /etc/fstab с логином и паролем в отдельном файле credentials (права 600), а не в самой строке fstab, которую читает любой пользователь системы. Логика прав на смонтированной шаре при этом двойная - серверные NTFS-разрешения плюс локальные права точки монтирования; про вторую половину у нас есть разбор прав доступа к файлам в Linux.

Обратная ситуация - файловый сервер на Linux, клиенты на Windows - закрывается Samba. Это свободная реализация того же SMB, и для Windows-машины шара на Samba выглядит точно так же, как шара на Windows Server: тот же UNC-путь, те же порты, та же доменная аутентификация, если Samba введена в Active Directory.

А если у вас не сервер, а обычная Windows

Отдельный случай - когда «сетевая папка» нужна на рабочей станции с Windows 10 или 11. Там путь короче: правый клик по папке → Свойства → вкладка «Доступ» → «Расширенная настройка» → галочка «Открыть общий доступ» → кнопка «Разрешения». Протокол тот же SMB, порт тот же 445.

Но это рабочая группа, а не домен: права раздаются локальными учётными записями каждой машины, и синхронизировать их придётся руками. На трёх-пяти человек живёт нормально. Дальше начинается арифметика - десять сотрудников и три общие папки дают тридцать пар «учётка-разрешение», которые надо помнить. В этот момент дешевле поднять домен и раздавать доступ группами.

Share Permissions vs NTFS: вечный источник путаницы

Два уровня прав - два уровня головной боли. Share Permissions контролируют доступ по сети. NTFS Permissions - на уровне файловой системы. Когда пользователь обращается к сетевой папке, применяется пересечение этих прав, причём побеждает то, что строже.

Рабочая схема: выставляете Share Permissions в «Authenticated Users - Full Control» и управляете доступом исключительно через NTFS. Два параллельных набора правил - гарантированный путь к ситуации, когда «у Иванова доступ есть, а у Петровой нет, хотя они в одной группе».

Ещё один нюанс, который регулярно ломает голову: при подключении через UNC-путь (\\server\share) срабатывают оба уровня. Но если зайти на сервер локально - Share Permissions игнорируются, работают только NTFS. Поэтому тестировать права нужно именно через сеть, с клиентской машины, под учётной записью целевого пользователя. Утилита Effective Access во вкладке Security → Advanced покажет итоговый набор разрешений - экономит время вместо ручного разбора наследования.

Безопасность: шифрование, подписи, rate limiting

SMB 3.0+ умеет шифровать трафик на уровне протокола - без IPsec, без VPN, без дополнительных сертификатов. Windows Server 2022 поддерживает AES-256-GCM и AES-256-CCM. Сервер и клиент согласовывают алгоритм автоматически, выбирая доступный с обеих сторон.

Подписывание пакетов (SMB Signing) защищает от подмены данных в транзите. Windows 11 24H2 сделала signing обязательным для всех исходящих SMB-подключений. Если в сети остались устройства со старой прошивкой или Samba ниже 4.6 - они перестанут подключаться. Решение: обновить или добавить исключение через групповую политику.

Ещё одна деталь - rate limiter аутентификации. Windows Server вставляет двухсекундную задержку после неудачной попытки входа. Это не панацея от brute-force, но снижает скорость перебора до уровня «нерентабельно». Настраивается через реестр или GPO, а в связке с политиками блокировки учётных записей даёт неплохой эшелон защиты.

Отдельный момент - Windows Firewall. Порт TCP 445 по умолчанию закрыт для внешних подключений. Не открывайте его наружу - никогда. Если нужен удалённый доступ к файлам, используйте VPN или SMB over QUIC (о нём ниже). Открытый 445-й порт в интернете - это не вопрос «будут ли ломать», а вопрос «через сколько минут».

Аудит обращений к SMBv1 (если он ещё включён):

Set-SmbServerConfiguration -AuditSmb1Access $true

После включения события пишутся в журнал Applications and Services → Microsoft → Windows → SMBServer → Audit. Так вы узнаете, какие клиенты до сих пор стучатся по первой версии протокола. Смежная задача - понимать, кто и что делает с самими файлами внутри шары: это уже аудит файлов на файловом сервере, настраивается отдельно через SACL и политики.

Multichannel, сжатие и производительность

SMB Multichannel включается автоматически, если у сервера и клиента есть несколько сетевых интерфейсов или один интерфейс с RSS. Никакого NIC teaming настраивать не надо - протокол сам открывает параллельные соединения и балансирует нагрузку. Допустим, у файлового сервера два 10GbE-порта - SMB Multichannel задействует оба и даст агрегированную пропускную способность 20 Гбит/с без какой-либо настройки со стороны администратора. Если один интерфейс упадёт - трафик автоматически пойдёт через оставшийся. Отказоустойчивость бесплатно.

Проверить активные каналы:

Get-SmbMultichannelConnection

Из Multichannel растёт и SMB Direct - режим, в котором данные передаются напрямую в память принимающей стороны, минуя процессор. Нужны сетевые карты с поддержкой RDMA: iWARP, RoCE или InfiniBand. Отдельно включать ничего не надо - Multichannel сам обнаруживает такие адаптеры и переключается на них. Проверить, что карта опознана правильно, можно командой Get-SmbClientNetworkInterface - в выводе есть колонка RdmaCapable.

Смысл в этом появляется не всегда. На гигабите и на обычных 10GbE процессор и так справляется, а RDMA-карты стоят заметно дороже обычных. Оправдан SMB Direct начиная примерно с 25 Гбит и в сценариях, где сеть уже упирается в процессор: Storage Spaces Direct, хранилище под Hyper-V, тяжёлые базы. На этом месте обычно спотыкаются при домашних тестах: клиентские Windows умеют быть только клиентом SMB Direct. Сервером - нет, для серверной стороны нужна Windows Server. Да и клиентская часть есть не в каждой редакции: Enterprise, Education и Pro for Workstations поддерживают её давно, обычная Pro - только с 22H2 и только при чистой установке, а не после апгрейда с младшей версии.

Сжатие трафика (SMB Compression) появилось в Windows Server 2022. Алгоритм XPRESS (LZ77) применяется к файлам при передаче - экономит полосу на медленных каналах. Включается на уровне шары:

New-SmbShare -Name "Archive" -Path "D:\Archive" -CompressData $true

Или для существующей шары:

Set-SmbShare -Name "Archive" -CompressData $true -Force

На 100-гигабитных линках между серверами с NVMe-массивами выигрыш от сжатия минимален - процессорные циклы на компрессию съедят экономию. А вот на гигабитном канале до филиала разница заметна, особенно при передаче текстовых файлов и баз данных.

SMB over QUIC: доступ без VPN

SMB over QUIC - альтернатива классическому TCP-транспорту. Вместо порта TCP 445 используется UDP 443 с обязательным TLS 1.3. Фактически это VPN-туннель, встроенный в сам протокол: весь SMB-трафик, включая аутентификацию, идёт внутри зашифрованного QUIC-соединения.

Зачем это нужно: удалённые сотрудники получают доступ к файловым шарам без корпоративного VPN. Порт 443 открыт в большинстве сетей, включая гостиничные Wi-Fi и мобильные хотспоты. Все привычные функции SMB - signing, compression, multichannel - работают внутри QUIC-туннеля без изменений.

Ограничение: в Server 2022 SMB over QUIC доступен только в Datacenter: Azure Edition. В Windows Server 2025 поддержка расширена на стандартные редакции. Клиентская часть требует Windows 11.

Настройка требует TLS-сертификат на сервере. QUIC-соединение начинается с TLS 1.3 handshake - без валидного сертификата клиент просто не подключится. Для доменных сред подойдёт внутренний CA (AD CS), для внешнего доступа - публичный сертификат. На клиенте подключение выглядит так:

New-SmbMapping -RemotePath "\\fs01.contoso.com\Data" -TransportType QUIC

Или через net use:

net use Z: \\fs01.contoso.com\Data /TRANSPORT:QUIC

QUIC использует UDP, поэтому файрволы, настроенные на пропуск только TCP, заблокируют трафик. Убедитесь, что UDP 443 открыт на всём пути от клиента до сервера.

Scale-Out File Server: когда одного сервера мало

Для Hyper-V кластеров, VDI и нагруженных файловых сервисов есть Scale-Out File Server (SOFS). Это кластерная роль, где CSV-тома (Cluster Shared Volumes) обслуживаются всеми нодами одновременно. Клиент подключается к кластерному имени, а не к конкретному серверу, и получает автоматический failover.

SOFS работает поверх SMB 3.0+ и активно использует Multichannel и SMB Direct (RDMA). Если вы строите инфраструктуру с Storage Spaces Direct - SOFS становится логичным способом раздать хранилище по сети.

Для VDI-сценариев SOFS особенно хорош: сотни виртуальных рабочих столов обращаются к VHDX-файлам через SMB, а кластер распределяет нагрузку между нодами. При выходе одной ноды из строя клиенты переключаются на другую без разрыва сессии - Continuous Availability в SMB 3.0 обеспечивает persistent handles, которые переживают failover. Если до полноценного SOFS вы ещё не доросли, а простой терпеть нельзя, промежуточный вариант - отказоустойчивый файловый сервер на классическом кластере Windows.

Troubleshooting: когда шара не работает

Три команды, которые экономят часы:

# Статус SMB-сервера и его настроек
Get-SmbServerConfiguration

# Список активных сессий - кто подключён прямо сейчас
Get-SmbSession

# Открытые файлы - кто что держит
Get-SmbOpenFile

Event ID 1020 в журнале SMBServer/Operational - клиент отключён по таймауту. Event ID 551 - ошибка аутентификации. Если видите высокую загрузку CPU на srv.sys - скорее всего, signing или encryption перегружают процессор. Решение: RDMA-карты с аппаратным offload или пересмотр политики шифрования для внутренних сегментов.

Классическая проблема: пользователь не может подключиться к шаре, ошибка «Access Denied». Алгоритм диагностики: сначала проверяете Test-NetConnection -ComputerName server -Port 445 - убеждаетесь, что порт доступен. Потом Get-SmbShareAccess -Name "ShareName" - смотрите Share Permissions. Затем icacls D:\SharedData\Finance - проверяете NTFS. В 80% случаев проблема именно в рассогласовании этих двух слоёв.

Для глубокой диагностики есть встроенная трассировка:

netsh trace start scenario=FileSharing capture=yes
# воспроизводите проблему
netsh trace stop

На выходе - ETL-файл, который открывается в Microsoft Message Analyzer или Wireshark с плагином. Трассировка покажет каждый SMB-запрос с таймингами - удобно для отлова проблем с latency, когда шара «вроде работает, но Word открывает файл по 30 секунд». Не забудьте остановить трассировку после воспроизведения проблемы - файл растёт быстро и может съесть диск, если оставить его работать.

Короткие ответы на частые вопросы

Какой порт нужен для SMB?
TCP 445 - основной и единственный обязательный. Порты TCP 139 и UDP 137-138 нужны только для устройств, работающих через NetBIOS. SMB over QUIC вместо 445 использует UDP 443.

Чем CIFS отличается от SMB?
CIFS - это имя, которое Microsoft дала первой версии SMB в 1996 году. То есть CIFS = SMBv1, и сегодня это скорее исторический термин. Когда в настройках Linux или NAS встречается «CIFS», речь почти всегда про современный SMB - название просто прижилось.

Как узнать, какая версия SMB используется?
На клиенте - Get-SmbConnection, колонка Dialect. На сервере список активных сессий с версиями покажет Get-SmbSession.

Безопасно ли открывать порт 445 в интернет?
Нет. Это прямая цель для сканеров и эксплойтов, а логика 445-го порта не рассчитана на враждебную сеть. Для доступа снаружи используйте VPN или SMB over QUIC.

Почему сетевая папка видна, но не открывается?
Чаще всего - рассогласование Share Permissions и NTFS: сама шара видна, потому что права на уровне SMB есть, а файловая система доступ не даёт. Проверьте оба уровня через Get-SmbShareAccess и icacls.

Можно ли подключить шару Windows Server из Linux или macOS?
Да, SMB кроссплатформенный. В macOS - smb://сервер/шара через Finder, в Linux - mount -t cifs из пакета cifs-utils. Обратная задача, шара на Linux для Windows-клиентов, решается через Samba.

Что дальше

SMB никуда не уходит. Протоколу 40 с лишним лет, и за это время он пережил NetBIOS, WannaCry, миграцию в облако - и стал только крепче. QUIC-транспорт, обязательное шифрование, интеграция с кластерными хранилищами - всё это говорит об одном: файловый доступ по SMB остаётся фундаментом Windows-инфраструктуры.

Samba уже работает над поддержкой QUIC в Linux, а Microsoft продолжает добавлять возможности в Windows Server 2025. Вопрос не в том, использовать ли SMB, а в том, какую версию и с какими настройками безопасности. Если в вашей инфраструктуре до сих пор жив SMBv1 - сегодня хороший день, чтобы это исправить.