Pourquoi le partage de fichiers SMB fonctionne-t-il sous Windows mais échoue-t-il sous macOS ?

Lorsque le partage de fichiers SMB fonctionne sous Windows mais échoue sous macOS, le serveur n'est probablement pas complètement hors ligne. Windows a déjà montré que le partage existe et qu'au moins un client peut y accéder. La différence réside plus probablement dans l'adresse utilisée, les identifiants enregistrés, l'identité du compte, la négociation SMB, les exigences de signature, les permissions du partage ou la façon dont le Finder gère les dossiers réseau.

La méthode de dépannage la plus sûre est de faire tester aux deux ordinateurs la même cible. Commencez par l'IP exacte du serveur et le nom du partage, puis passez par la résolution de nom d'hôte, l'authentification, la négociation de sécurité, les permissions, la compatibilité Samba et la performance du Finder. Ne commencez pas par activer SMB hérité ou désactiver la signature sur le Mac.

Confirmez d'abord que Windows et macOS ouvrent le même partage

Windows peut déjà avoir un lecteur mappé tel que \\192.168.1.50\Documents, tandis que l'utilisateur Mac clique sur une icône de serveur dans le Finder ou essaie seulement smb://nom-du-serveur. Ces tests peuvent pointer vers des adresses, comptes ou chemins de partage différents.

Sur l'ordinateur Windows, notez l'adresse du serveur fonctionnelle, le nom du partage, le nom d'utilisateur et si la connexion utilise une adresse IP ou un nom d'hôte. Puis appuyez sur Commande + K dans le Finder et entrez le chemin équivalent, comme smb://192.168.1.50/Documents.

Si le Mac peut ouvrir le chemin IP-et-partage précis, le service SMB et le partage sont fondamentalement accessibles. Le problème restant est plus probablement lié à la découverte, au DNS, aux identifiants enregistrés ou au format original du chemin.

Utilisez l'IP du serveur avant de vous fier à la découverte par le Finder

Windows et macOS ne découvrent pas toujours les appareils réseau de la même manière. Un serveur peut apparaître automatiquement dans l'Explorateur de fichiers Windows tout en restant absent de la vue Réseau du Finder.

Cela ne signifie pas nécessairement que macOS ne peut pas utiliser SMB. La découverte automatique dépend du DNS, du mDNS, du comportement compatible NetBIOS, de la résolution de nom du routeur et des annonces faites par le serveur de fichiers. L'accès direct via smb://IP/partage contourne la plupart de cette couche de découverte.

Si l'IP fonctionne, ne modifiez pas la configuration SMB et examinez plutôt le nom. Vérifiez si le nom d'hôte résout la bonne adresse, si le serveur se publie via mDNS, et si le Mac a mis en cache une ancienne adresse.

Effacez les identifiants enregistrés avant de réinitialiser le mot de passe du serveur

macOS peut réutiliser les identifiants SMB stockés dans le trousseau. Cela devient déroutant lorsqu'un mot de passe change, que le même serveur est accédé à la fois par IP et par nom d'hôte, ou que l'utilisateur a précédemment sélectionné l'accès invité.

Déconnectez le partage monté, ouvrez Accès au trousseau, et recherchez le nom d'hôte du serveur, l'adresse IP et le nom du partage. Supprimez les entrées obsolètes, puis reconnectez-vous en entrant le compte qui existe réellement sur le serveur SMB.

Les étapes de dépannage d'Apple commencent par la vérification du nom d'utilisateur, mot de passe, nom d'hôte et accès au partage corrects. Bien que cette page traite des environnements SMB hébergés sur macOS, la même distinction est utile ici : l'authentification réussie et l'autorisation d'utiliser un partage particulier sont des vérifications différentes.

Assurez-vous que le Mac envoie la bonne identité de compte

Un ordinateur Windows peut se connecter automatiquement avec son compte connecté. Sur macOS, la boîte de dialogue de connexion peut par défaut utiliser le nom d'utilisateur du Mac, qui peut ne pas exister sur le serveur Windows, NAS ou Samba.

Le serveur peut attendre un compte serveur local, un utilisateur Samba, un compte Microsoft, une identité Active Directory ou un compte qualifié par un nom de machine, groupe de travail ou domaine. Selon l'environnement, les formats valides peuvent inclure nom d'utilisateur, SERVER\nom d'utilisateur, ou DOMAIN\nom d'utilisateur.

N'utilisez pas un code PIN Windows Hello comme mot de passe SMB. Un code PIN déverrouille normalement l'appareil Windows localement ; le serveur de fichiers nécessite toujours le mot de passe du compte sous-jacent ou une autre méthode d'authentification prise en charge.

Vérifiez si le port 445 est accessible depuis le Mac

Si le chemin SMB exact échoue avant qu'une invite de connexion n'apparaisse, vérifiez que le Mac peut atteindre le serveur sur le port TCP 445. Windows peut utiliser une interface réseau, un VLAN, un profil de pare-feu ou une route enregistrée différente.

Sur macOS, un test simple comme nc -vz 192.168.1.50 445 peut indiquer si le port accepte une connexion. Un délai d'attente suggère un problème de routage, d'isolation VLAN, de règles de pare-feu ou un serveur qui n'écoute pas sur l'interface attendue.

Si le port 445 est accessible mais que l'authentification échoue, le chemin réseau physique n'est plus le principal suspect. Passez aux identifiants, aux dialectes SMB, à la signature et aux permissions de partage.

La négociation du dialecte SMB peut différer entre les deux clients

Les routeurs anciens, les appareils NAS hérités et les installations Samba obsolètes peuvent proposer des combinaisons de protocoles qu'un ordinateur Windows accepte mais qu'un Mac actuel ne négocie pas avec succès.

La solution à long terme est de configurer le serveur pour SMB2 et SMB3 plutôt que de compter sur SMB1 ou une collection d'exceptions de compatibilité côté client. Une configuration Samba moderne peut explicitement utiliser SMB2 comme protocole minimum et SMB3 comme protocole maximum, ce qui offre à Windows et macOS une plage de négociation plus claire.

Ne supposez pas que la compatibilité Windows prouve que la configuration du serveur est moderne. SMB1 ou une authentification héritée peuvent avoir été activés manuellement sur cette machine Windows, tandis que le Mac utilise une base de sécurité différente.

Les exigences de signature et d'authentification doivent correspondre

La signature SMB vérifie que les messages n'ont pas été modifiés en transit. Une connexion peut échouer lorsque le client et le serveur ne sont pas d'accord sur les capacités de sécurité SMB, l'authentification, la signature ou le comportement validate-negotiate.

Apple note que SMB 3 est la méthode de connexion par défaut sur macOS, que les sessions SMB 3 authentifiées utilisent la signature, et que certains environnements liés à un annuaire peuvent échouer lors des vérifications SMB 3 validate-negotiate et session-signing. C'est un cas spécifique d'Open Directory, mais cela illustre pourquoi un message générique « connexion échouée » peut provenir d'une négociation de sécurité plutôt que d'un problème réseau basique.

Ne pas définir signing_required=no ou validate_neg_off=yes comme première réponse. Désactiver la validation ou la signature peut réduire la protection contre l'interception. Confirmez d'abord que le serveur prend en charge une version SMB actuelle et dispose d'une politique de signature cohérente.

L'accès invité n'est peut-être pas ce que Windows utilise réellement

Un partage Windows peut s'ouvrir sans afficher de demande de mot de passe, ce qui amène l'utilisateur à supposer qu'il s'agit d'un partage invité. En réalité, Windows peut réutiliser des identifiants mis en cache depuis le Gestionnaire d'identifiants ou le compte connecté.

Sur le client Windows, inspectez la session SMB active ou déconnectez le partage mappé puis reconnectez-le explicitement. Utilisez ensuite le même compte côté serveur sur le Mac.

Si le partage est intentionnellement anonyme, confirmez que le serveur permet l'accès invité et mappe les utilisateurs invités à un compte avec des permissions système de fichiers appropriées. Évitez d'activer un accès invité large simplement pour contourner un problème d'identifiants non résolu.

Les permissions de partage et les permissions du système de fichiers sont distinctes

Un Mac peut s'authentifier avec succès mais voir un partage vide, recevoir un « permission refusée » ou monter le dossier en lecture seule. Dans ce cas, la connexion SMB a fonctionné ; l'autorisation des fichiers non.

La plupart des serveurs de fichiers évaluent au moins deux couches. La configuration du partage décide quels utilisateurs peuvent accéder au partage, tandis que les permissions NTFS, la propriété POSIX ou les ACL du système de fichiers déterminent ce que ces utilisateurs peuvent lire, créer, modifier et supprimer.

Testez Windows et macOS avec le même compte serveur. Si un client utilise un utilisateur ou un groupe différent, leurs résultats ne sont pas directement comparables. Vérifiez également si le Mac s'est accidentellement connecté en tant qu'invité alors que Windows utilisait un compte authentifié.

Samba peut nécessiter un meilleur support des métadonnées macOS

Si le serveur utilise Samba, la compatibilité Windows de base ne garantit pas un comportement idéal sous macOS. Finder et les applications Mac utilisent des attributs étendus, des métadonnées Finder, des flux de données alternatifs et des forks de ressources que les clients Windows ne demandent peut-être jamais.

Une configuration Samba destinée à un usage mixte Windows et macOS peut activer les métadonnées macOS via fruit et streams_xattr. Une configuration typique peut inclure vfs objects = catia fruit streams_xattr afin que les métadonnées spécifiques à Apple puissent être représentées sans perturber l'accès normal sous Windows.

Ces modules sont les plus pertinents lorsque le partage est monté mais que les noms de fichiers, les attributs étendus, les forks de ressources, le comportement de Time Machine ou les métadonnées de Finder sont incohérents. Ils ne remplacent pas la correction d'un mot de passe incorrect ou d'un serveur inaccessible.

Les problèmes de performance de Finder peuvent ressembler à des échecs de connexion

Parfois, le partage est connecté, mais Finder affiche un répertoire vide, tourne pendant plusieurs secondes ou devient non réactif lors de l'ouverture d'un dossier volumineux. L'utilisateur perçoit cela comme un « SMB cassé », même si le montage lui-même a réussi.

Finder peut demander des métadonnées de fichiers, des permissions, des aperçus, des informations de ressources et des mises à jour de répertoire. Ces opérations affectent un Mac différemment d’une simple liste de répertoire Windows, surtout sur de grands dossiers ou des serveurs sans gestion des métadonnées orientée Apple.

Testez le même partage monté dans Terminal avec des commandes telles que ls, ou copiez un gros fichier sans parcourir d’abord un grand répertoire. Si l’accès via Terminal fonctionne alors que Finder reste lent, dépannez les métadonnées et l’énumération de répertoire plutôt que l’authentification.

Un partage lent n’est pas la même chose qu’un partage échoué

Ne combinez pas les échecs d’authentification et les problèmes de vitesse de transfert en un seul diagnostic. Un Mac qui ne peut pas monter un partage a un problème différent d’un Mac qui monte avec succès mais écrit lentement.

Dans un cas de la communauté Unraid, les lectures atteignaient environ 180 Mo/s tandis que les écritures tombaient à environ 2 Mo/s, même si les tests de disque local et réseau étaient beaucoup plus rapides. C’est utile comme motif de symptôme, mais cela ne prouve pas que la signature soit la cause universelle ; la disposition du stockage, le comportement du cache, les petits fichiers, les interfaces client et les réglages Samba peuvent produire une asymétrie similaire.

Mesurez séparément : débit réseau, lecture d’un gros fichier, écriture d’un gros fichier, et charge de travail avec de nombreux petits fichiers. N’ajustez les paramètres de performance SMB qu’après avoir identifié quel test est réellement lent.

Samba basé sur Docker ajoute des problèmes de mappage utilisateur et de volume

Un conteneur Samba peut accepter les connexions Windows tout en rejetant celles de macOS car les deux clients ne présentent pas la même identité. Le conteneur peut aussi publier correctement le port 445 alors que son volume monté a une propriété ou des ACL incompatibles.

Vérifiez le compte Samba à l'intérieur du conteneur, l'UID et le GID de l'hôte utilisés pour le stockage monté, les permissions de lecture/écriture du volume, le port publié, et l'efficacité smb.conf. Consultez les journaux du conteneur pendant que le Mac tente de se connecter.

Si la requête atteint le conteneur et que l’authentification réussit, arrêtez de modifier le réseau Docker. Concentrez-vous sur le mappage des utilisateurs, la configuration des partages, la propriété du système de fichiers, et le support des métadonnées Apple.

Considérez les ajustements SMB côté client comme la dernière couche

Les correctifs en ligne fournissent souvent un long /etc/nsmb.conf fichier qui désactive la signature, modifie la mise en cache des répertoires, force un protocole ou modifie le comportement multicanal. Copier tous ces paramètres en même temps rend impossible de savoir quel changement a eu un effet.

Les modifications testées par la communauté impliquant la mise en cache des répertoires et le comportement multicanal filaire peuvent aider certaines combinaisons spécifiques macOS, réseau et Unraid. La même discussion inclut aussi des options réduisant la sécurité et des résultats contradictoires, donc elle doit être considérée comme un dépannage expérimental plutôt qu’une configuration universelle.

Avant de modifier nsmb.conf, enregistrer l'état actuel et changer un paramètre à la fois. Retester le même dossier et transfert de fichier après chaque changement. Évitez de désactiver la signature uniquement pour la vitesse à moins que le compromis de sécurité soit compris et que le partage soit limité à un réseau de confiance.

Suivre un ordre de dépannage en couches

Le processus le plus efficace commence par la cible exacte et évolue vers un comportement client de plus en plus spécifique. Ne modifiez pas simultanément les paramètres Samba, Trousseau, DNS, signature et Finder.

Commencer avec le chemin Windows fonctionnel, tester smb://IP/partage sur macOS, et confirmer le port 445. Ensuite, effacer les identifiants enregistrés, vérifier l'identité du compte, et vérifier la prise en charge SMB2/3. Après cela, examiner la signature, les permissions de partage, les ACL du système de fichiers, les extensions Apple de Samba, et les performances du Finder.

Cette séquence préserve les preuves de chaque test. Un résultat IP contre nom d'hôte identifie les problèmes de découverte ; une invite de connexion identifie un service SMB accessible ; un partage monté mais en lecture seule identifie les permissions ; et une session Terminal fonctionnelle avec une fenêtre Finder lente identifie le comportement de navigation côté client.

Conclusion finale

Quand SMB fonctionne sous Windows mais échoue sur macOS, utilisez la connexion Windows comme référence plutôt que comme preuve que tous les paramètres serveur sont corrects. Les deux clients peuvent utiliser des adresses, noms d’utilisateur, identifiants en cache, capacités de protocole ou permissions différents.

Commencez par l’adresse exacte smb://IP/partage chemin. Si l’IP fonctionne mais que le nom d’hôte échoue, dépannez la découverte. Si la connexion échoue, effacez les identifiants du Trousseau et vérifiez le compte serveur. Si l’authentification réussit mais que l’accès aux fichiers ne fonctionne pas, inspectez les permissions du partage et les ACL du système de fichiers. Si le partage se monte mais que Finder est lent, passez aux métadonnées, aux extensions Apple de Samba et aux tests de performance mesurés.

Les options côté client qui désactivent la signature ou les vérifications de négociation doivent rester un dernier recours. Un serveur SMB2/3 à jour, un mappage clair des comptes, des permissions correctes et un support délibéré des métadonnées macOS offrent une solution plus fiable que d’affaiblir la sécurité pour compenser une incompatibilité de configuration inexpliquée.

FAQ

Pourquoi Windows voit-il mon serveur SMB alors que Finder ne le peut pas ?

Windows et macOS peuvent utiliser des méthodes de découverte différentes. Essayez l’adresse IP exacte du serveur et le chemin du partage avec smb://192.168.x.x/partageSi cela fonctionne, le problème vient de la résolution ou de la découverte du nom d’hôte plutôt que de SMB lui-même.

Pourquoi mon Mac rejette-t-il sans cesse un mot de passe qui fonctionne sous Windows ?

Le Mac peut réutiliser un ancien mot de passe du Trousseau ou envoyer son nom d’utilisateur local macOS au lieu du compte serveur. Supprimez l’identifiant SMB enregistré et reconnectez-vous avec le compte défini sur le serveur de fichiers.

Dois-je désactiver la signature SMB sur macOS ?

Pas comme première solution. Désactiver la signature réduit la protection de l’intégrité des messages et peut masquer une configuration serveur obsolète ou incohérente. Vérifiez d’abord la prise en charge SMB2/3, les identifiants, les permissions et la politique de signature du serveur.

Pourquoi le Mac peut-il monter le partage mais pas créer ou modifier des fichiers ?

La connexion et l’authentification ont réussi, mais l’utilisateur peut ne pas avoir les droits d’écriture dans la configuration du partage SMB ou dans les permissions du système de fichiers NTFS/POSIX sous-jacent.

Pourquoi Finder est-il lent alors que l’Explorateur de fichiers Windows est rapide ?

Finder demande des métadonnées supplémentaires et peut passer plus de temps à énumérer de grands répertoires. Testez un transfert direct de gros fichiers et comparez Finder avec Terminal avant de modifier les paramètres de sécurité.