«Мережевий шлях не знайдено» (0x80070035): виправлення за 5 хвилин

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

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

9:07 ранку. Хтось не може відкрити \\fileserver\finance. Фінансовий директор на дзвінку. Ви перевіряєте самі і—бац—Windows
видає «Мережевий шлях не знайдено» з кодом 0x80070035. Не «доступ заборонено». Не «неправильний пароль». Навіть натяку немає.

Ця помилка — спосіб Windows сказати: «Я не можу добратися звідси до туди». Те «туди» може бути DNS, маршрутизація, SMB, правила брандмауера або шар,
якого вже немає, бо хтось «прибрав» кластер збереження о 2:00 ночі. Виправимо це за п’ять хвилин — у більшості випадків — і точно знатимемо, що робити, коли проблема складніша.

Швидкий план діагностики (перевірити перше, друге, третє)

Коли з’являється 0x80070035, не починайте з перезавантажень. Перезавантаження стирають докази й марнують час.
Почніть з доведення, який шар бреше.

1) Це розв’язання імен чи транспорт?

Спробуйте IP: \\10.20.30.40\share. Якщо по IP працює, а по імені — ні, проблема в DNS/NetBIOS/порядку пошуку hosts.
Перевірте TCP 445: якщо 445 заблоковано, SMB не дійде. Лікуйте брандмауер/маршрутизацію, а не «дозволи».

2) SMB доступний, але шару немає?

Перегляньте шари віддалено (або хоча б відкрийте \\server в Провіднику). Якщо сервер відповідає, а шару немає — це питання імені/шляху шару.
Перевірте серверну службу SMB: якщо сервер не пропонує SMB, Windows з максимальною впевненістю скаже «шлях не знайдено».

3) Аутентифікація маскується під «не знайдено»?

В деяких середовищах помилки аутентифікації, невідповідність підписування SMB або політики блокують та відображаються як загальні помилки.
Перевірте журнали подій Windows і SMB-серверні логи. Якщо ви дістаєтеся до 445, але сесії падають — це питання аутентифікації/політик.

4) Оцініть площу впливу за 60 секунд

Тільки один користувач? Це локальна конфігурація, VPN з розділом тунелю або кеш облікових даних.
Тільки одна підмережа? Це сегментація брандмауером або ACL маршрутизації.
Усі? Це сервер, бэкэнд-сторедж або спільна інфраструктура (DNS, AD, політика брандмауера).

Парафраз ідеї, приписаної Gene Kim (автор про DevOps/операції): Команди з високою ефективністю скорочують середній час відновлення, практикуючи та стандартизуючи діагностику.
Наведений план — ваша стандартизація.

Що насправді означає 0x80070035 (і чого не означає)

0x80070035 — це повернення Windows коду ERROR_BAD_NETPATH. Переклад: клієнт намагався звернутися до UNC-шляху
і не зміг встановити дійсний мережевий шлях. Це може статися ще до того, як розглядаються облікові дані.

Пастка — думати, що це обов’язково «мережева» проблема в фізичному сенсі. Може бути, але часто це питання імені (DNS),
політики (правила брандмауера, посилення SMB) або доступності служби (SMB-сервер зупинено, NAS завис).

Що це зазвичай

Невірне розв’язання DNS: ім’я вказує на старий IP, неправильну VLAN або застарілий запис.
TCP 445 заблокований: «покращення безпеки», яке забуло про файлові сервери.
SMB-сервер не слухає: служба зупинена, SMB на NAS вимкнено або порт не прив’язано.
Шар перейменовано/видалено: шлях фізично більше не існує.
Клієнтські функції відключені: SMB-клієнт вимкнено, політика виявлення мережі, або пошкоджений стек робочої станції.

Що це зазвичай не є

NTFS-права (ці зазвичай дають «Доступ заборонено» або запит пароля).
Випадкова “глюк” Windows, що вирішиться «пізніше». «Спробуйте пізніше» — не стратегія.

Виправлення за 5 хвилин: найкоротший шлях до істини

Ось авторитетний порядок дій. Дотримуйтесь його. Відступайте лише за наявності доказів.

Хвилина 1: Обійдіть розв’язання імен

Якщо \\fileserver\share не працює, спробуйте \\IP\share. Це найшвидший розвіл дороги.
Якщо по IP працює — перестаньте чіпати брандмауери й почніть виправляти DNS/розв’язання імен.

Хвилина 2: Доведіть, що мережевий шлях існує (TCP 445)

Сучасний SMB у Windows — це TCP 445. Якщо цей порт не сполучається, решта не має значення.
По SMB не домовляються на основі відчуттів.

Хвилина 3: Перевірте, чи сервер пропонує SMB

Якщо 445 доступний, але сектор «шляху не знайдено», впевніться, що служба SMB запущена і шар існує.
Якщо це NAS, перевірте, чи воно не перемкнулося на «security-first: NFS only» після оновлення прошивки.

Хвилина 4: Усуньте дивні речі на клієнті

Очистіть DNS-кеш, видаліть застарілі підключення мережевих дисків і переконайтеся, що робоча станція в потрібній мережі (VPN із розділеним тунелюванням часто винен).

Хвилина 5: Перевірте журнали, де живе правда

На Windows: журнали SMBClient Operational. На серверах: SMBServer, журнали безпеки і аудиту NAS. Код помилки в журналі зазвичай чесніший за Провідник.

Жарт №1: SMB — як торговий автомат — коли каже «не знайдено», часто означає: снек є, але слот заклинив.

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

Нижче реальні завдання, які можна виконати. Кожне містить: команду, типову відповідь, що вона означає і яке рішення виконати далі.
Я використовую команди Windows; позначення підказки — лише для оформлення. Запускайте в PowerShell або CMD.

Завдання 1: Підтвердити, що ім’я резольвиться в правильний IP

cr0x@server:~$ nslookup fileserver.corp.example
Server:  dns01.corp.example
Address: 10.10.0.10

Name:    fileserver.corp.example
Address: 10.20.30.40

Що це значить: DNS резольвить. Тепер перевірте, що 10.20.30.40 — дійсно ваш файловий сервер, а не повторно використаний IP.
Якщо IP неправильний — ви знайшли корінну причину.

Рішення: Якщо DNS неправильний — виправте A-запис, видаліть застарілі записи або налаштуйте порядок DNS-серверів на клієнтах. Не «прикривайте» проблему файлом hosts, якщо не хочете майбутніх збоїв.

Завдання 2: Перевірте, що Windows вважає за правильний IP

cr0x@server:~$ ping -4 fileserver
Pinging fileserver [10.20.30.40] with 32 bytes of data:
Reply from 10.20.30.40: bytes=32 time<1ms TTL=127

Що це значить: Клієнт може резольвити ім’я і досягати IP через ICMP. Це не доводить роботу SMB, але підказує, що маршрутизація в порядку.

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

Завдання 3: Доведіть, що TCP 445 доступний з клієнта

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection fileserver -Port 445 | Format-List ComputerName,RemoteAddress,TcpTestSucceeded"
ComputerName    : fileserver
RemoteAddress   : 10.20.30.40
TcpTestSucceeded: True

Що це значить: Ви можете відкрити TCP-з’єднання до SMB. Брандмауери й маршрутизація між клієнтом і сервером, ймовірно, в порядку.

Рішення: Якщо TcpTestSucceeded: False, зупиніться. Виправляйте правила брандмауера, сегментацію ACL, політику VPN або стан прослуховування сервера. Не чіпайте права шару.

Завдання 4: Підтвердіть, що ви потрапляєте на потрібний сервер (reverse lookup + ARP)

cr0x@server:~$ arp -a 10.20.30.40
Interface: 10.20.30.123 --- 0x11
  Internet Address      Physical Address      Type
  10.20.30.40           00-15-5d-4b-12-34     dynamic

Що це значить: Ви спілкуєтеся з MAC на вашому L2-шляху. В дивних мережах неправильні IP можуть тихо переназначатися.

Рішення: Якщо MAC не відповідає очікуваному (або змінюється), дослідіть конфлікти IP, неправильний DHCP-диапазон або шкідливу віртуальну машину.

Завдання 5: Спробуйте UNC-шлях по IP, щоб обійти DNS повністю

cr0x@server:~$ powershell -NoProfile -Command "dir \\10.20.30.40\finance"
Get-ChildItem : Cannot find path '\\10.20.30.40\finance' because it does not exist.
At line:1 char:1
+ dir \\10.20.30.40\finance
+ ~~~~~~~~~~~~~~~~~~~~~~~~~

Що це значить: Мережевий шлях до хоста існує (якщо 445 доступний), але ім’я шару може бути відсутнє.
Це відрізняється від неможливості дістатися до сервера взагалі.

Рішення: Підтвердіть ім’я шару (чутливість до регістру не ваша проблема; уважно перевірте написання). Перевірте на сервері/NAS: шар існує і експортується по SMB.

Завдання 6: Перелічіть шари на Windows файловому сервері

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare -CimSession fileserver | Select-Object Name,Path,Description"
Name     Path              Description
----     ----              -----------
finance  D:\Shares\Finance  Finance department share
public   D:\Shares\Public   General share

Що це значить: Шар існує на сервері, і ви маєте права запитати його (або ви запускали команду як адмін з потрібними обліковими даними).

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

Завдання 7: Перевірте, що служба SMB на сервері запущена (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name LanmanServer | Select-Object Name,Status,StartType"
Name         Status  StartType
----         ------  ---------
LanmanServer Running Automatic

Що це значить: Сервер пропонує SMB. Якщо служба зупинена, клієнти Windows часто бачать «шлях не знайдено».

Рішення: Якщо Status — Stopped, запустіть її й дослідіть причину зупинки (патч, відмова залежності, політики безпеки).

Завдання 8: Підтвердіть, що сервер слухає TCP 445

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 445 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess"
LocalAddress LocalPort OwningProcess
------------ --------- ------------
0.0.0.0      445       4
::           445       4

Що це значить: Щось (зазвичай процес System) слухає 445 для IPv4 і IPv6.

Рішення: Якщо ніхто не слухає — виправляйте службу SMB, прив’язку або політику, що відключила SMB.

Завдання 9: Перевірте правила брандмауера Windows, релевантні для SMB (на клієнті чи сервері)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Select-Object DisplayName,Enabled,Profile | Format-Table -AutoSize"
DisplayName                                      Enabled Profile
-----------                                      ------- -------
File and Printer Sharing (SMB-In)                True    Domain
File and Printer Sharing (SMB-In)                False   Public
File and Printer Sharing (SMB-In)                False   Private

Що це значить: Вхідний SMB дозволено лише на профілі Domain. Якщо сервер вважає, що він у Public — ви заблоковані.

Рішення: Виправте класифікацію мережевого профілю або ввімкніть потрібний профіль правила. Не вимикайте брандмауер просто так.

Завдання 10: Підтвердіть мережевий профіль клієнта (Domain vs Public)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object Name,NetworkCategory,IPv4Connectivity"
Name               NetworkCategory IPv4Connectivity
----               --------------- ----------------
CorpLAN            DomainAuthenticated Internet

Що це значить: Клієнт вважає, що він у доменній мережі. Якщо там Public, Windows застосує суворіші налаштування брандмауера та поведінку виявлення.

Рішення: Якщо несподівано Public — перевірте NLA (Network Location Awareness), стан VPN і підключення до домену.

Завдання 11: Перевірте, що SMB-клієнтські функції присутні й увімкнені

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol,SMB1Protocol-Client | Select-Object FeatureName,State"
FeatureName         State
-----------         -----
SMB1Protocol        Disabled
SMB1Protocol-Client Disabled

Що це значить: SMB1 вимкнено, що добре. Але якщо ви спілкуєтеся зі старим NAS, який підтримує лише SMB1, це зламає зв’язок.

Рішення: Краще оновити NAS або ввімкнути SMB2/3. Включайте SMB1 лише як тимчасову міру й із суворим контролем мережі.

Завдання 12: Очистіть застарілі мапінги дисків і підключіться заново

cr0x@server:~$ net use
New connections will be remembered.

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

cr0x@server:~$ net use z: /delete
z: was deleted successfully.

cr0x@server:~$ net use z: \\fileserver\finance /persistent:no
The command completed successfully.

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

Рішення: Якщо повторне підключення завершується з System error 53, ви все ще на рівні мережі/імен/портів. Якщо System error 5 — це питання прав/аутентифікації.

Завдання 13: Перегляньте кеш DNS-клієнта на предмет застарілих відповідей

cr0x@server:~$ ipconfig /displaydns | findstr /i fileserver
fileserver
    Record Name . . . . . : fileserver.corp.example
    Record Type . . . . . : 1
    Time To Live  . . . . : 120
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 10.20.30.40

Що це значить: Робоча станція закешувала IP. Якщо кеш неправильний — Windows продовжить помилятися, поки TTL не спливе або поки ви не очистите кеш.

Рішення: Якщо кешований IP неправильний — очистіть його й виправте upstream DNS, щоб проблема не повернулася.

Завдання 14: Очистіть DNS і повторіть спробу

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Що це значить: Ви видалили закешовані DNS-записи. Якщо проблема була в застарілому розв’язанні — це може миттєво допомогти на цьому клієнті.

Рішення: Якщо очищення допомогло — з’ясуйте, чому DNS змінився і чому кеші були застарілими (оновлення записів, очищення зон, кілька DNS-серверів).

Завдання 15: Перевірте здоров’я Kerberos/DNS на клієнті (середовища домену)

cr0x@server:~$ klist
Current LogonId is 0:0x3e7

Cached Tickets: (2)
#0>     Client: user@CORP.EXAMPLE
        Server: krbtgt/CORP.EXAMPLE@CORP.EXAMPLE
        End Time: 2/5/2026 18:12:03
#1>     Client: user@CORP.EXAMPLE
        Server: cifs/fileserver.corp.example@CORP.EXAMPLE
        End Time: 2/5/2026 18:12:03

Що це значить: У вас є CIFS-сервісний квиток для файлового сервера. Це зазвичай вказує, що розв’язання імен і доменна аутентифікація працюють.

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

Завдання 16: Перевірте журнали SMB-клієнта для точнішої помилки

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-SMBClient/Operational' -MaxEvents 5 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List"
TimeCreated      : 2/5/2026 9:09:41 AM
Id               : 30805
LevelDisplayName : Error
Message          : The SMB client failed to connect to the share. Error: The network path was not found.

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

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

Завдання 17: На сервері підтвердіть, що шлях шару існує на диску

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'D:\Shares\Finance'"
True

Що це значить: Підлягаюча директорія існує. Якщо це False, шар може існувати, але вказувати в нікуди (або том не змонтовано).

Рішення: Якщо шлях відсутній — перевірте сховище: збої монтування, відключення iSCSI, диск кластера офлайн, зламаний DFS-критерій або відмонтований том NAS.

Завдання 18: Перевірте DFS-реферальні дані, коли «сервер» — це DFS

cr0x@server:~$ powershell -NoProfile -Command "dfsutil /pktinfo"
PKT Entry: \\corp.example\dfs\finance
  Referrals:
    \\fs01.corp.example\finance  (ACTIVE)
    \\fs02.corp.example\finance  (INACTIVE)

Що це значить: У процесі DFS. Зламаний тарґет або реферал може проявлятися як «мережевий шлях не знайдено», особливо якщо клієнтів спрямовують до офлайн-вузла.

Рішення: Відновіть здоров’я DFS-тарґета, відключіть мертвий тарґет або виправте розрахунок вартостей по сайтах. Не звинувачуйте «мережу», коли DFS роздає неправильні вказівки.

Жарт №2: «Мережевий шлях не знайдено» — це Windows, яка каже «Я дійшов до дверей, але будівля або зникла, або зачинена — успіхів».

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

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

1) Симптом: Ім’я не працює, IP працює

Корінна причина: A-запис DNS вказує на старий сервер; застарілий кеш; невірний DNS-суфікс; split-brain DNS між on‑prem і VPN.
Виправлення: Виправте записи DNS (і механізми очищення), очистіть кеш клієнтів, перевірте, що клієнти використовують правильні DNS-сервери, і припиніть покладатися на NetBIOS-броадкасти.

2) Симптом: Працює в офісі LAN, не працює через VPN

Корінна причина: Розділене тунелювання VPN виключає підмережі файлового сервера; брандмауер VPN блокує 445; DNS через VPN повертає інший вигляд.
Виправлення: Пропустіть підмережу файлового сервера через VPN, дозвольте TCP 445 до затверджених серверів і вирівняйте DNS-перегляди з шляхом доступу.

3) Симптом: Раптом не працює в усіх після «посилення безпеки»

Корінна причина: Групова політика відключила SMB-клієнт, блокує NTLM, вимагає підписування SMB або відключила гостьовий доступ; зміни політики брандмауера блокують вхідний SMB.
Виправлення: Відкочуйте або відкоригуйте політику з контрольованим списком виключень; узгодьте вимоги підписування/NTLM по обох сторонах; тестуйте на пілотній групі.

4) Симптом: Лише один шар не працює; інші на тому ж сервері — працюють

Корінна причина: Шар перейменовано, видалено або вказує на відсутній том; зламаний DFS-тарґет; видалено рівень дозволів на шарі.
Виправлення: Підтвердіть існування шару на сервері, перевірте шлях шару, відновіть монтування тома або виправте DFS-реферали.

5) Симптом: Сервер доступний, але Провідник показує порожнє/довга затримка й потім помилку

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

6) Симптом: Старий NAS недоступний після оновлення Windows

Корінна причина: NAS підтримує лише SMB1; оновлення Windows видалило/вимкнуло SMB1-клієнт.
Виправлення: Оновіть прошивку/налаштування NAS до SMB2/3. Якщо неможливо — ізолюйте цей NAS і тимчасово ввімкніть SMB1 лише для необхідних машин.

7) Симптом: Періодичний «шлях не знайдено», особливо в кластерному сховищі

Корінна причина: Постійна доступність SMB фактично недоступна; переключення ролей кластера рве сесії; бэкэнд сховища відключає томи.
Виправлення: Перевірте ролі кластера й налаштування шару, стежте за стабільністю multipath/iSCSI і моніторте події перемикань у часі з описами користувачів.

Три корпоративні міні-історії (як це ламається в реальному житті)

Міні-історія 1: Інцидент, спричинений хибним припущенням

Середня компанія мігрувала файловий сервер на нову VM. Те саме ім’я, новий IP, «немає проблем». Команда оновила DNS і протестувала з кількох робочих станцій IT. Всі розійшлися.

О 8:30 служба підтримки почала отримувати 0x80070035 у різних відділах. Не у всіх. Достатньо, щоб спровокувати паніку.
Інженер на чергуванні припустив, що «нова VM впала» і перезапустив службу SMB. Без змін. Перезапустив VM. Всеодно нічого.

Причина була болісно проста: два DNS-сервери. Один отримав оновлений A-запис. Інший не реплікувався правильно і продовжував повертати старий IP.
Робочі станції були налаштовані з обома DNS, тож розв’язання залежало від того, який відповів першим. Файловий сервер не був упавший;
половині клієнтів давалися вказівки на мертву адресу.

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

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

Інша організація мала проєкт зниження затримок. Хтось помітив, що SMB-трафік петляє через центральний брандмауер, коли філії звертаються до HQ кластеру.
Рішення: додати політику брандмауера, яка блокує SMB з непогоджених підмереж, і змусити філії використовувати локальний кеш-сервіс.

Розгортання кеш-сервісу затрималося, але зміна брандмауера пішла за графіком, бо вважали її «безпечним»: більшість SMB не повинна була залишати HQ.
У запиті на зміну навіть був список «дозволених» підмереж.

До полудня інженери не могли отримати артефакти збірки з \\buildshare. Фінансисти не могли відкрити звітність. Помилка
не писала «заблоковано політикою». Вона була 0x80070035. Клієнти Windows не коментують ваші зміни брандмауера; вони просто падають.

Корінна причина: список дозволених не включав пул адрес VPN, яким користувалися віддалені співробітники, і низку нових Wi‑Fi VLAN. «Оптимізація» була слушною за задумом, але реалізована не в тому порядку і без механізму спостереження за відмовами 445.

Виправлення було не тільки додати підмережі. Вони запровадили поетапні релізи з логуванням відмов, дашбордами по блокам TCP 445 і canary-клієнтом у кожному сегменті. Мораль: оптимізуйте останнім кроком, після того як побачите, що ламаєте.

Міні-історія 3: Сумна, але правильна практика, що врятувала ситуацію

Велике підприємство використовувало простори DFS для користувацьких шарів із кількома тарґетами на сайт. Це не було захопливо. Це було послідовно, документовано і тестовано щокварталу.
Команда збереження мала простий мануал: перевіряти здоров’я рефералів DFS, підтверджувати прослуховування SMB, перевіряти шляхи шарів, верифікувати монтування бэкэнду.

Одного ранку баг у прошивці масиву зберігання спричинив, що підмножина LUN тимчасово відпала. На двох файлових серверах том критичного шару змонтувався з іншим буквеним іменем через зміну порядку монтування. Шар все ще існував в ОС — але вказував на порожній шлях. Клієнти бачили «мережевий шлях не знайдено» залежно від того, до якого DFS-тарґета їх перенаправив реферал.

Інженер на чергуванні не вгадав. Він виконав мануал. Перше: Test-NetConnection 445 (добре). Друге: Get-SmbShare на обох тарґетах (шар існує). Третє: Test-Path на шляху шару (false на двох вузлах). Четверте: виправили монтування й перевірили.

Час простою був обмежений, бо хтось раніше зробив нудну роботу: послідовний моніторинг DFS-тарґетів і звичку перевіряти шляхи шарів відносно монтувань сховища. Ніяких героїчних вчинків. Ніякої поезії в Slack о пів на третю ночі. Просто система, що ламається знайомими способами, і команда, яка впізнає патерн.

Цікаві факти та коротка історія (SMB, мережі Windows і чому ми страждаємо)

Факт 1: SMB виник у IBM у 1980‑х і пізніше був прийнятий і розширений Microsoft; він старший за багато «модернізаційних» планів.
Факт 2: Раніше Windows-мережі покладалися на NetBIOS і широкомовлення — зручно на плоскому LAN, але складно в маршрутизованих мережах.
Факт 3: TCP 445 («SMB over TCP») зменшив залежність від NetBIOS/139, але в багатьох середовищах досі живуть спадкові уявлення з епохи 139.
Факт 4: Слабкості SMB1 зробили його сумнозвісним, і сучасні Windows вимикають SMB1 за замовчуванням; це ламає старі NAS пристрої так, як передбачалось.
Факт 5: Той самий UNC-шлях може проходити різними стекми: прямий SMB, простір імен DFS або навіть WebDAV — кожен має свої режими відмови.
Факт 6: Повідомлення Провідника часто зводять кілька різних збоїв до однієї загальної фрази; журнали подій зазвичай більш конкретні.
Факт 7: Підписування і шифрування SMB підвищують цілісність/безпеку, але можуть спричиняти помилки перемовин, коли політики на клієнті і сервері не збігаються.
Факт 8: «Network Location Awareness» (NLA) впливає на профілі брандмауера; невірна класифікація в Public може непомітно блокувати файловий трафік.
Факт 9: DFS-реферали можуть змінюватися на основі мапінгу AD сайт/підмережа; неправильний мапінг сайту може спрямувати клієнта до віддалених або мертвих тарґетів.

Контрольні списки / покроковий план (для людей під тиском)

Контрольний список A: Один користувач повідомляє про 0x80070035

Попросіть спробувати шлях по IP: \\10.20.30.40\share. Якщо працює — це розв’язання імен.
На клієнті: запустіть Test-NetConnection server -Port 445. Якщо не вдається — це локальна мережа/VPN/політика.
Очистіть мапінги: net use * /delete (обережно) або видаліть конкретний диск, потім підключіться заново.
Очистіть кеш DNS: ipconfig /flushdns.
Перевірте профіль: Get-NetConnectionProfile. Якщо Public — виправте класифікацію мережі.
Витягніть події SMBClient Operational навколо часу збою.

Контрольний список B: Вся команда не може доступитися до одного шару

Підтвердіть існування шару на сервері: Get-SmbShare або список шарів NAS.
Підтвердіть існування шляху шару: Test-Path на сервері; перевірте монтування/томи.
Підтвердіть службу SMB і порт на сервері: Get-Service LanmanServer, Get-NetTCPConnection -LocalPort 445.
Перевірте зміни в політиці брандмауера і журнали відмов для порту 445.
Якщо DFS: перевірте реферали й стан тарґетів; відключіть мертві тарґети.

Контрольний список C: «Вчора працювало» після патчу або впровадження політики

Перевірте, чи змінилися політики щодо SMB1/гостьового доступу/NTLM на клієнтах або серверах.
Узгодьте вимоги підписування SMB по обох сторонах.
Перегляньте правила брандмауера в групі «File and Printer Sharing».
Порівняйте робочу машину й ту, що падає: DNS-сервери, стан VPN, категорія мережі й версії агентів безпеки.
Відкочуйте політику, якщо не можете довести її безпечність.

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

Q1: Чи однакові 0x80070035 і «System error 53»?

Вони тісно пов’язані. net use часто повідомляє про проблеми з підключенням/іменем/шляхом як «System error 53 has occurred. The network path was not found.»
Провідник може показати 0x80070035 для того самого класу збоїв.

Q2: Чому інколи по IP працює, а по імені — ні?

Бо ви обходите DNS і будь-які шари розв’язання імен (пошук суфіксів, WINS/NetBIOS-підстановки, кеш). Якщо по IP працює — транспорт у порядку.
Лікуйте іменування, а не брандмауери.

Q3: Який порт потрібно відкрити для SMB-файлових шарів?

Сучасний SMB використовує TCP 445. Старіший NetBIOS/SMB залучає порти 137–139, але для підтримуваних Windows і NAS треба використовувати 445.
Якщо 445 заблокований — очікуйте 0x80070035 або схожі збої.

Q4: Чи можуть дозволи спричинити 0x80070035?

Зазвичай проблеми з дозволами видно як «Access denied», запити облікових даних або конкретні помилки аутентифікації. Але політики блокувань (наприклад, «deny NTLM»)
можуть виявлятися як загальні збої. Перевірте журнали SMBClient і серверні журнали безпеки, щоб упевнитися.

Q5: Чому це не працює лише з дому або лише через VPN?

Маршрутизація VPN та правила брандмауера — типовi підозрювані. Розділене тунелювання може виключати підмережу файлового сервера, а деякі профілі безпеки VPN блокують 445 за замовчуванням.
Перевірте за допомогою Test-NetConnection -Port 445 з клієнта під VPN.

Q6: Чи варто вмикати SMB1, щоб швидко вирішити проблему?

Лише якщо ви впевнились, що сервер/NAS підтримує тільки SMB1 і немає можливості оновити. Включення SMB1 розширює поверхню атаки.
Розглядайте це як тимчасовий міст з обмеженнями, а не як постійне рішення.

Q7: Що робити, якщо ping працює, а SMB — ні?

Ping доводить досяжність ICMP, а не прикладну досяжність. Брандмауер часто дозволяє ICMP, але блокує TCP 445. Або служба SMB не запущена.
Перевірте 445 явно і стан прослуховування сервера.

Q8: Що робити, якщо 445 підключається, але шар все одно показує «не знайдено»?

Ви пройшли рівні маршруту/брандмауера і потрапили в зону SMB/шарів/DFS: неправильне ім’я шару, шар видалено, шлях шару відсутній, зламаний DFS-реферал
або невідповідність перемовин/політик, які логують більше деталей, ніж Провідник.

Q9: Як зрозуміти, чи задіяно DFS?

Якщо шлях виглядає як \\domain\dfsroot\share, це DFS. Використовуйте dfsutil /pktinfo, щоб побачити, на який тарґет вас перенаправили.
Мертвий реферал може зробити шлях «не знайденим».

Q10: Чому Windows інколи показує різні помилки для однієї й тієї ж проблеми?

Різні компоненти видають різні абстракції помилок: Провідник, SMB-клієнт, редіректор, менеджер облікових даних і DFS мають свої відображення помилок.
Довіряйте реальності на рівні пакетів (чи підключається 445?) і журналам подій більше, ніж формулюванням у GUI.

Висновок: практичні подальші кроки

0x80070035 не містичний. Це багатошаровий збій: розв’язання імен, з’єднання до TCP 445, доступність SMB-служби, існування шару і лише потім аутентифікація/політики.
Найшвидше виправлення — найшвидше спростування — спробуйте IP, перевірте 445, підтвердіть існування шару і читайте журнали, які не прикрашають правду.

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

Створіть односторінковий мануал з «Швидкого плану діагностики» і прикріпіть його туди, де ваш черговий справді дивиться.
Моніторьте й оповіщайте про відмови TCP 445 на межах мережі (з кореляцією змін), а не лише графіки CPU серверів.
Зробіть інвентаризацію версій SMB на NAS/файлових серверах; усуньте залежності від SMB1 до наступної хвилі посилення Windows.
Для середовищ з DFS: регулярно перевіряйте реферали й видаляйте мертві тарґети. DFS чудовий, доки він не почне чемно відправляти користувачів в нікуди.
Стандартизуйте canary-тест з кожного мережевого сегмента (LAN, VPN, Wi‑Fi VLAN), який перевіряє розв’язання імен і підключення до 445 на критичних шарах.