« Chemin réseau introuvable » (0x80070035) : la réparation en 5 minutes

février 25, 2026 • février 25, 2026 • Lecture : 26 min • Views: 0

Cet article vous a aidé ?

Il est 9h07. Quelqu’un n’arrive pas à ouvrir \\fileserver\finance. Le directeur financier est en conférence. Vous essayez vous‑même et—boum—Windows affiche
« Chemin réseau introuvable » avec le code 0x80070035. Pas « accès refusé ». Pas « mauvais mot de passe ». Pas même un indice.

Cette erreur est la façon de Windows de dire « je ne peux pas y accéder depuis ici ». Ce « là » peut être le DNS, le routage, SMB, des règles de pare‑feu, ou un partage
qui n’existe plus parce que quelqu’un a « rangé » un cluster de stockage à 2h du matin. Réparons ça en cinq minutes—la plupart du temps—et sachons précisément quoi faire quand ce n’est pas un problème de cinq minutes.

Playbook de diagnostic rapide (vérifier d’abord, ensuite, puis)

Quand vous voyez 0x80070035, ne commencez pas par redémarrer des machines. Les redémarrages effacent des preuves et gaspillent des réunions.
Commencez par prouver quelle couche ment.

1) Est‑ce la résolution de nom ou le transport ?

Essayez l’IP : \\10.20.30.40\share. Si l’IP fonctionne mais que le nom d’hôte échoue, c’est DNS/NetBIOS/ordre de recherche hosts.
Testez le TCP 445 : si le 445 est bloqué, SMB est mort à l’arrivée. Corrigez le pare‑feu/le routage, pas les « permissions ».

2) SMB est‑il joignable mais le partage est manquant ?

Listez les partages à distance (ou au moins ouvrez \\server dans l’Explorateur). Si le serveur répond mais que le partage n’apparaît pas, c’est un problème de nom/chemin de partage.
Vérifiez le service SMB côté serveur : si le serveur n’offre pas SMB, Windows signalera « chemin non trouvé » avec une grande confiance.

3) S’agit‑il d’une authentification déguisée en « introuvable » ?

Certaines environnements mappent des échecs d’authentification, des incompatibilités de signature SMB, ou des blocages de politique en erreurs génériques.
Vérifiez les journaux d’événements Windows et les journaux SMB du serveur. Si vous pouvez atteindre le 445 mais que les sessions échouent, c’est de l’authentification/politique.

4) Déterminez l’étendue en 60 secondes

Un seul utilisateur ? C’est une configuration locale, le split tunneling VPN, ou le cache d’identifiants.
Un sous‑réseau ? C’est de la segmentation pare‑feu ou une ACL de routage.
Tous les utilisateurs ? C’est le serveur, le stockage qui le soutient, ou une dépendance d’infrastructure partagée (DNS, AD, push de politique pare‑feu).

Idée paraphrasée, attribuée à Gene Kim (auteur DevOps/ops) : Les équipes d’opérations performantes réduisent le temps moyen de récupération en pratiquant et standardisant le diagnostic.
Le playbook ci‑dessus est votre standardisation.

Ce que signifie réellement 0x80070035 (et ce que ce n’est pas)

0x80070035 est Windows qui renvoie ERROR_BAD_NETPATH. Traduction : le client a tenté d’atteindre un chemin UNC
et n’a pas pu établir un chemin réseau valide. Cela peut se produire avant même que les identifiants ne soient pris en compte.

Le piège est de supposer que c’est « un problème réseau » au sens physique. Cela peut l’être, mais c’est souvent une chose de nom (DNS),
une chose de politique (règles de pare‑feu, durcissement SMB), ou une chose de disponibilité de service (serveur SMB arrêté, NAS bloqué).

Ce que c’est généralement

Mauvaise résolution DNS : le nom d’hôte pointe vers une IP ancienne, un VLAN erroné, ou un enregistrement obsolète.
TCP 445 bloqué : « amélioration de sécurité » qui a oublié que les serveurs de fichiers existent.
Serveur SMB non à l’écoute : service arrêté, SMB du NAS désactivé, ou port non lié.
Partage renommé/supprimé : le chemin n’existe littéralement plus.
Fonctions côté client désactivées : client SMB désactivé, découverte réseau désactivée, ou pile workstation corrompue.

Ce que ce n’est généralement pas

Permissions NTFS (elles donnent typiquement « Accès refusé » ou des invites d’identifiants).
Un « bug » Windows aléatoire qui serait résolu par « réessayer plus tard ». Réessayer plus tard n’est pas une stratégie.

La réparation en 5 minutes : le chemin le plus court vers la vérité

Voici l’ordre d’opérations opinionné. Suivez‑le. Déviez uniquement avec des preuves.

Minute 1 : Contournez la résolution de nom

Si \\fileserver\share échoue, essayez \\IP\share. C’est la bifurcation la plus rapide.
Si l’IP fonctionne, arrêtez de toucher aux pare‑feu et commencez à corriger le DNS/la résolution de noms.

Minute 2 : Prouvez que le chemin réseau existe (TCP 445)

SMB sur les versions modernes de Windows est TCP 445. Si ce port ne se connecte pas, rien d’autre n’a d’importance.
Vous ne pouvez pas négocier SMB sur des impressions.

Minute 3 : Vérifiez si le serveur propose SMB

Si le 445 est joignable mais que le partage est « introuvable », confirmez que le service SMB tourne et que le partage existe.
Si c’est un NAS, vérifiez qu’il n’a pas basculé de SMB vers « sécurité d’abord : NFS uniquement » après une mise à jour firmware.

Minute 4 : Éliminez les bizarreries locales du client

Videz le cache DNS, supprimez les lecteurs mappés obsolètes et vérifiez que la station de travail est sur le bon réseau (le split tunneling VPN est un récidiviste).

Minute 5 : Consultez les journaux où la vérité se trouve

Sur Windows : journaux SMBClient Opérationnel. Sur les serveurs : journaux SMBServer, journaux de sécurité et journaux d’audit NAS. Le code d’erreur dans le journal est généralement plus honnête que l’Explorateur.

Blague n°1 : SMB, c’est comme un distributeur automatique—quand il dit « introuvable », ça veut souvent dire que la friandise est là mais que la fente est coincée.

Tâches pratiques : commandes, sortie attendue, et la décision que vous prenez

Voici des tâches réelles à exécuter. Chacune inclut : la commande, la sortie typique, ce que cela signifie, et la décision suivante.
J’utilise des commandes Windows ; l’étiquette d’invite est juste un wrapper pour satisfaire les règles de formatage. Exécutez‑les dans PowerShell ou CMD.

Tâche 1 : Confirmer que le nom d’hôte résout vers la bonne 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

Ce que cela signifie : le DNS résout. Vérifiez maintenant que 10.20.30.40 est bien votre serveur de fichiers et non une IP recyclée.
Si l’IP est incorrecte, vous avez trouvé la cause racine.

Décision : si le DNS est faux, corrigez l’enregistrement A, la purge des enregistrements obsolètes ou l’ordre de recherche DNS client. Ne contournez pas avec des fichiers hosts sauf si vous aimez les pannes futures.

Tâche 2 : Vérifier ce que Windows pense que le nom devrait résoudre

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

Ce que cela signifie : le client peut résoudre et atteindre l’IP via ICMP. Cela ne prouve pas que SMB fonctionne, mais suggère que le routage est sain.

Décision : si le ping échoue mais que le DNS résout, testez le routage/VPN et le pare‑feu local. Si le ping fonctionne, passez au test du port 445.

Tâche 3 : Prouver que le TCP 445 est joignable depuis le client

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

Ce que cela signifie : vous pouvez ouvrir une connexion TCP vers SMB. Les pare‑feu et le routage entre client et serveur sont probablement corrects.

Décision : si TcpTestSucceeded: False, arrêtez. Corrigez les règles de pare‑feu, les ACL de segmentation, la politique VPN, ou l’état d’écoute du serveur. Ne touchez pas encore aux permissions de partage.

Tâche 4 : Valider que vous atteignez le serveur prévu (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

Ce que cela signifie : vous parlez à une MAC sur votre chemin L2. Dans des réseaux étranges, des IP incorrectes peuvent être réattribuées silencieusement.

Décision : si la MAC n’est pas celle attendue (ou change), enquêtez sur les conflits d’IP, DHCP mal scoping, ou une VM rogue clonée.

Tâche 5 : Essayez le chemin UNC par IP pour contourner complètement le 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
+ ~~~~~~~~~~~~~~~~~~~~~~~~~

Ce que cela signifie : le chemin réseau vers l’hôte existe (si le 445 est joignable), mais le nom du partage peut être absent.
C’est différent de l’incapacité à atteindre le serveur du tout.

Décision : confirmez le nom du partage (la casse n’est pas le problème ; vérifiez l’orthographe). Vérifiez sur le serveur/NAS : le partage existe‑t‑il et est‑il exporté via SMB.

Tâche 6 : Énumérer les partages sur un serveur de fichiers 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

Ce que cela signifie : le partage existe côté serveur, et vous avez le droit de le lister (ou vous avez exécuté en admin avec les bons identifiants).

Décision : si le partage n’est pas listé, ce n’est pas un problème client. Corrigez la configuration serveur, le rôle en cluster, ou le montage du stockage sous‑jacent.

Tâche 7 : Vérifier que le service SMB serveur fonctionne (côté serveur Windows)

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

Ce que cela signifie : le serveur propose SMB. S’il est arrêté, les clients Windows verront souvent « chemin non trouvé » en ramant.

Décision : si Status est Stopped, démarrez‑le et enquêtez sur la raison de l’arrêt (patch, dépendance défaillante, durcissement sécurité).

Tâche 8 : Confirmer que le serveur écoute sur le 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

Ce que cela signifie : quelque chose (typiquement le processus System) écoute sur le 445 en IPv4 et IPv6.

Décision : si rien n’écoute, corrigez le service SMB, le binding, ou la politique qui a désactivé SMB.

Tâche 9 : Vérifier les règles du pare‑feu Windows pertinentes pour SMB (client ou serveur)

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

Ce que cela signifie : l’entrée SMB inbound est autorisée seulement sur le profil Domain. Si le serveur se croit sur Public, vous êtes bloqué.

Décision : corrigez la classification du profil réseau ou activez la règle pour le profil approprié. N’éteignez pas le pare‑feu juste pour « tester » si vous aimez rendre des comptes ensuite.

Tâche 10 : Confirmer le profil réseau du client (Domaine vs Public)

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

Ce que cela signifie : le client croit être sur un réseau de domaine. S’il indique Public, Windows appliquera des défauts de pare‑feu et de découverte plus stricts.

Décision : si c’est Public de manière inattendue, enquêtez sur NLA (Network Location Awareness), la posture VPN et la connectivité au domaine.

Tâche 11 : Vérifier que les fonctionnalités client SMB sont présentes et activées

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

Ce que cela signifie : SMB1 est désactivé, ce qui est souhaitable. Mais si vous parlez à un NAS ancien qui supporte uniquement SMB1, cela cassera.

Décision : privilégiez la mise à jour du NAS ou l’utilisation de SMB2/3. N’activez SMB1 qu’en dernier recours temporaire et derrière des contrôles réseau stricts.

Tâche 12 : Supprimer les lecteurs mappés obsolètes et reconnecter proprement

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.

Ce que cela signifie : vous forcez une nouvelle création de session. Cela aide quand des identifiants, sessions obsolètes ou mappages morts sont impliqués.

Décision : si la reconnexion échoue avec System error 53, vous êtes encore au niveau réseau/nom/port. Si elle échoue avec System error 5, vous êtes en territoire permissions/auth.

Tâche 13 : Inspecter le cache DNS client pour des réponses obsolètes

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

Ce que cela signifie : la station de travail a mis en cache une IP. Si ce cache est faux, Windows continuera d’échouer jusqu’à l’expiration du TTL ou jusqu’à un flush.

Décision : si l’IP en cache est incorrecte, videz‑le et corrigez le DNS en amont pour éviter que le problème ne revienne.

Tâche 14 : Vider le DNS et réessayer

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

Successfully flushed the DNS Resolver Cache.

Ce que cela signifie : vous avez supprimé les entrées DNS en cache. Si la résolution de nom était obsolète, cela peut corriger immédiatement le problème pour ce client.

Décision : si le flush corrige, demandez‑vous pourquoi le DNS a changé et pourquoi les caches étaient obsolètes (mises à jour d’enregistrements, purge, serveurs DNS multiples).

Tâche 15 : Vérifier la santé Kerberos/DNS depuis le client (environnements de domaine)

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

Ce que cela signifie : vous avez un ticket CIFS pour le serveur de fichiers. Cela indique généralement que la résolution de nom et l’authentification de domaine fonctionnent.

Décision : s’il n’y a pas de ticket cifs/ et que vous échouez répétitivement, vérifiez les SPN, le décalage horaire, ou l’interdiction de NTLM par la politique.

Tâche 16 : Vérifier les journaux client SMB pour une erreur plus précise

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.

Ce que cela signifie : le client SMB confirme l’échec. Souvent, des événements proches contiennent des détails sur la négociation, la signature, ou l’authentification.

Décision : si vous voyez des erreurs de négociation ou des exigences de signature, alignez les politiques SMB client/serveur. Si vous ne voyez que « chemin non trouvé », revenez aux vérifications nom/port/service.

Tâche 17 : Sur le serveur, confirmer que le chemin du partage existe sur le disque

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

Ce que cela signifie : le répertoire sous‑jacent existe. Si c’est False, le partage peut exister mais pointer vers nulle part (ou le volume n’est pas monté).

Décision : si le chemin est manquant, enquêtez sur le stockage : montage échoué, déconnexion iSCSI, disque de cluster hors ligne, cible DFS cassée, ou volume NAS non exporté.

Tâche 18 : Vérifier les referrals DFS quand le « serveur » est en fait 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)

Ce que cela signifie : DFS est en jeu. Une cible ou un referral cassé peut apparaître comme « chemin réseau introuvable », surtout si les clients sont renvoyés vers un nœud hors ligne.

Décision : corrigez la santé des cibles DFS, désactivez la cible morte, ou corrigez le costing des sites. Ne blâmez pas « le réseau » quand DFS donne de mauvaises directions.

Blague n°2 : « Chemin réseau introuvable » est la façon de Windows de dire « je suis allé à la porte, mais le bâtiment a soit disparu soit est verrouillé—bonne chance. »

Erreurs courantes : symptôme → cause racine → correctif

Cette section est directe parce que les mêmes erreurs se répètent dans chaque entreprise avec une file de tickets helpdesk et une fenêtre de changement.

1) Symptom : Le nom d’hôte échoue, l’IP fonctionne

Cause racine : enregistrement A DNS pointant vers l’ancien serveur ; cache obsolète ; suffixe DNS erroné ; split‑brain DNS entre on‑prem et VPN.
Correctif : corriger les enregistrements DNS (et la purge), vider le cache client, vérifier que les clients utilisent les bons serveurs DNS, et arrêter de compter sur les broadcasts NetBIOS.

2) Symptom : Fonctionne sur LAN du bureau, échoue sur VPN

Cause racine : split tunneling VPN qui exclut les sous‑réseaux des serveurs de fichiers ; pare‑feu VPN qui bloque le 445 ; DNS via VPN qui renvoie une vue incorrecte.
Correctif : router le sous‑réseau du serveur de fichiers via le VPN, autoriser le TCP 445 vers les serveurs approuvés, et aligner la vue DNS avec le chemin d’accès.

3) Symptom : Échec soudain pour tout le monde après durcissement

Cause racine : GPO qui désactive le client SMB, bloque NTLM, impose la signature SMB, ou désactive l’accès invité ; changement de politique pare‑feu bloquant SMB inbound.
Correctif : revenir en arrière ou ajuster la politique avec une liste d’exceptions contrôlée ; valider les paramètres de signature SMB/NTLM sur les deux bouts ; tester avec un groupe pilote.

4) Symptom : Un seul partage échoue ; les autres sur le même serveur fonctionnent

Cause racine : partage renommé, supprimé, ou pointant vers un volume manquant ; cible DFS cassée ; permission de niveau partage supprimée.
Correctif : confirmer que le partage existe côté serveur, vérifier le chemin du partage, restaurer le montage du volume, ou corriger la cible/referral DFS.

5) Symptom : Serveur joignable, mais l’Explorateur montre vide / long délai puis erreur

Cause racine : la négociation SMB cale à cause d’un mismatch de signature/chiffrement ; antivirus/EDR intercepte SMB ; middleboxes réseau malmènent les paquets.
Correctif : vérifier les journaux client/serveur SMB, contourner temporairement l’inspection pour tester, valider le support du dialecte SMB, et confirmer que le MTU/fragmentation est correct.

6) Symptom : Ancien NAS inaccessible après une mise à jour Windows

Cause racine : le NAS ne supporte que SMB1 ; une mise à jour Windows a retiré/désactivé le client SMB1.
Correctif : mettre à jour le firmware/config du NAS pour SMB2/3. Si impossible, isoler ce NAS et activer SMB1 client uniquement pour les machines requises temporairement.

7) Symptom : « Chemin introuvable » intermittent, surtout sur stockage en cluster

Cause racine : la haute disponibilité SMB n’est pas réellement continue ; basculements de cluster coupent les sessions ; problèmes backend de stockage démontent des volumes.
Correctif : valider les rôles de cluster et les réglages de partage, vérifier la stabilité multipath/iSCSI, et corréler les événements de basculement avec les rapports utilisateurs.

Trois mini‑histoires d’entreprise (comment ça foire en réalité)

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a migré son serveur de fichiers vers une nouvelle VM. Même nom d’hôte, nouvelle IP, « pas de problème ». L’équipe a mis à jour le DNS et testé depuis
quelques postes IT. Tout le monde est parti chez soi.

À 8h30, le helpdesk a commencé à voir 0x80070035 dans plusieurs départements. Pas tous. Juste assez pour créer la panique.
L’ingénieur d’astreinte a supposé « la nouvelle VM est down » et a redémarré le service SMB. Pas de changement. Puis a redémarré la VM. Toujours rien.

La cause était douloureusement simple : deux serveurs DNS. L’un avait l’enregistrement A mis à jour. L’autre n’a pas répliqué correctement et continuait de servir l’ancienne IP.
Les postes étaient configurés avec les deux serveurs DNS, donc la résolution dépendait de celui qui répondait en premier. Le serveur de fichiers n’était pas mort ;
la moitié des clients étaient envoyés vers une adresse morte.

Le correctif a été de corriger la réplication et forcer un transfert de zone, puis vider les caches clients. La leçon était plus importante que la réparation :
« DNS mis à jour » n’est pas une affirmation. C’est une hypothèse qu’il faut vérifier sur plusieurs résolveurs.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait un projet de « réduction de latence ». Quelqu’un a remarqué que le trafic SMB faisait un détour via un pare‑feu central quand des agences
accédaient au cluster de fichiers du siège. La solution proposée : ajouter une politique de pare‑feu bloquant SMB depuis des sous‑réseaux non approuvés et
forcer les branches à utiliser un service de cache local.

Le déploiement du service de cache a été retardé, mais le changement de pare‑feu est passé à l’heure parce que c’était « sûr » : après tout, la plupart du SMB ne devrait pas
quitter le siège. La demande de changement incluait même une liste de sous‑réseaux « autorisés ».

À midi, l’ingénierie ne pouvait plus accéder aux artefacts build sur \\buildshare. La finance ne pouvait pas ouvrir les tableaux de fin de mois. L’erreur
n’était pas « bloqué par la politique ». C’était 0x80070035. Les clients Windows ne racontent pas vos changements de pare‑feu ; ils échouent simplement.

Cause : la liste des autorisés n’incluait pas un pool d’adresses VPN utilisé par le personnel à distance et un ensemble de nouveaux VLAN Wi‑Fi. L’« optimisation » était correcte en esprit mais déployée dans le mauvais ordre et sans visibilité des refus 445.

Le correctif n’a pas été seulement d’ajouter des sous‑réseaux. Ils ont mis en place des déploiements par étapes avec journalisation des refus, tableaux de bord centrés sur les blocs TCP 445, et un client canari dans chaque segment réseau majeur. La morale : optimisez en dernier, après avoir la visibilité sur ce que vous cassez.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise gérait des espaces de noms DFS pour les partages utilisateurs avec plusieurs cibles par site. Ce n’était pas excitant. Ce n’était pas tendance. C’était
cohérent, documenté, et testé trimestriellement. L’équipe stockage tenait un runbook simple : valider la santé des referrals DFS, valider l’écoute SMB,
valider les chemins de partage, valider les volumes backend.

Un matin, un bug firmware sur une baie de stockage a fait chuter momentanément un sous‑ensemble de LUNs. Sur deux serveurs de fichiers, le volume hébergeant un
partage critique est revenu avec une lettre de lecteur différente due à un changement d’ordre de montage. Le partage existait encore dans l’OS—mais pointait vers un
chemin vide. Les clients obtenaient « chemin réseau introuvable » de manière intermittente selon la cible DFS qui les avait été renvoyés.

L’ingénieur d’astreinte n’a pas deviné. Il a suivi le runbook. Première étape : Test-NetConnection 445 (bon). Deuxième : Get-SmbShare sur les deux cibles
(le partage existe). Troisième : Test-Path sur le chemin du partage (false sur deux nœuds). Quatrième : corriger les points de montage et valider.

Le temps d’indisponibilité a été limité parce que quelqu’un avait fait le travail ennuyeux en amont : surveillance cohérente des cibles DFS et habitude de vérifier les chemins de partage par rapport aux montages de stockage. Pas d’héroïsme. Pas de poésie Slack à minuit. Juste un système qui échoue de manière connue et une équipe qui reconnaît le motif.

Faits intéressants et brève histoire (SMB, réseau Windows et pourquoi on souffre)

Fait 1 : SMB a commencé chez IBM dans les années 1980 puis a été adopté et étendu par Microsoft ; il est plus ancien que beaucoup de plans de « modernisation » en production.
Fait 2 : Le réseau Windows reposait historiquement sur la résolution NetBIOS et les broadcasts—pratique sur des LAN plats, chaotique sur des réseaux routés.
Fait 3 : TCP 445 (« SMB over TCP ») a réduit la dépendance à NetBIOS sur TCP 139, mais de nombreux environnements portent encore des hypothèses héritées de l’ère 139.
Fait 4 : Les faiblesses de SMB1 sont devenues si notoires que les Windows modernes désactivent SMB1 par défaut ; cela casse les anciens NAS exactement comme prévu.
Fait 5 : Un même chemin UNC peut traverser des piles différentes : SMB direct, espaces de noms DFS, ou même WebDAV dans certains cas—chacune avec des modes de défaillance distincts.
Fait 6 : Les erreurs de l’Explorateur Windows condensent souvent plusieurs échecs sous une même phrase générique ; les journaux d’événements sont généralement plus spécifiques.
Fait 7 : La signature et le chiffrement SMB améliorent l’intégrité/la sécurité mais peuvent provoquer des échecs de négociation quand politiques client/serveur sont désalignées.
Fait 8 : « Network Location Awareness » (NLA) influence les profils de pare‑feu ; une mauvaise classification en Public peut bloquer silencieusement le trafic de partage de fichiers.
Fait 9 : Les referrals DFS peuvent changer en fonction du mapping site/subnet AD ; un mauvais mapping de site peut envoyer les clients vers des cibles lointaines ou mortes.

Checklists / plan pas‑à‑pas (pour les humains sous pression)

Checklist A : Un seul utilisateur signale 0x80070035

Faites‑lui essayer le chemin IP : \\10.20.30.40\share. Si ça marche, c’est la résolution de noms.
Sur le client : exécutez Test-NetConnection server -Port 445. Si ça échoue, c’est réseau local/VPN/politique.
Supprimez les mappages : net use * /delete (prenez garde) ou retirez le lecteur spécifique, puis reconnectez.
Videz le cache DNS : ipconfig /flushdns.
Vérifiez le profil : Get-NetConnectionProfile. Si Public, corrigez la classification réseau.
Récupérez les événements du journal SMBClient Opérationnel autour de l’heure de la panne.

Checklist B : Toute l’équipe ne peut pas accéder à un partage

Confirmez que le partage existe côté serveur : Get-SmbShare ou la liste de partage du NAS.
Confirmez que le chemin du partage existe : Test-Path sur le serveur ; vérifiez les points de montage/volumes.
Confirmez le service SMB et le port à l’écoute sur le serveur : Get-Service LanmanServer, Get-NetTCPConnection -LocalPort 445.
Vérifiez les changements de politique pare‑feu et les logs de refus pour le port 445.
Si DFS : validez les referrals et la santé des cibles ; désactivez les cibles mortes.

Checklist C : « Ça marchait hier » après patch ou déploiement de politique

Vérifiez si SMB1/guest/NTLM a changé côté client ou serveur.
Validez que les exigences de signature SMB correspondent des deux côtés.
Vérifiez les règles Windows Firewall sous « File and Printer Sharing ».
Comparez une machine qui marche et une qui échoue : serveurs DNS, posture VPN, catégorie réseau, et versions des agents de sécurité.
Revenez en arrière sur la politique si vous ne pouvez pas prouver que le changement est sans effet nuisible.

FAQ

Q1 : 0x80070035 est‑il la même chose que « System error 53 » ?

Ils sont étroitement liés. net use rapporte souvent des problèmes de connectivité/nom/chemin comme « System error 53 has occurred. The network path was not found. »
L’Explorateur peut afficher 0x80070035 pour la même classe d’échec sous‑jacente.

Q2 : Pourquoi l’usage de l’IP fonctionne parfois quand le nom d’hôte échoue ?

Parce que vous contournez le DNS et toutes les couches de résolution de nom (suffixe DNS, WINS/NetBIOS fallback, résultats en cache). Si l’IP fonctionne, votre transport est correct.
Corrigez le nommage, pas les pare‑feu.

Q3 : Quel port faut‑il ouvrir pour les partages SMB ?

SMB moderne utilise TCP 445. Le NetBIOS/SMB legacy peut impliquer 137–139, mais vous devriez utiliser 445 pour les plateformes Windows et NAS supportées.
Si le 445 est bloqué, attendez‑vous à 0x80070035 ou échecs similaires.

Q4 : Les permissions peuvent‑elles provoquer 0x80070035 ?

Habituellement les problèmes de permissions apparaissent comme « Accès refusé », des invites d’identifiants, ou des erreurs d’authentification spécifiques. Mais des blocages de politique (comme « interdiction NTLM »)
peuvent se manifester par des échecs génériques. Vérifiez les journaux SMBClient et les journaux de sécurité serveur pour en avoir le cœur net.

Q5 : Pourquoi ça échoue seulement depuis chez moi ou seulement sur VPN ?

Le routage VPN et les règles de pare‑feu sont les coupables habituels. Le split tunneling peut exclure le sous‑réseau du serveur de fichiers, et certains profils VPN bloquent le 445 par défaut.
Confirmez avec Test-NetConnection -Port 445 depuis le client connecté au VPN.

Q6 : Dois‑je activer SMB1 pour réparer rapidement ?

Seulement si vous avez confirmé que le serveur/NAS ne supporte que SMB1 et que vous ne pouvez pas mettre à jour immédiatement. Activer SMB1 augmente la surface d’attaque.
Traitez‑le comme un pont temporaire avec confinement, pas comme une solution permanente.

Q7 : Et si le ping fonctionne mais SMB ne fonctionne pas ?

Le ping prouve la portée ICMP, pas la portée applicative. Les pare‑feu autorisent souvent ICMP mais bloquent le TCP 445. Ou le service SMB n’est pas en fonctionnement.
Testez explicitement le 445 et vérifiez l’état d’écoute du serveur.

Q8 : Et si le 445 se connecte mais que le partage indique toujours « introuvable » ?

Alors vous avez dépassé le routage/pare‑feu et êtes dans le territoire SMB/partage/DFS : mauvais nom de partage, partage supprimé, chemin de partage manquant, referral DFS cassé,
ou mismatch de négociation/politique qui fournit plus de détails dans les journaux que l’Explorateur.

Q9 : Comment savoir si DFS est impliqué ?

Si le chemin ressemble à \\domain\dfsroot\share, c’est du DFS. Utilisez dfsutil /pktinfo pour voir vers quelle cible vous avez été renvoyé.
Une cible de referral morte peut rendre le chemin « introuvable ».

Q10 : Pourquoi Windows affiche parfois des erreurs différentes pour le même problème ?

Différents composants exposent différentes abstractions : l’Explorateur, le client SMB, le redirector, le gestionnaire d’identifiants et DFS ont chacun leur propre cartographie d’erreur.
Faites confiance à la réalité au niveau paquet (pouvez‑vous vous connecter au 445 ?) et aux journaux d’événements plutôt qu’à la formulation du GUI.

Conclusion : prochaines étapes pratiques

0x80070035 n’est pas mystique. C’est une défaillance en couches : résolution de noms, connectivité TCP 445, disponibilité du service SMB, existence du partage, puis auth/politique.
La correction la plus rapide est la réfutation la plus rapide—essayez l’IP, testez le 445, validez que le partage existe, et lisez les journaux qui ne maquillent pas la réalité.

Prochaines étapes que vous pouvez entreprendre aujourd’hui :

Créez un runbook d’une page à partir du « Playbook de diagnostic rapide » et épinglez‑le là où votre astreinte le consulte vraiment.
Surveillez et alertez sur les refus TCP 445 aux frontières réseau (avec corrélation de changement), pas seulement sur l’utilisation CPU des serveurs.
Inventoriez les versions SMB sur les NAS/serveurs de fichiers ; éliminez les dépendances SMB1 avant la prochaine vague de durcissement Windows qui le retirera pour vous.
Pour les environnements DFS : validez régulièrement les referrals et retirez les cibles mortes. DFS est excellent jusqu’à ce qu’il redirige poliment les utilisateurs vers nulle part.
Standardisez un test canari depuis chaque segment réseau (LAN, VPN, VLAN Wi‑Fi) qui vérifie la résolution de nom et la connectivité 445 vers les partages critiques.