Guide de dépannage du client SMB pour Windows, macOS et Linux

La méthode sûre consiste à traiter un test courant par étapes, qui sépare la découverte, le transport, l’authentification, l’accès au partage et les opérations sur les fichiers pour chaque client, comme une succession de contrôles observables, et non comme une commande unique.

Sur un NAS domestique desservant des clients SMB Windows, macOS et Linux, le risque pratique est qu’un partage SMB fonctionne depuis un système d’exploitation, mais échoue ou se comporte différemment depuis un autre. Notez l’identité actuelle et le point de récupération, commencez par le discriminant le moins invasif, interprétez les résultats réussis et échoués avant de modifier une autre variable, et arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable risquerait d’être exposée. Le flux de travail ci-dessous ne se termine qu’une fois la charge de travail initiale exécutée avec succès ou lorsque les éléments recueillis atteignent un seuil nécessitant une escalade.

Construire un test de contrôle multiplateforme unique

Choisissez une adresse IP du NAS, un nom d’hôte, un utilisateur connu, un partage et un dossier de test jetable. Notez les versions des systèmes d’exploitation clients, l’emplacement réseau, la commande du client SMB ou le chemin dans l’interface graphique, l’heure du serveur et le message d’erreur exact. Ne désactivez ni les contrôles de sécurité ni les pare-feu pendant la collecte de référence.

Un dépannage des connexions SMB par étapes divise les échecs de connexion SMB en recherche de nom, accessibilité du port TCP 445, négociation du protocole, authentification, connexion au partage et autorisation d’accès aux fichiers. Suivez cet ordre afin de ne pas prendre un ping fonctionnel pour une session SMB fonctionnelle.

Testez séparément l’adresse IP et le nom d’hôte depuis chaque client. Si seul le nom d’hôte échoue, corrigez le DNS ou la résolution locale des noms ; si le port TCP 445 est inaccessible, examinez le routage et la politique du pare-feu avant de modifier les mots de passe ou les autorisations du partage.

Éliminer l’ambiguïté des identifiants et confirmer la négociation

Déconnectez les sessions SMB existantes vers le même serveur et supprimez uniquement l’identifiant mis en cache concerné dans le Gestionnaire d’informations d’identification Windows, le trousseau d’accès macOS ou le fichier d’identifiants ou le trousseau Linux. Reconnectez-vous avec un nom de compte explicite et vérifiez si le serveur voit bien l’utilisateur associé prévu.

Vérifiez le dialecte SMB négocié, l’état de la signature, le chiffrement lorsqu’il est configuré et l’accès invité par rapport à l’accès authentifié. N’activez pas SMB1 et ne désactivez pas la signature simplement pour faire réussir un test ; comparez les politiques du client et du serveur et identifiez précisément le décalage.

L’article de ZimaSpace sur les différences SMB entre Windows et macOS porte sur le cas courant où Windows fonctionne, mais macOS échoue. Utilisez ses vérifications du nom d’hôte, des identifiants, de la signature et du Finder après que la référence partagée a montré que macOS est le seul système à diverger.

Séparer l’accès au partage des autorisations sur les fichiers

Après l’authentification, listez les partages, connectez-vous au nom exact du partage, puis testez l’affichage de la liste, la lecture, la création, le renommage et la suppression dans le dossier jetable. Capturez le propriétaire et l’ACL résultants sur le NAS. Un montage réussi suivi d’un échec lors de la création indique un problème d’autorisation, et non un problème de découverte.

Sous Linux, comparez un test en ligne de commande avec smbclient aux options de montage CIFS et au gestionnaire de fichiers du bureau. Un guide indépendant du montage d’un client SMB Linux présente les éléments du montage côté client ; les options qui ne font que présenter des valeurs locales d’UID et de GID ne modifient pas nécessairement l’autorisation côté serveur.

Sous macOS, notez la réutilisation des identifiants par le Finder et les fichiers de métadonnées ; sous Windows, notez les sessions existantes ouvertes sous un autre utilisateur. Utilisez le même compte serveur sur tous les clients afin que la mise en cache côté client ne soit pas confondue avec des autorisations NAS différentes.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Valider la charge de travail initiale et mesurer séparément

Une fois les opérations de base fonctionnelles, répétez la tâche initiale : copie séquentielle volumineuse, nombreux petits fichiers, ouverture et enregistrement d’une application ou reconnexion après une mise en veille. Mesurez un seul client à la fois avec le même jeu de fichiers et une connexion filaire avant d’attribuer les performances lentes à SMB.

Si le débit diffère, notez la signature, le chiffrement, la liaison Wi-Fi, l’utilisation du processeur client, l’utilisation du processeur serveur et la vitesse du stockage local. Ne combinez pas une correction de connectivité avec une optimisation spéculative des performances ; un partage peut être correctement configuré tout en étant plus lent parce qu’un client applique une politique plus stricte ou utilise un autre chemin réseau.

Clôturez le problème lorsque tous les clients prévus s’authentifient en tant que l’utilisateur correct, effectuent les opérations autorisées sur les fichiers, se reconnectent après un redémarrage et conservent la politique de sécurité requise. Procédez à une escalade lorsque les journaux du serveur indiquent des erreurs de protocole répétées, que le système de fichiers du NAS signale des erreurs d’E/S ou que seuls des clients hérités non pris en charge nécessitent un affaiblissement des paramètres.