Виправити «Вказана мережна назва більше не доступна» в SMB

February 26, 2026 • February 26, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Ви копіюєте великий файл на шаринг. Або запускаєте збірку, що отримує вигоду від дрібних I/O. Або відкриваєте гігантську Excel з мережевого диска. І раптом — бах — Windows видає: «Вказана мережна назва більше не доступна.» Шер пропадає під час операції, програми зависають, і всі звинувачують «мережу».

Ця помилка — симптом, а не діагноз. Вона може означати все: від поганого кабелю до контролера зберігання, який ввічливо перезавантажився. Гарна новина: SMB розмовляє багато, Windows логує багато, і ви можете швидко звузити сферу пошуку — якщо перестанете гадати й почнете вимірювати.

Що насправді означає ця помилка (і чого вона не означає)

Windows показує «Вказана мережна назва більше не доступна» коли операція SMB зазнає невдачі, бо підлягаюче з’єднання/сесія із сервером більше не придатні. У термінах Win32 це часто з’являється як System error 64 (ERROR_NETNAME_DELETED) або іноді суміжні помилки залежно від точки виклику та настрою редиректора.

Чого це не означає: чиста ситуація «шер не знайдено» або «помилкові облікові дані». Ви цілком можете отримати цю помилку навіть якщо:

DNS правильний
Сервер «живий» (ping працює, RDP працює)
Шер існує і дозволи в порядку

Що це часто є: SMB було відключено. Іноді ввічливо (таймаут), іноді різко (TCP RST), іноді через «допомогу» проміжного пристрою. SMB працює поверх TCP (звично 445). Якщо TCP скидається, NAT-мапінги закінчуються, фаєрвол розриває бездіяльні потоки або сервер рве сесію через тиск ресурсів, наступна файлова операція клієнта може вибухнути цим повідомленням.

Будьте дисципліновані щодо своєї ментальної моделі:

Повідомлення SMB = додаток, який говорить із Windows-редиректором.
Збій редиректора = сесія/з’єднання SMB недійсні.
Корінна причина = десь між додатком ↔ ОС клієнта ↔ NIC ↔ комутатор ↔ фаєрвол ↔ сервер ↔ зберігання.

Одне зауваження, щоб не губитися: Надія — не стратегія. (парафразована ідея, яку часто приписують операційним лідерам; сприймайте як нагадування, а не догму.)

Швидкий план діагностики

Якщо ви відповідаєте за продакшен, ви не починаєте з крутіння в реєстрі. Ви починаєте з того, щоб знайти де відбувається відключення.

По-перше: підтвердіть, що це відключення, а не права доступу

Швидко відтворіть проблему простим тестом копіювання і зафіксуйте часову позначку.
Перегляньте журнали Windows навколо цієї часової позначки для подій SMB Client/Server.
Підтвердіть транспорт: SMB по TCP/445 (а не якийсь застарілий шлях) і яка діалектна версія SMB погоджена.

По-друге: вирішіть, чи мережа чи сервер обірвали сесію

Шукайте TCP RST і патерни «connection closed» (запис клієнта або сервера).
Перевірте таймаути бездіяльності на фаєрволах/балансувальниках/VPN. «Виникає лише після 10–30 хвилин бездіяльності» — майже зізнання.
Перевірте здоров’я сервера: CPU в піку, тиск пам’яті, флапи NIC, стрибки затримки зберігання, відмови кластера.

По-третє: звузьте до одного з великих блоків

Клієнтська сторона: баги драйвера NIC, offload-функції, сон/modern standby, агресивні налаштування енергозбереження, драйвери фільтрів антивірусу.
Мережа: невідповідність MTU, асиметрія ECMP + станний фаєрвол, закінчення NAT, мікро-і втрати пакетів, проблеми дуплексу, переміщення Wi‑Fi.
SMB-стек на сервері: виснаження ресурсів, некоректні обробки oplock/lease, накладні витрати підпису/шифрування плюс голодування CPU, перезапуск служби.
Зберігання: I/O-стали призводять до того, що SMB-сервер не відповідає; клієнти таймаутять і відключаються.

Практичне правило: якщо одночасно відключається кілька клієнтів, підозрюйте сервер/мережу. Якщо це один клієнт — спочатку перевірте шлях клієнта.

Жарт №1 (короткий, по темі): помилки SMB як проблеми з принтером — всі звинувачують мережу, і іноді мережа справді винна.

Цікавинки та історичний контекст

SMB старший за сучасний інтернет. Родовід протоколу сягає IBM і 1980-х, а Microsoft значно розширив його.
CIFS — це ера «маркетингової назви» SMB. У 1990-х «CIFS» був поширеним для поведінки SMB1, особливо через NetBIOS-шляхи.
SMB1 через свою розмовність був уразливий на нестабільних лінках. Багато раундів, обмежений pipelining і семантика, що погано узгоджується з сучасними мережами.
SMB2 (Vista/Server 2008) був великим перезапуском. Він зменшив розмовність і покращив продуктивність; багато «випадкових відключень» зникають після переходу з SMB1.
SMB3 додав шифрування і multichannel. Це корисно для безпеки та пропускної здатності, але додає більше складних компонентів (кілька TCP-з’єднань, крипто-навантаження на CPU).
Oplock еволюціонували в leases. Вони покращують кешування клієнта, але можуть погано взаємодіяти з нестабільним з’єднанням і деякими AV/фільтр-драйверами.
Durable handles були створені для перепідключення. SMB2/3 може відновлювати файлові дескриптори після транзитних відключень, але лише якщо сервер/клієнт та налаштування шарінгу це підтримують.
«Error 64» часто з’являється, коли сервер закриває tree connect. Користувач бачить «мережна назва більше не доступна», навіть якщо мережа в порядку; сесія стала недійсною.
Сучасний Windows віддає перевагу TCP/445 напряму. NetBIOS через TCP/139 ще зустрічається в темних куточках, але це не оптимальний шлях.

Де зазвичай живе відмова: клієнт, мережа, сервер, зберігання

Клієнтські режими відмови

Проблеми на клієнті часті, бо одна машина може бути «особливою» у багатьох вимірах: інший драйвер NIC, інший енергетичний профіль, інший VPN, інший AV. Типові підозрювані:

Баги драйвера NIC, які викликають зависання/скидання TCP під навантаженням.
Offload-функції (LSO/TSO, checksum offload, RSS, RSC), що погано взаємодіють з певними комутаторами або гіпервізорами.
Керування енергоспоживанням: Modern Standby, sleep, selective suspend, «energy efficient ethernet». SMB не любить, коли NIC зникає.
Фільтр-драйвери: антивірус, DLP-агенти, «прискорювальне» мережеве ПЗ, локальні фаєрволи.

Мережеві режими відмови

SMB чутливий до втрат, стрибків латентності і станних проміжних пристроїв. Це не унікально, але SMB робить проблему помітною, бо користувачі працюють із файлами в реальному часі.

Таймаути бездіяльності на фаєрволах/NAT/VPN, які рвуть тихі TCP-потоки.
Невідповідність MTU що призводить до фрагментації/чорних дір, особливо при неправильно налаштованих jumbo frames.
Асиметрична маршрутизація через станний фаєрвол: зворотний трафік іде іншим шляхом, фаєрвол відкидає його, SMB вмирає.
Мікросплески втрат пакетів на оверсабскрайблених лінках; TCP виживає, але SMB-операції таймаутять.
Роумінг Wi‑Fi, коли IP зберігається, але шлях змінюється; довготривалі TCP-сесії не завжди переживають таке.

Серверні режими відмови SMB

Windows Server, Samba і NAS-пристрої можуть рвати сесії під певним навантаженням:

Перезапуск служби SMB або перезавантаження сервера (планове чи «непланове»).
Фейловер кластера з некоректною налаштуванням continuous availability або клієнтами, що не перепідключаються чисто.
Голодування CPU від шифрування/підписування SMB або «шумних сусідів».
Ліміти сесій SMB або тиск пам’яті, що змушує сервер термінувати з’єднання.

Режими відмови на стороні зберігання

Зберігання — це місце, де «мережева назва недоступна» стає неправдою з пропуском інформації. Мережа може бути в порядку, а SMB-сервер заблокований на I/O:

Висока латентність (метадані, дрібні випадкові I/O) викликає таймаути SMB-запитів.
Фейловер контролера або фейловер шляхів, що викликає прочій стоп.
Снапшоти, сканування антивірусом або завдання tiering що б’ють по метаданих.
Проблеми файлової системи що спричиняють паузи, відновлення або блокування.

Практичні завдання: команди, виводи та рішення

Нижче — 14 реальних завдань, які ви можете виконати сьогодні. Кожне містить команду, приклад виводу, що означає цей вивід, і рішення, яке слід прийняти. Оберіть підмножину, що відповідає вашому середовищу: клієнт Windows, файловий сервер Windows, Samba/NAS і мережа між ними.

Task 1 — Confirm the error code and capture the exact timestamp

On the affected Windows client, reproduce the failure and immediately check recent SMB client events.

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-SMBClient/Connectivity'; StartTime=(Get-Date).AddMinutes(-30)} | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List -Force"
TimeCreated : 2/5/2026 10:14:22 AM
Id          : 30805
LevelDisplayName : Error
Message     : The client lost its connection to the server. Error: The specified network name is no longer available.

TimeCreated : 2/5/2026 10:14:22 AM
Id          : 30806
LevelDisplayName : Warning
Message     : The connection to the share was lost.

Значення: У вас є доказ, що це втрата зв’язку/сесії, а не проблема тільки додатку.

Рішення: Зкорелюйте цю часову позначку з логами сервера і мережевими подіями. Поки нічого не «чіпайте».

Task 2 — Verify SMB dialect, encryption, signing, multichannel

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,NumOpens,Encrypted,Signed,Multichannel | Format-Table -Auto"
ServerName ShareName Dialect NumOpens Encrypted Signed Multichannel
---------- --------- ------- -------- --------- ------ ------------
FS01       data      3.1.1       12     False   True        True

Значення: Працює SMB 3.1.1; підписування ввімкнено; multichannel активний.

Рішення: Якщо multichannel увімкнено і у вас кілька NIC/VLAN, підозрюйте асиметрію шляхів або баги NIC/offload. Якщо шифрування увімкнено і CPU високий — підозрюйте перенавантаження CPU на сервері.

Task 3 — Check if the client is using a stale mapped drive session

cr0x@server:~$ powershell -NoProfile -Command "net use"
New connections will be remembered.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
OK           Z:        \\FS01\data               Microsoft Windows Network
The command completed successfully.

Значення: Мапінг диска існує; зараз статус OK.

Рішення: Якщо помилки виникають після бездіяльності — ви маєте справу з таймаутами. Якщо під навантаженням — шукайте втрати/латентність/CPU/I/O.

Task 4 — Force a clean reconnect (quick sanity test)

cr0x@server:~$ powershell -NoProfile -Command "net use Z: /delete /y; net use Z: \\FS01\data /persistent:no"
Z: was deleted successfully.
The command completed successfully.

Значення: Ви видалили мапінг і створили його знову.

Рішення: Якщо це тимчасово «виправляє», це підказка: сесії інвалідуються. Тепер шукайте, чому сесії обриваються.

Task 5 — Check basic network quality: loss and latency spikes

cr0x@server:~$ powershell -NoProfile -Command "Test-Connection -ComputerName FS01 -Count 50 | Measure-Object -Property ResponseTime -Average -Maximum -Minimum"
Count    : 50
Average  : 2.14
Maximum  : 28
Minimum  : 1

Значення: Середня латентність в порядку, але максимум стрибає до 28 мс. Це може бути нормою в LAN або симптомом, якщо стрибки корелюють з відключеннями.

Рішення: Якщо бачите таймаути або великі стрибки — розслідуйте перевантаження мережі, роумінг Wi‑Fi або перевантажений VPN.

Task 6 — Confirm DNS and avoid “it resolves on my machine” debates

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FS01 | Select-Object Name,IPAddress"
Name IPAddress
---- ---------
FS01 10.20.30.40

Значення: DNS показує 10.20.30.40.

Рішення: Якщо сервер кластеризований або за VIP, підтвердіть, що IP правильний і стабільний. Якщо DNS повертає кілька IP і лише один некоректний — ви знайшли цікаву проблему.

Task 7 — Check the server’s SMB server events (Windows Server)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-SMBServer/Operational'; StartTime=(Get-Date).AddHours(-2)} | Select-Object TimeCreated,Id,LevelDisplayName,Message | Select-Object -First 5 | Format-List -Force"
TimeCreated : 2/5/2026 10:14:21 AM
Id          : 1006
LevelDisplayName : Warning
Message     : The server terminated the connection from client 10.20.30.91 due to an internal error.

Значення: Сервер термінував з’єднання. Це дуже важливий індикатор: це не клієнт «вирішив» піти.

Рішення: Розслідуйте тиск ресурсів сервера, баги SMB-сервера або латентність зберігання. Якщо сервер пише «internal error», це рідко проблема прав клієнта.

Task 8 — Check server CPU, memory pressure, and SMB counters quickly

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(_Total)\% Processor Time','\Memory\Available MBytes','\SMB Server Shares(*)\Avg. sec/Read','\SMB Server Shares(*)\Avg. sec/Write' -SampleInterval 2 -MaxSamples 3 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
Path                                                     CookedValue
----                                                     -----------
\\server\processor(_total)\% processor time               92.1
\\server\memory\available mbytes                          310.0
\\server\smb server shares(data)\avg. sec/read            0.185
\\server\smb server shares(data)\avg. sec/write           0.240

Значення: CPU дуже завантажений і часи обслуговування SMB I/O — сотні мілісекунд. Це не «мережа». Це біль сервера або зберігання.

Рішення: Якщо CPU завантажений — перевірте накладні витрати шифрування/підписування, сканування антивірусу на сервері або процес, що губить ресурси. Якщо латентність чит/запис висока — переходьте до метрик зберігання.

Task 9 — Verify whether SMB encryption/signing policy changed recently

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EncryptData,EnableSecuritySignature,RequireSecuritySignature | Format-List"
EncryptData              : False
EnableSecuritySignature  : True
RequireSecuritySignature : True

Значення: Підписування вимкнено як опція, але в вимогах підписування вмонтоване. Це нормально у багатьох середовищах, але має CPU-витрати з обох сторін.

Рішення: Не відключайте підписування як «виправлення», якщо ви не розумієте безпекову політику. Якщо потрібно змінити — робіть це усвідомлено і вимірюйте CPU до/після.

Task 10 — Look for NIC flaps or link resets on Windows Server

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Id=27,32,10400,10401; StartTime=(Get-Date).AddDays(-1)} | Select-Object TimeCreated,Id,ProviderName,Message | Format-Table -Auto"
TimeCreated            Id ProviderName               Message
-----------            -- ------------               -------
2/5/2026 10:13:58 AM   27 e1rexpress                Network link is disconnected.
2/5/2026 10:14:02 AM   27 e1rexpress                Network link has been established at 10 Gbps.

Значення: NIC сервера відключав і знову з’єднав лінк. SMB-сесії цього не люблять, і це виправдано.

Рішення: Припиніть звинувачувати SMB. Виправте NIC/порт комутатора/кабель/драйвер. Також перевірте налаштування energy efficient ethernet і несумісність прошивок.

Task 11 — On Linux/Samba server: confirm Samba logs and live sessions

cr0x@server:~$ sudo smbstatus --shares
Service      pid     Machine       Connected at                     Encryption   Signing
------------------------------------------------------------------------------------------
data         2143    10.20.30.91   Tue Feb  5 10:10:12 2026 UTC     -            SMB3_11

Значення: Клієнт підключений; підписування узгоджено; шифрування не використовується.

Рішення: Якщо сесії зникають під час відмов, перевірте логи Samba і системні логи на предмет причин відключення, аварій або лімітів ресурсів.

Task 12 — On Linux/Samba server: check kernel and Samba messages around the incident

cr0x@server:~$ sudo journalctl -u smbd --since "2026-02-05 10:00:00" --until "2026-02-05 10:30:00" | tail -n 20
Feb 05 10:14:21 nas01 smbd[2143]: smbd_smb2_request_error_ex: client disconnected while processing request
Feb 05 10:14:21 nas01 smbd[2143]: closing connection to client 10.20.30.91 due to I/O timeout

Значення: Samba повідомляє про I/O таймаут. Зазвичай це латентність зберігання або завислий файловий виклик, а не «дивний SMB».

Рішення: Йдіть до зберігання: перевірте iostat, multipath, бекенд NFS (якщо є), RAID-контролер або затримки ZFS.

Task 13 — On Linux server: measure storage latency and saturation

cr0x@server:~$ iostat -xz 2 3
Linux 6.5.0 (nas01)     02/05/2026      _x86_64_    (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    8.40   21.30    0.00   58.20

Device            r/s     w/s    rkB/s    wkB/s  rrqm/s  wrqm/s  %util  await  r_await  w_await
nvme0n1         950.0   620.0  38000.0  54000.0     0.0     0.0   99.0   38.2     28.1     53.6

Значення: Пристрій практично зафіксований (%util ~99) і await — десятки мілісекунд. Для SMB, що обслуговує метаданні-навантаження, це катастрофічно.

Рішення: Зменшіть навантаження, додайте потужності/IOPS, зупиніть runaway job або налаштуйте робоче навантаження (відокремте метадані, додайте кеш, виправте сканування AV, призупиніть хвилю snaphot-операцій).

Task 14 — Capture TCP resets and retransmits (Linux side) when you suspect the network

cr0x@server:~$ sudo tcpdump -nn -i eth0 host 10.20.30.91 and port 445 -c 20
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
20 packets captured
10:14:21.120345 IP 10.20.30.91.51562 > 10.20.30.40.445: Flags [P.], seq 12345:12412, ack 9988, win 1024, length 67
10:14:21.130112 IP 10.20.30.40.445 > 10.20.30.91.51562: Flags [R.], seq 9988, ack 12412, win 0, length 0

Значення: Сервер відправив TCP RST. Це жорсткий скидання, а не тихий таймаут.

Рішення: Якщо сервер скидає з’єднання — розслідуйте стек сервера (впадіння процесу/перезапуск, фаєрвол на сервері, завершення служби SMB). Якщо проміжний пристрій інжектить RST — знайдіть його за допомогою зняттів на обох боках.

Жарт №2 (короткий, по темі): Фаєрвол з «агресивною політикою таймаутів» — як колега, що завершив зустріч раніше: продуктивно, поки вам не потрібні останні п’ять хвилин.

Типові помилки: симптом → корінна причина → виправлення

Цей розділ окупається сам: шаблони, що повторюються — ті самі симптоми, ті самі хибні припущення, ті самі уникнені прості помилки.

1) «Виникає рівно через 15 хвилин бездіяльності» → таймаут фаєрволу/NAT → збільшити таймаути або keepalive

Симптом: Мапінги дисків виглядають нормально, але відкриття файлу після обіду зазнає невдачі; перепідключення працює одразу.
Корінна причина: Станний пристрій рве бездіяльні TCP-сесії; keepalive SMB недостатньо часті, щоби тримати стан.
Виправлення: Збільшіть TCP idle timeout для 445 на фаєрволі/VPN/NAT. Якщо не можна — налаштуйте keepalive клієнта SMB або переробіть підхід (уникати довготривалих сесій через NAT/VPN для інтенсивної роботи з файлами).

2) «Тільки ноутбук одного користувача» → драйвер NIC/offload/енергозбереження → оновити драйвер, відключити проблемні offload

Симптом: Той самий шер, той самий сервер, одна машина постійно відключається.
Корінна причина: Баг драйвера NIC або енергоменеджмент вимикає NIC; offload-функції конфліктують з мережею.
Виправлення: Оновіть драйвер/прошивку NIC, відключіть selective suspend, протестуйте послідовно відключення LSO/RSC/RSS і валідуйте результат packet capture.

3) «Почалося після увімкнення шифрування SMB везде» → вузьке місце CPU → планування потужностей або селективне шифрування

Симптом: Під навантаженням клієнти відключаються; CPU сервера високий; пропускна здатність гірша.
Корінна причина: Накладні витрати шифрування на сервері/клієнтах; SMB-сервер без CPU не встигає відповісти.
Виправлення: Виміряйте CPU, використовуйте апаратний AES-NI, обмежте шифрування для критичних шарів або масштабуйтесь. Не вважайте криптооперації безкоштовними.

4) «Випадково під час великих копій» → невідповідність MTU / неповні jumbo frames → узгодити MTU по всьому шляху

Симптом: Дрібні операції працюють; великі копії падають. Іноді лише через певні VLAN.
Корінна причина: Один сегмент втрачає jumbo frames або блокує ICMP fragmentation-needed; TCP стає застопореним, потім скидається.
Виправлення: Вимкніть jumbo frames або увімкніть їх скрізь, включно з проміжними пристроями; переконайтеся, що ICMP не блокується там, де залежить PMTUD.

5) «Багато клієнтів одночасно» → перезавантаження/фейловер сервера/перезапуск служби → зробити стабільність і контроль змін

Симптом: Уся секція офісу кричить одночасно.
Корінна причина: Фейловер кластера, збій/перезапуск служби SMB, флап NIC, фейловер контролера зберігання.
Виправлення: Перевірте аптайм сервера, журнали кластера, рівні патчів, стабільність драйверів, події фейловера зберігання. Потім зробіть фейловери контрольованими з правильними налаштуваннями SMB CA, де це важливо.

6) «Виникає під час бекапу/вікна snapshot» → стрибок латентності зберігання → ізолювати навантаження і правильно розкласти графік

Симптом: Робочий час в порядку; нічні завдання збігаються з відключеннями.
Корінна причина: Бекап-скани, AV-сканування, очищення снапшотів, tiering або реплікація насичують зберігання і підвищують латентність.
Виправлення: QoS, зміна розкладу, відокремлення томів, налаштування кеша, виключення активних шерів з патологічних сканів і планування потужності під реальний I/O-патерн.

Контрольні списки / поетапний план (стабілізувати потім оптимізувати)

Фаза 1 — Зупинити кровотечу (той самий день)

Візьміть один уражений клієнт і один неуражений. Потрібна контрольна група. Без неї ви «поправите» не те.
Зафіксуйте часові позначки для трьох подій відключення. Зкорелюйте клієнтські логи SMB із серверними.
Підтвердіть діалект SMB і функції (підписування/шифрування/multichannel). Не працюйте навмання.
Перевірте події лінку NIC сервера і базове здоров’я (CPU, пам’ять, латентність зберігання).
Якщо відключення корелюють з бездіяльністю, знайдіть станний проміжний пристрій і перевірте його політику TCP-timeout.
Якщо відключення корелюють з навантаженням, виміряйте CPU сервера і await зберігання; потім вирішіть, який з них зафіксований.
Впровадьте вузьку міру пом’якшення, що відкатна: оновіть драйвер NIC, відрегулюйте таймаут фаєрволу для 445, зупиніть заплановану роботу, яка насичує зберігання.

Фаза 2 — Зробити нудним (цього тижня)

Стандартизуйте драйвери/прошивки NIC на клієнтах і серверах. «Останній» не ціль; ціль — «відомо робочий».
Документуйте налаштування безпеки SMB (підписування/шифрування) і переконайтеся, що CPU сервера відповідає цьому вибору.
Валідуйте MTU по всьому шляху між клієнтами і серверами, включно з фаєрволами і оверлеями.
Перегляньте поведінку кластера/HA: чи налаштовані шари для continuous availability там, де потрібно? Чи сумісні клієнти?
Виміряйте латентність зберігання на бекенді шарінгу під час піку. Якщо не можете її виміряти — ви гадаєте.

Фаза 3 — Оптимізувати без самосаботажу (цей місяць)

Підійміть функції SMB відповідно до потреб. Multichannel чудовий на стабільній мережі; на брудній він може посилити дивні явища.
Розгляньте QoS для бекапів і пакетних робіт, щоб інтерактивні користувачі не постраждали.
Побудуйте синтетичний SMB-тест (чит/запис + метадані) і запускайте його до та після змін.
Зробіть packet capture стандартним інструментом, а не героїчним останнім засобом.

Три міні-історії з корпоративного життя

Міні-історія №1 — Інцидент через хибне припущення

У тікеті було: «SMB шер впав. Користувачі бачать ‘мережева назва більше не доступна’.» Оператор зробив те, що багато з нас роблять під стресом: перезавантажив файловий сервер. Це допомогло на годину. Потім повернулось, як небажане продовження.

Ми витягли часові позначки з двох клієнтів і порівняли. Відключення синхронізувались із різницею в секунди по різних підмережах. Це майже ніколи не проблема драйвера клієнта. Ми перевірили логи файлового сервера: нічого драматичного. CPU в нормі. Зберігання в нормі. Аптайм стабільний. Сервер був найменш підозрілим учасником.

Хибне припущення було: «помилка SMB = проблема SMB-сервера». Пакетний захват на сервері показав, що вхідний трафік зупинився посеред сесії, після чого сервер відправляв keepalive у порожнечу. На боці клієнта ми бачили TCP-реклами, потім з’єднання померло. Ніякого чистого FIN. Ніякого граціозного закриття. Просто стан розчинився.

Винуватцем виявилась зміна політики фаєрволу: команда безпеки посилила таймаути для «невідомих застосунків». Порт 445 не був у їхньому «відомому» списку, бо хтось класифікував файлообмін як «застарілий». Кожна тихa SMB-сесія помирала після фіксованого інтервалу. Користувачі це помітили тільки при наступному відкритті файлу, коли Windows показала класичне повідомлення.

Виправлення було простим: налаштувати таймаути бездіяльності для SMB і включити власників застосунків до процесу зміни політик. Урок складніший: ви не діагностуєте SMB за відчуттями. Ви діагностуєте за тим, хто перший рве TCP-сесію.

Міні-історія №2 — Оптимізація, що відгукнулась боком

Команда хотіла швидшої пропускної здатності між набором агентів збірки і Windows-файловим сервером. Хтось увімкнув jumbo frames і SMB multichannel, щоб «розблокувати продуктивність». Зміна отримала оплески. Пропускна здатність покращилась у швидкому тесті. Потім прийшов продакшен і почав поводитися ніби мильна опера.

Під тривалим навантаженням деякі агенти почали випадково падати з «мережна назва більше не доступна». Не одночасно. Непередбачувано. Система збірки створювала багато дрібних файлів, била по метаданих і тримала з’єднання активними через кілька потоків TCP. Коли падало — падало жорстко: часткові робочі простори, пошкоджені кеші, сердиті розробники.

Хитрість виявили простими діями: валідацією MTU end-to-end. Деякі порти комутаторів і один інтерфейс фаєрволу були все ще на 1500. PMTUD також був частково ослаблений політикою ICMP. Тому великі кадри іноді потрапляли в чорну діру залежно від шляху, і multichannel збільшив кількість потоків, що могли піти «поганим» маршрутом.

Оптимізація відгукнулась боком, бо була застосована непослідовно. «Виправлення» не було містичним тюнінгом реєстру. Це була послідовність: або 1500 всюди, або jumbo всюди, включно з проміжними пристроями. Вони врешті відкотили jumbo, тримали multichannel лише там, де NIC і шляхи чисті, і відключення зникли.

Міні-історія №3 — Нудна, але правильна практика, що врятувала ситуацію

Фінансовий відділ покладався на SMB-шер на кластеризованому файловому сервері. Середовище не блищало. Воно регулярно патчилось, зміни логувались, і була правило: кожен інцидент має таймлайн принаймні з двома незалежними джерелами даних.

В один вівторок користувачі почали бачити «Вказана мережна назва більше не доступна» під час роботи зі spreadsheets. Паніка швидко розгорілася, бо запахнуло втратами даних. Оператор не перезавантажив нічого. Вони почали формувати таймлайн: клієнтські події SMB, серверні SMB-operational логи і події кластера.

За кілька хвилин таймлайн показав флап мережевого інтерфейсу кластера. Відбувся фейловер, але частина клієнтів не перепідключилась чисто. Бекенд зберігання був в порядку; проблема була в мережевому шляху кластера і тому, як сесії оброблялися під час переходу.

Оскільки оновлення і драйвери відслідковувались, вони одразу зв’язали поведінку NIC з нещодавнім оновленням драйвера на одній вузлі. Вони відкотили драйвер на тім вузлі, стабілізували кластерну мережу, і SMB-відключення припинилися. Нудна практика — дисциплінований контроль змін плюс швидка кореляція — перетворила потенційно довгий простій на обмежену подію.

Непривабливий висновок: талантом не замаскуєш відсутність таймлайнів. Логи дешевші за простої.

Питання й відповіді

1) Чи означає «Вказана мережна назва більше не доступна» завжди проблему мережі?

Ні. Часто це означає, що SMB-сесія зникла, що може бути спричинено перезапусками сервера, зависаннями зберігання, багами драйверів клієнта або пристроями мережі, що втрачають стан.

2) Який найшвидший спосіб визначити, чи сервер чи мережа розірвали з’єднання?

Шукайте напрямок TCP RST у packet capture і корелюйте з журналами SMB сервера. Якщо сервер посилає RST або логить термінацію — підозрюйте сервер. Якщо трафік зникає посеред потоку або фаєрвол інжектує скидання — підозрюйте мережевий шлях.

3) Чи виправить відключення SMB підписування цю проблему?

Іноді це зменшує навантаження на CPU і робить нестабільну систему «менш нестабільною», але це не усуває корінну причину. Відключення підписування може порушити вимоги безпеки. Розглядайте це як останній захід зі схваленням і вимірюванням.

4) Чи може SMB multichannel спричиняти відключення?

Сам по собі multichannel не є злом. Але він збільшує кількість TCP-з’єднань і може швидше виявити асиметрію шляхів, невідповідність MTU і баги NIC. Якщо multichannel корелює з відмовами — валідуйте симетрію мережі і драйвери NIC перед відключенням функцій.

5) Чому це трапляється частіше при великих файлах?

Великі передачі навантажують пропускну здатність, буфери і поведінку MTU/фрагментації. Вони також роблять втрати пакетів більш помітними. Крихкий шлях може пережити дрібні читання, але впасти під час великої копії.

6) Чому це трапляється частіше при великій кількості дрібних файлів?

Навантаження дрібними файлами сильно залежить від метаданих і чутливе до латентності. Якщо латентність зберігання стрибає (або антивірус борсається за метадані), SMB-запити можуть таймаутити і сесії будуть припинені.

7) Чи може антивірус викликати цю помилку?

Так. На клієнті AV може інжектити фільтр-драйвери, що заважають файловому I/O або мережі. На сервері AV може навантажувати файлову систему і підвищувати латентність. Якщо відключення AV «виправляє» проблему — не зупиняйтесь на цьому: використайте виключення і безпечну конфігурацію.

8) Чи залучений SMB1 у цю помилку?

Повідомлення може з’являтися на SMB1, SMB2, SMB3 — Windows використовує однакову форму для декількох шляхів помилок. Якщо SMB1 ще в середовищі, його видалення зазвичай підвищує надійність і безпеку.

9) Що якщо лише один шар на сервері уражений?

Підозрюйте бекенд зберігання для того тому, налаштування конкретного шару (continuous availability, вимоги шифрування), квоти/дії FSRM або заплановану задачу, що таргетує цей шлях.

10) Як запобігти поверненню проблеми?

Зробіть процес вимірюваним: зберігайте клієнтські та серверні SMB-логи, моніторте події NIC сервера, відстежуйте латентність зберігання і контролюйте зміни політик таймаутів мережі. Більшість повторних інцидентів — «та сама проблема під новою маскою.»

Наступні кроки, які можна зробити сьогодні

Ось практична послідовність дій, яку я б виконав, якби мені віддали пейджер і чашку поганої кави:

Візьміть один клієнт, що падає, і один стабільний і зафіксуйте наступну часову позначку відключення.
Витягніть події підключення SMB клієнта і операційні події SMB сервера за те саме вікно.
Перевірте події лінку NIC серверу і базові метрики ресурсів (CPU, пам’ять, лічильники латентності шарів SMB).
Якщо пахне таймаутом бездіяльності, перевірте TCP idle timeouts для 445 на фаєрволі/NAT/VPN і відрегулюйте.
Якщо пахне навантаженням, виміряйте await зберігання і CPU сервера; зупиніть найбільш навантажувальну роботу і підтвердіть відновлення стабільності.
Лише потім розглядайте тюнінг функцій SMB (multichannel, обсяг шифрування) або offload NIC на клієнті — по одній зміні з доказами до/після.

Більшість інцидентів «вказана мережна назва більше не доступна» виявляються однією з трьох причин: проміжний мережевий пристрій рве стан, NIC флапає, або латентність зберігання маскується під мережеву проблему. Ваше завдання — припинити ставитись до цього як до «характерної риси» SMB і почати лікувати порушений контракт десь у стеку.

Схожі статті

Мережі Windows: SMB повільний — єдина функція, яку ви забули увімкнути Повільні копії на NAS: налаштування SMB, що справді мають значення