Le SMB distant se bloque après un changement de réseau car sa session TCP existante est liée à une adresse et une route qui n'existent plus.
Lorsqu'un ordinateur portable passe de l'Ethernet au Wi-Fi, du Wi-Fi domestique à un hotspot, ou d'un chemin VPN à un autre, son IP source, son interface, sa passerelle, son serveur DNS, son MTU et sa connectivité au NAS peuvent tous changer. Le SMB peut se reconnecter automatiquement, rester à moitié ouvert jusqu'à un délai d'attente, choisir une interface différente ou conserver des identifiants périmés et l'état des lecteurs mappés. Le diagnostic doit distinguer une interruption de session attendue d'un problème de route, DNS, VPN ou pilote sans fil qui empêche une reconnexion propre.
Confirmer que le changement de réseau interrompt une session existante
Ouvrez le partage distant et lancez un transfert contrôlé, puis changez de réseau en enregistrant l'heure, les anciennes et nouvelles adresses client, l'état du VPN et l'erreur SMB. Testez une nouvelle connexion après le changement séparément du transfert initial.
Un cas Microsoft Q&A note que les sessions SMB existantes se coupent lorsqu'un ordinateur portable passe de l'Ethernet au Wi-Fi car le chemin et le profil réseau changent. Une icône rouge déconnectée peut se rétablir à l'accès, tandis qu'un montage bloqué de façon permanente signale un problème supplémentaire.
Si une nouvelle connexion au partage fonctionne mais que l'ancien transfert échoue, la transition réseau s'est comportée comme prévu et le flux de travail nécessite un support de reprise ou de reconnexion. Si même une nouvelle connexion se bloque, poursuivez avec les vérifications de route, DNS, VPN et état client.
Comparer les routes avant et après le changement
Enregistrez la route vers l'adresse NAS sur l'ancienne interface puis à nouveau après activation du nouveau réseau. Vérifiez le préfixe de destination, la passerelle, la métrique, l'interface VPN et si une ancienne route reste installée.
Un cas Ask Different décrit un accès SMB intermittent après qu'un réseau a été divisé en VLANs, avec une reconnexion réseau restaurant l'accès. Ce schéma encourage à vérifier l'état des routes et interfaces avant de considérer le partage NAS comme indisponible.
Si la route NAS pointe toujours vers l'interface déconnectée, renouvelez les routes ou reconnectez le VPN. Si la nouvelle route chevauche le sous-réseau NAS distant, corrigez le split-tunnel ou le conflit d'adressage avant de nettoyer les sessions SMB.
Vérifier la résolution DNS et le nom d'hôte sur le nouveau réseau
Résolvez le nom d'hôte du NAS avant et après le changement de réseau et comparez les enregistrements A, AAAA, suffixe de recherche et serveur DNS. Testez ensuite le partage via l'IP connue du VPN ou du NAS.
Un nom d'hôte peut se résoudre localement via le DNS du routeur ou mDNS mais échouer sur un hotspot, tandis qu'une politique DNS VPN peut arriver plusieurs secondes après le changement d'interface. Les chemins mappés existants peuvent conserver le nom même si le résolveur actuel retourne une adresse différente ou inaccessible.
Si l'IP fonctionne mais pas le nom d'hôte, corrigez le DNS fractionné, le DNS VPN, les suffixes ou les réponses en cache. Si les deux échouent, poursuivez l'investigation sur le routage, le pare-feu ou la connectivité du tunnel.
Effacer la session SMB cassée sans redémarrer l'ordinateur portable
Arrêtez la copie échouée, déconnectez le partage mappé affecté ou le montage, et fermez les applications maintenant des fichiers ouverts. Supprimez uniquement la connexion SMB périmée avant de vous reconnecter via le nouveau réseau.
Windows et d'autres clients peuvent conserver un état à moitié ouvert jusqu'à l'expiration des délais TCP et SMB. Redémarrer masque ce comportement mais ne prouve pas si la correction réelle était le nettoyage de session, la récupération de route ou la correction DNS.
Si un remontage propre fonctionne immédiatement, automatisez la reconnexion ou utilisez un outil de transfert qui reprend après les changements de chemin. Si le remontage bloque, capturez une nouvelle tentative de connexion et poursuivez les tests VPN, pare-feu ou pilote d'interface.
Tester si le changement d'interface déclenche une défaillance du pilote
Surveillez les journaux système lors des passages entre Wi-Fi, Ethernet et hotspot. Recherchez des réinitialisations d'adaptateur, des échecs d'installation de clé, des pertes de routes par défaut, des erreurs de service DNS ou un VPN restant lié à l'ancienne interface.
Un rapport de la communauté Intel décrit un AX210 perdant une session SMB pendant une activité Wi-Fi, notant qu'une réinitialisation sans fil fait perdre la session même si le NAS restait disponible.
Si l'interface disparaît ou se réinitialise, mettez à jour ou revenez à une version antérieure du pilote réseau et reproduisez la transition sans SMB. Si l'interface reste saine, évitez d'incriminer le matériel Wi-Fi et revenez aux routes, état VPN et récupération de session.
Valider la reconnexion et la reprise sur tous les réseaux requis
Testez la séquence de transition que les utilisateurs effectuent réellement : Wi-Fi domestique vers hotspot mobile, Ethernet vers Wi-Fi, ou Wi-Fi public vers VPN. Confirmez une nouvelle connexion SMB, l'authentification, la liste des répertoires, la lecture, l'écriture et la reprise du transfert.
Le guide ZimaSpace sur un serveur accessible avec des délais SMB couvre la couche suivante lorsque la connectivité réseau revient mais que le partage reste bloqué.
Le problème est résolu uniquement lorsque l'ancienne session échoue de manière prévisible ou se reconnecte proprement, qu'une nouvelle session suit la bonne route et le bon nom d'hôte, et que l'outil de transfert reprend sans recopier les données déjà transférées. Ne vous attendez pas à ce qu'une session TCP survive à un changement d'adresse source sauf si le protocole et le client supportent explicitement la migration de chemin.
Assistance et conseils
Plus à lire

How to Reduce Plex Database Contention on a Busy Docker Host
A Plex configuration guide for busy hosts that treats the database as local application state and reduces I/O contention without inventing a shared DB...

How to Prevent Duplicate Plex Scans and Imports
A prevention guide for duplicate Plex scans and imports that removes overlapping triggers instead of disabling library updates entirely.

How to Recover Plex After Its App-Data Volume Fills Up
A recovery ladder for full Plex app-data volumes that protects the database first and avoids deleting unknown files just to make the service start.

