Corriger les erreurs d'authentification Azure File Storage — NetDrive

Un administrateur IT gère cinq partages Azure File Storage montés en lettres de lecteur sur un hôte Windows Server RDS — un par service, chacun repris d’un ancien serveur de fichiers sur site. Lundi matin, le partage Finance renvoie une erreur d’authentification dans NetDrive alors que les quatre autres se reconnectent normalement. Comme rien n’a changé dans la configuration de montage depuis vendredi, cela signifie généralement que les identifiants ou le partage lui-même ont bougé, pas NetDrive.

Montez Azure File Storage comme lettre de lecteur persistante

Avec NetDrive, Google Drive, OneDrive, S3, SFTP, WebDAV et plus apparaissent comme des lecteurs natifs sur Windows et macOS — sans synchronisation ni téléchargement complet.

• Connexion via une clé de compte ou un jeton SAS à portée limitée
• Le montage automatique au démarrage garde le partage prêt avant l'ouverture de session
• La licence équipe permet à un admin de déployer les identifiants sur chaque machine

WindowsmacOS

Télécharger NetDrive →

Essai gratuit. Licences à vie et abonnements disponibles.

Azure File Storage vs. Azure Blob — même erreur, cause différente

NetDrive traite Azure File Storage et Azure Blob Storage comme deux types de connexion distincts, et leurs échecs d’authentification viennent de sources légèrement différentes. Blob Storage pointe vers un conteneur ; File Storage pointe vers un partage de fichiers nommé de type SMB sous un compte de stockage. Un lecteur basé sur File Storage a besoin de trois valeurs pour se reconnecter correctement — le nom du compte de stockage, l’identifiant (clé de compte ou jeton SAS) et le nom exact du partage — il y a donc trois endroits où un échec du type « ça marchait la semaine dernière, plus aujourd’hui » peut trouver son origine.

Vérification 1 : jeton SAS expiré ou clé de compte régénérée

C’est la cause la plus fréquente et la plus rapide à écarter.

1. Dans le portail Azure, ouvrez le compte de stockage derrière le lecteur en échec et vérifiez avec quel type d’identifiant il est configuré.
2. Jeton SAS : allez dans Security + networking → Shared access signature et vérifiez que la Expiry date n’est pas dépassée. Un jeton généré à la configuration avec une expiration de 90 jours cesse silencieusement de fonctionner trois mois plus tard, sans aucun avertissement préalable.
3. Clé de compte : allez dans Security + networking → Access keys et vérifiez si key1 ou key2 a été régénérée récemment — souvent par un autre administrateur qui fait tourner les identifiants par hygiène de routine, sans se rendre compte que quatre autres services référencent encore l’ancienne valeur.
4. Générez un nouveau jeton SAS limité au service File (avec au minimum les droits Read, Write, List, Create, Delete), ou copiez la clé de compte actuelle.
5. Ouvrez NetDrive → cliquez sur l’icône d’engrenage du lecteur concerné dans Drive Manager pour ouvrir ses paramètres de connexion, collez le nouvel identifiant, puis cliquez sur Save.

Vérification 2 : règles de pare-feu du compte de stockage

Si l’identifiant est correct et que le lecteur ne s’authentifie toujours pas, l’étape suivante concerne les règles réseau du compte de stockage.

1. Dans le portail Azure, ouvrez Networking → Firewalls and virtual networks pour le compte de stockage.
2. S’il est réglé sur Enabled from selected virtual networks and IP addresses plutôt que sur All networks, Azure rejette la tentative de connexion avant même d’évaluer l’identifiant — ce qui, côté NetDrive, ressemble exactement à une mauvaise clé.
3. Vérifiez l’IP publique actuelle de la machine et ajoutez-la à la plage autorisée, ou assouplissez la règle si une restriction par IP n’est pas nécessaire pour ce partage.

Une machine sur une connexion résidentielle ou de succursale avec une IP dynamique est ici une récidiviste habituelle : la règle était correcte au moment de son ajout, et le fournisseur d’accès a depuis attribué une adresse différente.

Vérification 3 : le partage a été renommé ou supprimé

Contrairement à un conteneur Blob, un partage File Storage peut être renommé, supprimé et recréé sous le même compte de stockage sans que les identifiants du compte de stockage lui-même ne changent — ce qui veut dire que la clé de compte ou le jeton SAS continuent de s’authentifier correctement, mais que NetDrive ne trouve plus le partage vers lequel il pointait à l’origine. Dans le portail Azure, allez dans Data storage → File shares du compte de stockage et vérifiez que le nom du partage correspond exactement, casse comprise, à ce qui est saisi dans les paramètres de connexion de NetDrive. Si le partage a été recréé après suppression, mettez à jour le champ du nom de partage dans NetDrive même si tous les autres identifiants sont inchangés.

Confirmer la correction

Après avoir mis à jour l’identifiant, la règle de pare-feu ou le nom du partage, reconnectez le lecteur et vérifiez qu’il sert bien des fichiers plutôt que d’afficher simplement « Connected » dans la liste des lecteurs.

Ouvrez le lecteur dans l’explorateur et listez un dossier contenant des fichiers que vous reconnaissez. Si la liste se remplit et qu’un fichier s’ouvre sans erreur, l’identifiant, le chemin réseau et le nom du partage sont tous corrects.

Pour conclure

Les échecs d’authentification Azure File Storage dans NetDrive proviennent bien plus souvent d’un jeton SAS expiré, d’une clé de compte régénérée, d’une règle de pare-feu du compte de stockage ou d’un partage renommé que d’une faute de frappe dans la configuration initiale — vérifiez d’abord les identifiants, plus rapides à écarter, puis le réseau. Pour la procédure de connexion initiale, voir Monter Azure File Storage sur Windows avec NetDrive ; si le lecteur en question utilise en réalité des conteneurs Blob plutôt qu’un partage de fichiers, corriger les erreurs d’authentification Azure Blob traite ce cas équivalent.

— Casey, NetDrive