Le serveur domestique est accessible mais les partages de fichiers expirent : que devez-vous tester ?

Un serveur domestique accessible peut toujours rencontrer un délai d’attente sur les partages de fichiers lorsque SMB lui-même est bloqué, arrêté, mal lié, surchargé ou bloqué dans une session échouée.

Le ping prouve seulement que le serveur répond à l’ICMP ; il ne prouve pas que le TCP 445 atteint l’écoute SMB, que le client négocie un protocole supporté, ou que le partage peut s’authentifier et s’énumérer. Le diagnostic le plus rapide progresse par couches : accessibilité IP, résolution du nom d’hôte, port 445, état du service SMB, chemin du partage, identifiants, et enfin charge du serveur pendant le délai d’attente.

Comparer l’IP du Serveur avec le Nom du Partage

Testez le partage par l’adresse IP actuelle du serveur et par son nom d’hôte normal depuis le même client. Notez si les deux expirent, si seul le nom échoue, ou si le nom se résout en une adresse IPv4 ou IPv6 différente.

Un cas de support OSMC a montré un hôte pouvant être pingé alors qu’un chemin SMB retournait toujours un délai d’attente de connexion. Cette distinction empêche un ping réussi d’éliminer prématurément les problèmes DNS, de port ou de service.

Si l’IP fonctionne mais que le nom échoue, corrigez le DNS, la découverte multicast, les suffixes ou les adresses mises en cache. Si les deux échouent de manière identique, poursuivez avec le TCP 445 et l’écoute SMB plutôt que de vider sans cesse les caches de noms.

Tester le Port TCP 445 Depuis le Client en Échec

Ouvrez un test de connexion TCP à l’adresse du serveur sur le port 445 depuis le même appareil qui subit le délai d’attente. Exécutez-le pendant la panne plutôt qu’après avoir redémarré le NAS ou reconnecté le client.

Un diagnostic Ask Ubuntu a distingué un ping fonctionnel d’un échec Samba en vérifiant si le port 445 était accessible. SMB sur les réseaux modernes dépend de ce chemin TCP même lorsque d’autres services serveur restent disponibles.

Si le port 445 expire, inspectez le VLAN client, le pare-feu hôte, le pare-feu NAS, la liaison d’interface et les ACL intermédiaires. S’il se connecte immédiatement, le chemin réseau est ouvert et le diagnostic doit passer à la négociation SMB, aux sessions, aux identifiants ou à l’état du partage.

Confirmer que le Service SMB Écoute sur la Bonne Interface

Vérifiez l’état du service SMB et les écouteurs actifs sur le serveur. Confirmez qu’il est lié à l’adresse LAN ou VLAN utilisée par le client, pas seulement à la boucle locale, une autre carte réseau, un pont de conteneur ou une ancienne adresse.

Redémarrer tout le NAS peut temporairement masquer un service arrêté ou bloqué. Préférez vérifier les journaux de service, la sortie des écouteurs et les changements de configuration récents avant de redémarrer afin que les preuves de la panne restent disponibles.

Si le service est arrêté, trouvez pourquoi il s’est arrêté et vérifiez la configuration du partage avant de le redémarrer. S’il écoute sur la mauvaise interface, corrigez la liaison et retestez depuis le client sans modifier les règles de pare-feu non concernées.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Séparer la Négociation du Protocole de l’Authentification

Utilisez un client SMB qui rapporte le dialecte négocié et le code d’erreur. Comparez un chemin de partage direct avec la navigation à la racine du serveur, car la découverte, l’énumération, l’authentification et l’ouverture d’un partage connu sont des opérations distinctes.

Un rapport de la communauté Synology a décrit un NAS dont le nom d’hôte et l’adresse étaient accessibles alors que le port SMB 445 échouait sur les résultats IPv4 et IPv6.

Si la connexion TCP s’ouvre mais que la négociation échoue, comparez les versions SMB, la signature, le chiffrement et la compatibilité client. Si la négociation réussit mais que l’authentification bloque ou échoue, effacez uniquement les identifiants stockés pertinents et vérifiez le compte, l’ACL du partage et l’état de verrouillage.

Effacer les Sessions Obsolètes Sans Supprimer la Configuration Fonctionnelle

Déconnectez les lecteurs mappés existants et les sessions SMB actives depuis le client en échec, puis reconnectez-vous en utilisant une adresse serveur explicite et un compte unique. Les sessions obsolètes peuvent conserver une ancienne adresse, un identifiant, un dialecte ou un transport déconnecté.

Vérifiez la table des sessions serveur en même temps. Une session qui reste établie alors que le client expire peut indiquer une connexion TCP à moitié ouverte, un client en veille, un changement de chemin VPN ou un basculement d’interface qui n’a pas réinitialisé proprement l’état SMB.

Effacez la session client individuelle avant de redémarrer le service SMB pour chaque utilisateur. Si le délai d’attente revient sur de nouvelles sessions, poursuivez vers la charge serveur et le comportement réseau plutôt que de considérer le nettoyage des sessions comme la solution finale.

Reproduire le Délai d’Attente en Surveillant la Charge du Serveur

Surveillez le CPU, la pression mémoire, la latence disque, la santé du pool, les files d’attente réseau, l’activité des conteneurs, l’analyse antivirus, l’indexation et le travail des instantanés lors de l’ouverture et de la liste du partage. Un serveur peut répondre au ping alors que le travailleur SMB ou le chemin de stockage attend assez longtemps pour provoquer un délai d’attente.

Le guide ZimaSpace sur un chemin de service NAS surchargé fournit les contrôles de performance adjacents après la réussite des tests de port et de protocole.

Le problème est résolu uniquement lorsque le même client peut se connecter, s’authentifier, lister les dossiers, lire, écrire, se déconnecter et se reconnecter pendant la fenêtre de panne. Si SMB expire alors que le port 445 reste ouvert et que le serveur est saturé, corrigez le goulot d’étranglement des ressources ou du stockage plutôt que d’ajouter des délais d’attente clients plus longs.