Erreur Microsoft Windows : Nom de périphérique local déjà attribué dans le réseau

L’erreur Microsoft Windows “Nom de périphérique local déjà attribué dans le réseau” apparaît surtout quand un lecteur réseau garde une vieille connexion bancale.

Le correctif le plus rapide consiste souvent à supprimer les mappages existants avec net use * /del /y, puis à reconnecter proprement le partage.

Si l’accès fonctionne avec une adresse du type 192.168.1.10partage, le souci vient presque toujours de la résolution de nom, de NetBIOS ou d’un cache réseau Windows qui fait n’importe quoi.

Corriger l’erreur “Nom de périphérique local déjà attribué” sous Windows

On va pas tourner autour du pot : cette erreur arrive quand Windows croit qu’une lettre de lecteur ou une session réseau est déjà utilisée, alors que l’utilisateur ne voit parfois rien dans l’Explorateur.

Le message peut apparaître au démarrage, après une sortie de veille, ou au moment d’ouvrir un dossier partagé sur un NAS, un serveur Windows, une Freebox Pro ou un partage Samba.

La première action propre consiste à ouvrir une invite de commandes en administrateur et lancer net use. Cette commande montre les connexions réseau encore enregistrées, même celles qui ne sont plus visibles.

Si un lecteur fantôme traîne, la commande net use * /del /y nettoie les anciennes connexions. Ensuite, il faut remapper le lecteur avec une lettre libre, par exemple net use Z: serveurpartage.

Le bricolage via l’Explorateur Windows peut marcher, mais la ligne de commande dit la vérité. C’est moins joli, certes, mais en prod on cherche du fiable, pas du vernis.

Pourquoi Windows affiche “Le nom du périphérique local est déjà utilisé”

La cause la plus courante reste le conflit de lettre de lecteur. Windows tente de restaurer un lecteur réseau sur Z:, mais cette lettre est déjà prise par un disque USB, un ancien mapping ou une session pas purgée.

Autre classique : la résolution de nom part en vrille. Le poste ne sait plus traduire serveur vers la bonne adresse IP, alors que 192.168.1.xpartage fonctionne sans broncher.

Dans ce cas, il faut regarder côté DNS, suffixe réseau, NetBIOS et cache local. Un bon vieux ipconfig /flushdns peut aider, mais ce n’est pas magique si le serveur annonce mal son nom.

Les sessions SMB expirées provoquent aussi cette panne. Après une mise en veille longue, Windows garde l’impression d’être connecté, pendant que le serveur a déjà fermé la porte.

Depuis le durcissement de SMB, certains vieux équipements râlent davantage. SMB v1 est désactivé pour une bonne raison, notamment la sécurité, mais des boitiers anciens n’ont jamais été pensés pour SMB v2 ou v3.

Vérifier SMB, NetBIOS et le pare-feu Windows sans perdre du temps

Quand le mapping saute sans raison apparente, il faut vérifier SMB. Un NAS récent doit fonctionner en SMB v2 ou SMB v3, pas avec une antiquité laissée ouverte pour “compatibilité”.

Sur Windows, les fonctionnalités SMB se contrôlent dans les fonctionnalités facultatives. Activer SMB v1 à l’aveugle reste une mauvaise idée, sauf besoin temporaire et isolé.

NetBIOS peut encore sauver certaines installations un peu vieillottes. Dans les propriétés IPv4 de la carte réseau, puis paramètres avancés WINS, l’option Activer NetBIOS sur TCP/IP règle parfois le bazar.

Le pare-feu Windows mérite aussi son contrôle. Partage de fichiers et d’imprimantes doit être autorisé sur le bon profil réseau, surtout si Windows a basculé le réseau en public après une mise à jour.

Microsoft adore déplacer les menus, mais les bases restent les bases. Si le poste ne peut pas résoudre le nom, dialoguer en SMB et passer le pare-feu, le lecteur réseau ne tiendra pas.

NAS, Freebox Pro, Samba et VPN : les cas qui foutent le bronx

Avec un NAS Synology, QNAP ou Terramaster, le blocage peut venir d’une protection automatique. Après plusieurs mauvais identifiants, l’adresse IP du poste est parfois bannie sans prévenir clairement.

Sur une Freebox Pro, le piège vient souvent du plan d’adressage. Si le réseau passe en 192.168.10.x, les anciens raccourcis en 192.168.1.x deviennent bons pour la benne.

Son partage intégré utilise SMB v2.1 à SMB v3. Les vieux clients bricolés avec SMB v1 ne doivent pas être forcés à revenir dans le circuit, sauf à aimer les emmerdes de sécurité.

Avec OpenVPN et Samba, le problème est plus vicieux. Les routes doivent être poussées vers le client, le pare-feu doit accepter le trafic, et Samba doit écouter sur la bonne interface.

Si l’accès marche sur le LAN mais pas via VPN, le lecteur réseau n’est pas le coupable principal. C’est souvent la route, le DNS interne ou la règle firewall qui coince, point barre.

Nettoyer les mappages Windows et stabiliser les lecteurs réseau

Pour repartir proprement, il faut supprimer les anciens mappages, redémarrer la session réseau, puis recréer les connexions. La séquence net use * /del /y, redémarrage, puis nouveau mapping reste une méthode carrée.

Le service Computer Browser peut aussi être relancé sur les systèmes où il existe encore. Les commandes net stop browser puis net start browser peuvent débloquer certains environnements anciens.

Il faut également vérifier l’espace libre côté serveur. Un partage réseau saturé peut refuser de nouvelles connexions et produire des symptômes qui ressemblent à un conflit local.

Dans les cas têtus, le registre Windows offre des leviers comme InvalidFileServerCacheLifeTime. Ce genre de réglage ne se pose pas au hasard, sinon on remplace une panne par une autre.

La règle propre reste simple : une lettre libre, un nom résolu correctement, un protocole SMB cohérent, et des identifiants valides. Le reste, c’est souvent du cache moisi et des parametres laissés de travers.