Partage SMB du Mac via VPN : connectez d’abord, testez l’écriture ensuite

Si le Finder monte le partage à travers le VPN puis refuse d’enregistrer un fichier, le tunnel fait déjà son travail et le désaccord porte sur l’identité et les droits sur le serveur de fichiers. Si le montage n’apparaît jamais, rien au-delà de ce point n’a été testé. Les deux cas se terminent par une boîte de dialogue similaire sur macOS, et c’est pourquoi les gens reconstruisent des profils VPN pour une panne que le VPN ne peut pas produire. Je commence par déterminer exactement où la connexion s’arrête, et seulement ensuite je teste l’écriture avec un fichier jetable plutôt qu’avec le document que je suis venu modifier.

Trois conditions décident où regarder

Il vous faut trois réponses avant de toucher à un réglage : le nom se résout-il en une adresse privée que le tunnel route, le service SMB accepte-t-il le compte précis que vous avez fourni, et ce compte détient-il des droits d’écriture sur exactement ce partage, ce dossier et cette opération. Chacune échoue à un endroit différent, et seule la première relève du responsable du VPN.

Le tableau mérite sa place parce qu’une session Mac, une session VPN et un compte SMB sont trois identités distinctes. Changer le mot de passe du VPN n’ouvre jamais un partage qui rejette l’utilisateur enregistré, et un client qui se dit connecté ne dit rien du serveur que vous visez.

Connectez-vous par adresse, pas en naviguant

Un partage distant peut être parfaitement joignable tout en restant invisible dans la liste Réseau du Finder. La découverte sur un LAN de bureau repose sur des noms de diffusion et de multicast, et la plupart des VPN ne transportent pas ce trafic dans le tunnel, donc une vue Réseau vide n’est pas la preuve d’un lien rompu.

1. Lancez le VPN prévu avec son client habituel et terminez son authentification.

2. Dans le Finder, choisissez Aller, puis Se connecter au serveur, ou appuyez sur Command-K.

3. Saisissez l’adresse fournie. Dans cet exemple, c’est smb://files.corp.example/team, un nom illustratif et non un service public. Si vous n’avez que le nom du serveur, connectez-vous-y et choisissez le partage autorisé dans la liste qu’il renvoie.

4. Choisissez Utilisateur enregistré et saisissez le compte du service de fichiers, pas votre compte Mac ni le compte VPN. Invité n’est correct que lorsque le propriétaire le dit.

5. Ouvrez le partage et faites l’unique tâche pour laquelle vous êtes venu. Un listage de dossier prouve le montage, rien de plus.

Le guide Apple de connexion au serveur documente ce flux du Finder et la connexion au service qui le sous-tend. Enregistrez l’adresse en favori pour que la prochaine connexion soit reproductible, et rappelez-vous que renommer l’entrée change l’étiquette, pas la cible.

Lisez l’étape où cela s’arrête

Avant de changer quoi que ce soit, notez quelle étape échoue, avec les mêmes noms que vous avez saisis dans le Finder. Commencez par la résolution : dscacheutil -q host -a name files.corp.example affiche l’adresse que macOS utilisera, et netstat -rn montre si cette adresse a une route via l’interface du tunnel ou via votre passerelle domestique.

Puis la joignabilité. nc -vz files.corp.example 445 indique si le port SMB répond du tout ; si la résolution fonctionne et que le 445 expire, vous êtes dans le domaine du routage, du pare-feu ou des adresses qui se chevauchent, et aucun changement de droits sur le partage n’aidera. Si le port répond, demandez au serveur ce qu’il offre à ce compte : smbutil view //[email protected] liste les partages, et smbutil statshares -a signale le dialecte négocié et l’état de signature de la session montée, ce qui vous dit si le montage que vous testez est bien celui que vous croyez.

L’identité mérite sa propre vérification, car c’est l’étape que les gens sautent. Un montage peut vivre en invité ou sous un ancien compte enregistré alors que vous supposez être l’utilisateur enregistré, et chaque test d’écriture mesure alors le mauvais compte.

L’accès en écriture a plus d’une porte

Deux couches peuvent dire non côté serveur, et les deux se ressemblent depuis le Mac. Un partage peut être exporté en lecture seule alors que le dossier en dessous est inscriptible, et un partage inscriptible ne peut pas contourner une ACL du système de fichiers qui refuse votre compte ; un sous-dossier peut aussi porter sa propre stratégie. Sur les serveurs Windows, le droit de partage et les droits NTFS sont distincts, et le droit effectif est le plus restrictif des deux.

Décidez donc de ce qui est réellement refusé : créer un fichier, modifier un fichier existant, créer un dossier, renommer ou supprimer. Ce n’est pas un seul droit, et un dossier où le listage fonctionne peut les refuser tous. Un montage qui fonctionne n’est pas une autorisation.

Si vous soupçonnez la mauvaise identité, éjectez le partage, supprimez l’entrée obsolète dans Trousseau d’accès et reconnectez-vous avec le compte enregistré. Le Finder réutilisera volontiers une session enregistrée et vous laissera mesurer les droits d’un utilisateur que le serveur ne considère pas comme vous.

Testez l’écriture sans toucher à de vrais documents

Avec l’accord du propriétaire, créez un petit fichier sous un nouveau nom dans le dossier qui échoue : touch /Volumes/team/qa-write-test.txt lorsque le partage y est monté, ou simplement Enregistrer sous avec un nouveau nom depuis l’application. N’écrasez jamais un document pour tester l’accès, et conservez le texte exact de l’erreur au lieu de le paraphraser, car le VPN ne le copiera pas.

Remettez ensuite au propriétaire l’opération que vous avez tentée plutôt qu’une plainte générale. Il peut vérifier la stratégie du partage, l’appartenance du compte aux groupes et les droits sur ce seul dossier, et vous dire quelle couche vous a refusé. Si le message mentionne la capacité, un fichier verrouillé ou un conflit de noms, c’est un autre problème qui mérite sa propre enquête.

Vérifiez la correction, puis éjectez dans l’ordre

Après que le propriétaire a changé quelque chose, répétez la même petite écriture et confirmez que le fichier est visible par le serveur puis supprimable. Une copie qui démarre puis se bloque est une question de débit, pas de droits ; un refus qui arrive instantanément est une question de droits.

Avant de couper le VPN, démontez le partage et fermez les documents ouverts. Éjecter après la disparition du tunnel laisse le Finder et vos applications attendre un chemin mort. Gardez SMB à l’intérieur du réseau privé, ne désactivez pas le pare-feu pour tester une théorie et n’ouvrez pas un dossier à tout le monde comme contournement. Pour le ticket, incluez l’adresse, le nom du compte, l’opération échouée, le message exact et l’heure, en laissant dehors les mots de passe et les fichiers de profil.

• L’adresse se résout en une adresse privée routée par le tunnel.
• Le port 445 répond et smbutil view liste le partage prévu pour le compte prévu.
• L’écriture dont vous aviez besoin se prouve avec un nouveau fichier, pas avec un document existant.