Résoudre les problèmes de connectivité et d’accès Azure Files (SMB)

Cet article répertorie les problèmes courants qui peuvent se produire lorsque vous essayez de vous connecter à des partages de fichiers Azure SMB (Server Message Block) et d’y accéder à partir de clients Windows ou Linux. Il fournit également les causes possibles et les solutions à ces problèmes.

Remarque

Cet article vous a-t-il été utile ? Votre avis est important à nos yeux. Utilisez le bouton Commentaires sur cette page pour nous faire savoir dans quelle mesure cet article vous a été utile ou comment nous pouvons l’améliorer.

Importante

Cet article s’applique uniquement aux partages SMB. Pour plus d’informations sur les partages de système de fichiers réseau (NFS), consultez Résoudre les problèmes liés aux partages de fichiers Azure NFS.

S’applique à

Type de partage de fichiers	SMB	NFS
Partages de fichiers standard (GPv2), LRS/ZRS
Partages de fichiers standard (GPv2), GRS/GZRS
Partages de fichiers Premium (FileStorage), LRS/ZRS

Impossible de se connecter ou de monter un partage de fichiers Azure

Sélectionnez l’onglet Windows ou Linux en fonction du système d’exploitation client que vous utilisez pour accéder aux partages de fichiers Azure.

Fenêtres

Lorsque vous essayez de vous connecter à un partage de fichiers Azure dans Windows, vous pouvez recevoir les messages d’erreur suivants.

Erreur 5 lors du montage d’un partage de fichiers Azure

• L’erreur système 5 s’est produite. L’accès est refusé.

Cause 1 : Canal de communication non chiffré

Pour des questions de sécurité, les connexions aux partages de fichiers Azure sont bloquées si le canal de communication n’est pas chiffré et que la tentative de connexion n’est pas effectuée à partir du même centre de données que celui où se trouvent les partages de fichiers Azure. Si le paramètre Transfert sécurisé requis est activé sur le compte de stockage, les connexions non chiffrées au sein du même centre de données sont également bloquées. Un canal de communication chiffré est fourni uniquement si le système d’exploitation client de l’utilisateur final prend en charge le chiffrement SMB.

Windows 8, Windows Server 2012 et versions ultérieures de chaque demande de négociation système incluant SMB 3.x, qui prend en charge le chiffrement.

Solution pour la cause 1

1. Connectez-vous à partir d’un client qui prend en charge le chiffrement SMB (Windows 8/Windows Server 2012 ou version ultérieure).
2. Connectez-vous à partir d’une machine virtuelle dans le même centre de données que le compte de stockage Azure utilisé pour le partage de fichiers Azure.
3. Vérifiez que le paramètre Transfert sécurisé requis est désactivé sur le compte de stockage si le client ne prend pas en charge le chiffrement SMB.

Cause 2 : Les règles de réseau virtuel ou de pare-feu sont activées sur le compte de stockage

Le trafic réseau est refusé si le réseau virtuel (VNET) et les règles de pare-feu sont configurées sur le compte de stockage, sauf si l’adresse IP du client ou le réseau virtuel est autorisé.

Solution pour la cause 2

Vérifiez que les règles de réseau virtuel et de pare-feu sont correctement configurées sur le compte de stockage. Pour tester si le réseau virtuel ou les règles de pare-feu sont à l’origine du problème, modifiez temporairement le paramètre sur le compte de stockage sur Autoriser l’accès à partir de tous les réseaux. Pour plus d’informations, consultez Configurer des pare-feu et des réseaux virtuels de Stockage Azure.

Cause 3 : Les autorisations au niveau du partage sont incorrectes lors de l’utilisation de l’authentification basée sur l’identité

Si les utilisateurs accèdent au partage de fichiers Azure à l’aide d’Active Directory (AD) ou d’une authentification Microsoft Entra Domain Services, l’accès au partage de fichiers échoue avec l’erreur « L’accès est refusé » si les autorisations au niveau du partage sont incorrectes.

Solution pour la cause 3

Vérifiez que les autorisations sont correctement configurées :

• services de domaine Active Directory (AD DS) consultez Attribuer des autorisations au niveau du partage.

  Les attributions d’autorisations au niveau du partage sont prises en charge pour les groupes et les utilisateurs qui ont été synchronisés à partir d’AD DS vers Microsoft Entra ID à l’aide de Microsoft Entra Connect Sync ou de la synchronisation cloud Microsoft Entra Connect. Vérifiez que les groupes et les utilisateurs auxquels des autorisations de niveau partage sont attribuées ne sont pas des groupes « cloud uniquement » non pris en charge.

• Microsoft Entra Domain Services consultez Attribuer des autorisations au niveau du partage.

Erreur 53, Erreur 67 ou Erreur 87 lorsque vous montez ou démontez un partage de fichiers Azure

Lorsque vous essayez de monter un partage de fichiers à partir d’un centre de données local ou d’un autre centre de données, vous pouvez recevoir les erreurs suivantes :

• L’erreur système 53 s’est produite. Le chemin réseau n’a pas été trouvé.
• L’erreur système 67 s’est produite. Le nom du réseau est introuvable.
• L’erreur système 87 s’est produite. Paramètre incorrect.

Cause 1 : Le port 445 est bloqué

L’erreur système 53 ou l’erreur système 67 peut se produire si la communication sortante du port 445 vers un centre de données Azure Files est bloquée. Pour afficher le résumé des fournisseurs de services Internet qui autorisent ou interdisent l’accès à partir du port 445, accédez à TechNet.

Pour case activée si votre pare-feu ou votre fournisseur de services Internet bloque le port 445, utilisez l’outil AzFileDiagnostics ou l’applet de Test-NetConnection commande .

Pour utiliser l’applet de Test-NetConnection commande, le module Azure PowerShell doit être installé. Pour plus d’informations, consultez Installer Azure PowerShell module. N’oubliez pas de remplacer <your-storage-account-name> et <your-resource-group-name> par les noms appropriés pour votre compte de stockage.

$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"

# This command requires you to be logged into your Azure account and set the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName

# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445

Si la connexion a réussi, vous devriez voir la sortie suivante :

ComputerName     : <your-storage-account-name>
RemoteAddress    : <storage-account-ip-address>
RemotePort       : 445
InterfaceAlias   : <your-network-interface>
SourceAddress    : <your-ip-address>
TcpTestSucceeded : True

Remarque

Cette commande retourne l’adresse IP actuelle du compte de stockage. Il n’est pas garanti que cette adresse IP reste la même et peut changer à tout moment. Ne codez pas en dur cette adresse IP dans des scripts ou dans une configuration de pare-feu.

Solutions pour la cause 1

Solution 1 : utiliser Azure File Sync comme point de terminaison QUIC Vous pouvez utiliser Azure File Sync comme solution de contournement pour accéder aux Azure Files à partir de clients dont le port 445 est bloqué. Bien que Azure Files ne prend pas directement en charge SMB sur QUIC, Windows Server 2022 Azure Edition prend en charge le protocole QUIC. Vous pouvez créer un cache léger de vos partages de fichiers Azure sur une machine virtuelle Windows Server 2022 Azure Edition à l’aide de Azure File Sync. Cette configuration utilise le port 443, qui est largement ouvert pour prendre en charge HTTPS, au lieu du port 445. Pour en savoir plus sur cette option, consultez SMB sur QUIC avec Azure File Sync.

Solution 2 : utiliser un VPN ou ExpressRoute En configurant un réseau privé virtuel (VPN) ou ExpressRoute à partir d’un emplacement local vers votre compte de stockage Azure, avec Azure Files exposées sur votre réseau interne à l’aide de points de terminaison privés, le trafic passe par un tunnel sécurisé plutôt que via Internet. Suivez les instructions pour configurer un VPN pour accéder à Azure Files à partir de Windows.

Solution 3 : débloquer le port 445 avec l’aide de votre fournisseur de services Internet/administrateur informatique Collaborez avec votre service informatique ou votre isp pour ouvrir le port 445 sortant vers des plages d’adresses IP Azure.

Solution 4 : utilisez des outils basés sur l’API REST comme Explorateur Stockage ou PowerShell Azure Files prend également en charge REST en plus de SMB. L’accès REST fonctionne sur le port 443 (tcp standard). Il existe différents outils écrits à l’aide de l’API REST qui permettent une expérience d’interface utilisateur enrichie. Explorateur Stockage est l’un d’entre eux. Téléchargez et installez Explorateur Stockage et connectez-vous à votre partage de fichiers avec Azure Files. Vous pouvez également utiliser PowerShell qui utilise également l’API REST.

Cause 2 : NTLMv1 est activé

L’erreur système 53 ou l’erreur système 87 peut se produire si la communication NTLMv1 est activée sur le client. Azure Files prend uniquement en charge l’authentification NTLMv2. L’activation de NTLMv1 crée un client moins sécurisé. Par conséquent, la communication est bloquée pour Azure Files.

Pour déterminer s’il s’agit de la cause de l’erreur, vérifiez que la sous-clé de Registre suivante n’est pas définie sur une valeur inférieure à 3 :

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

Pour plus d’informations, consultez la rubrique LmCompatibilityLevel sur TechNet.

Solution pour la cause 2

Rétablissez la LmCompatibilityLevel valeur par défaut de 3 dans la sous-clé de Registre suivante :

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Échec avec le code d’erreur 0x800704b3

Lorsque vous essayez de monter un partage de fichiers Azure, vous recevez l’erreur suivante :

Code d’erreur : 0x800704b3
Nom symbolique : ERROR_NO_NET_OR_BAD_PATH
Description de l’erreur : le chemin d’accès réseau a été tapé de manière incorrecte, n’existe pas ou le fournisseur réseau n’est pas disponible actuellement. Essayez de retaper le chemin d’accès ou contactez votre administrateur réseau.

Cause

Cette erreur peut se produire si les principaux services liés au réseau Windows sont désactivés, car tout service qui dépend explicitement de ces services réseau ne parvient pas à démarrer.

Solution

Vérifiez si l’un des services suivants est à l’état Arrêté sur la machine virtuelle Windows :

• Connexions réseau
• Service de liste réseau
• Reconnaissance de l’emplacement réseau
• Service d’interface de magasin réseau
• DHCP Client
• Assistance NETBIOS TCP/IP
• Station de travail

Si vous en trouvez, démarrez le ou les services et réessayez de monter le partage de fichiers Azure.

L’application ou le service ne peut pas accéder à un lecteur Azure Files monté

Cause

Les lecteurs sont montés par utilisateur. Si votre application ou service s’exécute sous un compte d’utilisateur différent de celui qui a monté le lecteur, l’application ne voit pas le lecteur.

Solution

Utilisez l’une des solutions suivantes :

• Montez le lecteur à partir du même compte d’utilisateur que celui qui contient l’application. Vous pouvez utiliser un outil tel que PsExec.

• Transmettez le nom et la clé du compte de stockage dans les paramètres de nom d’utilisateur et de mot de passe de la net use commande.

• Utilisez la cmdkey commande pour ajouter les informations d’identification dans le Gestionnaire d’informations d’identification. Effectuez cette action à partir d’une ligne de commande sous le contexte du compte de service, via une connexion interactive ou à l’aide runasde .

  cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>
  

• Mappez le partage directement sans utiliser de lettre de lecteur mappée. Certaines applications peuvent ne pas se reconnecter correctement à la lettre de lecteur. L’utilisation du chemin d’accès UNC complet peut donc être plus fiable :

  net use * \\storage-account-name.file.core.windows.net\share

Après avoir suivi ces instructions, vous pouvez recevoir le message d’erreur suivant lorsque vous exécutez net use pour le compte de service système/réseau : « L’erreur système 1312 s’est produite. Une session d’ouverture de session spécifiée n’existe pas. Il a peut-être déjà été arrêté. Si cette erreur s’affiche, assurez-vous que le nom d’utilisateur passé à net use inclut des informations de domaine (par exemple : [storage account name].file.core.windows.net).

Aucun dossier avec une lettre de lecteur dans « Poste de travail » ou « Ce PC »

Si vous mappez un partage de fichiers Azure en tant qu’administrateur à l’aide de la net use commande , le partage semble manquant.

Cause

Par défaut, Windows Explorateur de fichiers ne s’exécute pas en tant qu’administrateur. Si vous exécutez net use à partir d’une invite de commandes d’administration, vous mappez le lecteur réseau en tant qu’administrateur. Étant donné que les lecteurs mappés sont centrés sur l’utilisateur, le compte d’utilisateur connecté n’affiche pas les lecteurs s’ils sont montés sous un autre compte d’utilisateur.

Solution

Montez le partage à partir d’une ligne de commande non administrateur. Vous pouvez également suivre cette rubrique TechNet pour configurer la valeur de EnableLinkedConnections Registre.

La commande Net Use échoue si le compte de stockage contient une barre oblique

Cause

La net use commande interprète une barre oblique (/) comme une option de ligne de commande. Si le nom de votre compte d’utilisateur commence par une barre oblique, le mappage de lecteur échoue.

Solution

Vous pouvez utiliser l’une des étapes suivantes pour contourner le problème :

• Exécutez la commande PowerShell suivante:

  New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"
  

  À partir d’un fichier de commandes, vous pouvez exécuter la commande de cette façon :

  Echo new-smbMapping ... | powershell -command –

• Placez des guillemets doubles autour de la clé pour contourner ce problème, sauf si la barre oblique est le premier caractère. Si c’est le cas, utilisez le mode interactif et entrez votre mot de passe séparément ou régénérez vos clés pour obtenir une clé qui ne commence pas par une barre oblique.

New-PSDrive commande échoue avec l’erreur « le type de ressource réseau n’est pas correct »

Cause

Ce message d’erreur peut s’afficher si le partage de fichiers n’est pas accessible. Par exemple, le port 445 est bloqué ou il y a un problème de résolution DNS.

Solution

Assurez-vous que le port 445 est ouvert et case activée la résolution DNS et la connectivité à votre partage de fichiers.

Linux

Les causes courantes de ce problème sont les suivantes :

• Vous utilisez une distribution Linux avec un client SMB obsolète. Pour plus d’informations sur les distributions Linux courantes disponibles dans Azure qui ont des clients compatibles, consultez Utiliser Azure Files avec Linux.
• Les utilitaires SMB (cifs-utils) ne sont pas installés sur le client.
• La version minimale de SMB, 2.1, n’est pas disponible sur le client.
• Le chiffrement SMB 3.x n’est pas pris en charge sur le client. Le tableau précédent fournit une liste des distributions Linux qui prennent en charge le montage à partir d’un emplacement local et d’une région à l’aide du chiffrement. D’autres distributions nécessitent le noyau 4.11 et les versions ultérieures.
• Vous essayez de vous connecter à un partage de fichiers Azure à partir d’une machine virtuelle Azure, et la machine virtuelle ne se trouve pas dans la même région que le compte de stockage.
• Si le paramètre Transfert sécurisé requis est activé sur le compte de stockage, Azure Files autorise uniquement les connexions qui utilisent SMB 3.x avec chiffrement.

Solution

Pour résoudre le problème, utilisez l’outil de résolution des problèmes pour Azure Files les erreurs de montage sur Linux. Cet outil :

• Vous aide à valider l’environnement d’exécution du client.
• Détecte la configuration du client incompatible qui entraînerait un échec d’accès pour Azure Files.
• Fournit des conseils normatifs sur la correction automatique.
• Collecte les traces diagnostics.

« Erreur de montage(13) : Autorisation refusée » lorsque vous montez un partage de fichiers Azure

Cause 1 : Canal de communication non chiffré

Pour des raisons de sécurité, les connexions aux partages de fichiers Azure sont bloquées si le canal de communication n’est pas chiffré et que la tentative de connexion n’est pas effectuée à partir du même centre de données que celui où résident les partages de fichiers Azure. Les connexions non chiffrées au sein du même centre de données peuvent également être bloquées si le paramètre Transfert sécurisé requis est activé sur le compte de stockage. Un canal de communication chiffré est fourni uniquement si le système d’exploitation client de l’utilisateur prend en charge le chiffrement SMB.

Pour plus d’informations, consultez Prérequis pour le montage d’un partage de fichiers Azure avec Linux et le package cifs-utils.

Solution pour la cause 1

1. Connectez-vous à partir d’un client qui prend en charge le chiffrement SMB ou connectez-vous à partir d’une machine virtuelle dans le même centre de données que le compte de stockage Azure utilisé pour le partage de fichiers Azure.
2. Vérifiez que le paramètre Transfert sécurisé requis est désactivé sur le compte de stockage si le client ne prend pas en charge le chiffrement SMB.

Cause 2 : Les règles de réseau virtuel ou de pare-feu sont activées sur le compte de stockage

Si les règles de réseau virtuel (VNET) et de pare-feu sont configurées sur le compte de stockage, l’accès au trafic réseau est refusé, sauf si l’adresse IP du client ou le réseau virtuel est autorisé à y accéder.

Solution pour la cause 2

Vérifiez que les règles de réseau virtuel et de pare-feu sont correctement configurées sur le compte de stockage. Pour tester si des réseaux virtuels ou des règles de pare-feu sont à l’origine du problème, modifiez temporairement le paramètre sur le compte de stockage sur Autoriser l’accès à partir de tous les réseaux. Pour plus d’informations, consultez Configurer des pare-feu et des réseaux virtuels de Stockage Azure.

« Erreur de montage(115) : Opération en cours » lorsque vous montez Azure Files à l’aide de SMB 3.x

Cause

Certaines distributions Linux ne prennent pas encore en charge les fonctionnalités de chiffrement dans SMB 3.x. Les utilisateurs peuvent recevoir un message d’erreur « 115 » s’ils tentent de monter Azure Files à l’aide de SMB 3.x en raison d’une fonctionnalité manquante. SMB 3.x avec chiffrement complet est pris en charge uniquement sur la dernière version d’une distribution Linux.

Solution

La fonctionnalité de chiffrement de SMB 3.x pour Linux a été introduite dans le noyau 4.11. Cette fonctionnalité permet le montage d’un partage de fichiers Azure à partir d’un emplacement local ou d’une autre région Azure. Certaines distributions Linux peuvent avoir des modifications rétroportées du noyau 4.11 vers des versions plus anciennes du noyau Linux qu’elles gèrent. Pour déterminer si votre version de Linux prend en charge SMB 3.x avec chiffrement, consultez Utiliser Azure Files avec Linux.

Si votre client SMB Linux ne prend pas en charge le chiffrement, montez Azure Files à l’aide de SMB 2.1 à partir d’une machine virtuelle Linux qui se trouve dans le même centre de données Azure que le partage de fichiers. Vérifiez que le paramètre Transfert sécurisé requis est désactivé sur le compte de stockage.

« Erreur de montage(112) : l’hôte est arrêté » en raison d’un délai d’attente de reconnexion

Une erreur de montage « 112 » se produit sur le client Linux lorsque le client est inactif depuis longtemps. Après une durée d’inactivité prolongée, le client se déconnecte et la connexion expire.

Cause

La connexion peut être inactive pour les raisons suivantes :

• Échecs de communication réseau qui empêchent le rétablissement d’une connexion TCP au serveur lorsque l’option de montage « soft » par défaut est utilisée.
• Correctifs de reconnexion récents qui ne sont pas présents dans les noyaux plus anciens.

Solution

Ce problème de reconnexion dans le noyau Linux est maintenant résolu dans le cadre des modifications suivantes :

• Correction de la reconnexion pour ne pas différer la reconnexion de session smb3 longtemps après la reconnexion du socket
• Service d’écho d’appel immédiatement après la reconnexion du socket
• CIFS : Correction d’une éventuelle altération de la mémoire lors de la reconnexion
• CIFS : Correction d’un double verrouillage possible de mutex lors de la reconnexion (pour le noyau v4.9 et versions ultérieures)

Toutefois, ces modifications peuvent ne pas encore être transférées vers toutes les distributions Linux. Si vous utilisez une distribution Linux populaire, vous pouvez case activée Utiliser Azure Files avec Linux pour voir quelle version de votre distribution a les modifications nécessaires du noyau.

Solution de contournement

Vous pouvez contourner ce problème en spécifiant un montage dur. Un montage dur force le client à attendre qu’une connexion soit établie ou qu’elle soit explicitement interrompue. Vous pouvez l’utiliser pour éviter les erreurs dues à des délais d’attente réseau. Toutefois, cette solution de contournement peut entraîner des attentes indéfinies. Préparez-vous à arrêter les connexions si nécessaire.

Si vous ne pouvez pas effectuer la mise à niveau vers les dernières versions du noyau, vous pouvez contourner ce problème en conservant un fichier dans le partage de fichiers Azure dans lequel vous écrivez toutes les 30 secondes ou moins. Il doit s’agir d’une opération d’écriture, telle que la réécriture de la date de création ou de modification sur le fichier. Sinon, vous risquez d’obtenir des résultats mis en cache et votre opération risque de ne pas déclencher la reconnexion.

Impossible d’accéder, de modifier ou de supprimer un partage de fichiers Azure (ou un partage instantané)

Erreur « Le nom d’utilisateur ou le mot de passe est incorrect » après un basculement initié par le client

Dans un scénario de basculement initié par le client avec des comptes de stockage géoredondants, les descripteurs de fichiers et les baux ne sont pas conservés lors du basculement. Les clients doivent démonter et remonter les partages de fichiers.

Erreur « Aucun accès » lorsque vous essayez d’accéder ou de supprimer un partage de fichiers Azure

Lorsque vous essayez d’accéder à un partage de fichiers Azure ou de le supprimer à l’aide de la Portail Azure, vous pouvez recevoir l’erreur suivante :

Aucun accès Code d’erreur : 403

Cause 1 : Les règles de réseau virtuel ou de pare-feu sont activées sur le compte de stockage

Solution pour la cause 1

Vérifiez que les règles de réseau virtuel et de pare-feu sont correctement configurées sur le compte de stockage. Pour tester si les règles de réseau virtuel ou de pare-feu sont à l’origine du problème, modifiez temporairement le paramètre sur le compte de stockage sur Autoriser l’accès à partir de tous les réseaux. Pour plus d’informations, consultez Configurer des pare-feu et des réseaux virtuels de Stockage Azure.

Cause 2 : Votre compte d’utilisateur n’a pas accès au compte de stockage

Solution pour la cause 2

Accédez au compte de stockage dans lequel se trouve le partage de fichiers Azure, sélectionnez Contrôle d’accès (IAM) et vérifiez que votre compte d’utilisateur a accès au compte de stockage. Pour plus d’informations, consultez Comment sécuriser votre compte de stockage avec le contrôle d’accès en fonction du rôle Azure (Azure RBAC).

Verrous et baux de fichiers

Si vous ne pouvez pas modifier ou supprimer un partage de fichiers Ou instantané Azure, cela peut être dû à des verrous ou des baux de fichiers. Azure Files offre deux façons d’empêcher la modification ou la suppression accidentelle des partages de fichiers et des instantanés de partage Azure :

• Verrous de ressources de compte de stockage : toutes les ressources Azure, y compris le compte de stockage, prennent en charge les verrous de ressources. Les verrous peuvent être placés sur le compte de stockage par un administrateur ou par des services tels que Sauvegarde Azure. Il existe deux variantes de verrous de ressources : la modification, qui empêche toutes les modifications apportées au compte de stockage et à ses ressources, et la suppression, qui empêche uniquement les suppressions du compte de stockage et de ses ressources. Lors de la modification ou de la suppression de partages via le Microsoft.Storage fournisseur de ressources, des verrous de ressources sont appliqués sur les partages de fichiers Azure et les instantanés de partage. La plupart des opérations du portail, Azure PowerShell applets de commande pour Azure Files avec Rm dans le nom (par exemple, Get-AzRmStorageShare) et les commandes Azure CLI dans le share-rm groupe de commandes (par exemple, az storage share-rm list) utilisent le fournisseur de Microsoft.Storage ressources. Certains outils et utilitaires tels que les Explorateur Stockage, les Azure Files les applets de commande de gestion PowerShell héritées sans Rm dans le nom (par exemple, Get-AzStorageShare) et les commandes CLI héritées Azure Files sous le share groupe de commandes (par exemple, az storage share list) utilisent des API héritées dans l’API FileREST qui contournent le Microsoft.Storage fournisseur de ressources et les verrous de ressources. Pour plus d’informations sur les API de gestion héritées exposées dans l’API FileREST, consultez plan de contrôle dans Azure Files.

• Partage/partage instantané baux : les baux de partage sont une sorte de verrou propriétaire pour les partages de fichiers Azure et les instantanés de partage de fichiers. Les baux peuvent être placés sur des partages de fichiers Azure individuels ou des instantanés de partage de fichiers par les administrateurs en appelant l’API via un script ou par des services à valeur ajoutée tels que Sauvegarde Azure. Lorsqu’un bail est placé sur un partage de fichiers Ou un partage de fichiers Azure instantané, la modification ou la suppression du partage de fichiers/partage instantané peut être effectuée avec l’ID de bail. Les administrateurs peuvent également libérer le bail avant les opérations de modification, ce qui nécessite l’ID de bail, ou rompre le bail, ce qui n’a pas besoin de l’ID de bail. Pour plus d’informations sur les baux de partage, consultez Bail Share.

Étant donné que les verrous et les baux de ressources peuvent interférer avec les opérations d’administrateur prévues sur votre compte de stockage/partages de fichiers Azure, vous souhaiterez peut-être supprimer tous les verrous/baux de ressources qui ont été placés sur vos ressources manuellement ou automatiquement par des services à valeur ajoutée tels que Sauvegarde Azure. Le script suivant supprime tous les verrous et baux de ressources. N’oubliez pas de remplacer <resource-group> et <storage-account> par les valeurs appropriées pour votre environnement.

Avant d’exécuter le script suivant, vous devez installer la dernière version du module Azure Storage PowerShell.

Importante

Les services à valeur ajoutée qui prennent des verrous de ressources et partagent/partagent des baux instantané sur vos ressources Azure Files peuvent régulièrement réappliquer des verrous et des baux. La modification ou la suppression de ressources verrouillées par des services à valeur ajoutée peut avoir un impact sur le fonctionnement régulier de ces services, comme la suppression des instantanés de partage gérés par Sauvegarde Azure.

# Parameters for storage account resource
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName

# Remove resource locks
Get-AzResourceLock `
        -ResourceType "Microsoft.Storage/storageAccounts" `
        -ResourceGroupName $storageAccount.ResourceGroupName `
        -ResourceName $storageAccount.StorageAccountName | `
    Remove-AzResourceLock -Force | `
    Out-Null

# Remove share and share snapshot leases
Get-AzStorageShare -Context $storageAccount.Context | `
    Where-Object { $_.Name -eq $fileShareName } | `
    ForEach-Object {
        try {
            $leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($_.ShareClient)
            $leaseClient.Break() | Out-Null
        } catch { }
    }

Impossible de modifier, déplacer/renommer ou supprimer un fichier ou un répertoire

Sélectionnez l’onglet Windows ou Linux en fonction du système d’exploitation client que vous utilisez pour accéder aux partages de fichiers Azure.

Fenêtres

Dans Windows, vous pouvez voir les erreurs suivantes.

Descripteurs ou baux de fichiers orphelins

L’un des principaux objectifs d’un partage de fichiers est que plusieurs utilisateurs et applications peuvent interagir simultanément avec des fichiers et des répertoires dans le partage. Pour faciliter cette interaction, les partages de fichiers offrent plusieurs façons de communiquer l’accès aux fichiers et répertoires.

Lorsque vous ouvrez un fichier à partir d’un partage de fichiers Azure monté sur SMB, votre application/système d’exploitation demande un handle de fichier, qui est une référence au fichier. Entre autres choses, votre application spécifie un mode de partage de fichiers lorsqu’elle demande un handle de fichier, qui spécifie le niveau d’exclusivité de votre accès au fichier appliqué par Azure Files :

• None: vous disposez d’un accès exclusif.
• Read: d’autres utilisateurs peuvent lire le fichier pendant que vous l’avez ouvert.
• Write: d’autres peuvent écrire dans le fichier tant que vous l’avez ouvert.
• ReadWrite: combinaison des modes de Read partage et .Write
• Delete: d’autres peuvent supprimer le fichier tant que vous l’avez ouvert.

Bien qu’en tant que protocole sans état, le protocole FileREST n’a pas de concept de descripteurs de fichiers, il fournit un mécanisme similaire pour servir de médiation de l’accès aux fichiers et dossiers que votre script, application ou service peut utiliser : baux de fichiers. Lorsqu’un fichier est loué, il est traité comme équivalent à un descripteur de fichier avec un mode de partage de fichiers de None.

Bien que les descripteurs de fichiers et les baux servent un objectif important, il arrive que les descripteurs de fichiers et les baux soient orphelins. Lorsque cela se produit, cela peut entraîner des problèmes lors de la modification ou de la suppression de fichiers. Vous pouvez voir des messages d’erreur tels que :

• Le processus ne peut pas accéder au fichier, car il est utilisé par un autre processus.
• Impossible d’effectuer l’action, car le fichier est ouvert dans un autre programme.
• Le document est verrouillé pour modification par un autre utilisateur.
• La ressource spécifiée est marquée pour suppression par un client SMB.

La résolution de ce problème dépend de la cause ou non d’un descripteur de fichier ou d’un bail orphelin.

Remarque

Les baux REST sont utilisés par les applications pour empêcher la suppression ou la modification des fichiers. Avant de rompre les baux, vous devez identifier l’application qui les acquiert. Sinon, vous risquez d’interrompre le comportement de l’application.

Cause 1

Un descripteur de fichier empêche la modification ou la suppression d’un fichier/répertoire. Vous pouvez utiliser l’applet de commande PowerShell Get-AzStorageFileHandle pour afficher les descripteurs ouverts.

Si tous les clients SMB ont fermé leurs descripteurs ouverts sur un fichier/répertoire et que le problème continue de se produire, vous pouvez forcer la fermeture d’un descripteur de fichier.

Solution 1

Pour forcer la fermeture d’un descripteur de fichier, utilisez l’applet de commande PowerShell Close-AzStorageFileHandle .

Remarque

Les Get-AzStorageFileHandle applets de commande et Close-AzStorageFileHandle sont incluses dans le module Az PowerShell version 2.4 ou ultérieure. Pour installer le dernier module Az PowerShell, consultez Installer le module Azure PowerShell.

Cause 2

Un bail de fichier empêche la modification ou la suppression d’un fichier. Vous pouvez case activée si un fichier a un bail de fichier avec les commandes PowerShell suivantes. Remplacez <resource-group>, <storage-account>, <file-share>et <path-to-file> par les valeurs appropriées pour votre environnement.

# Set variables 
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
$fileShareName = "<file-share>"
$fileForLease = "<path-to-file>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
        -ResourceGroupName $resourceGroupName `
        -Name $storageAccountName

# Get reference to file
$file = Get-AzStorageFile `
        -Context $storageAccount.Context `
        -ShareName $fileShareName `
        -Path $fileForLease

$fileClient = $file.ShareFileClient

# Check if the file has a file lease
$fileClient.GetProperties().Value

Si un fichier a un bail, l’objet retourné doit contenir les propriétés suivantes :

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Solution 2

Pour supprimer un bail d’un fichier, vous pouvez libérer le bail ou l’annuler. Pour libérer le bail, vous avez besoin du LeaseId du bail, que vous définissez lorsque vous créez le bail. Vous n’avez pas besoin du LeaseId pour rompre le bail.

L’exemple suivant montre comment rompre le bail du fichier indiqué dans la cause 2 (cet exemple continue avec les variables PowerShell de la cause 2) :

$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClient)
$leaseClient.Break() | Out-Null

Linux

Dans Linux, vous pouvez rencontrer les problèmes suivants.

Descripteurs ouverts sur des fichiers ou des répertoires

Cause

Ce problème se produit généralement si le fichier ou le répertoire a un descripteur ouvert.

Solution

Si les clients SMB ont fermé tous les handles ouverts et que le problème continue de se produire, procédez comme suit :

• Utilisez l’applet de commande PowerShell Get-AzStorageFileHandle pour afficher les descripteurs ouverts.

• Utilisez l’applet de commande PowerShell Close-AzStorageFileHandle pour fermer les descripteurs ouverts.

Remarque

Les Get-AzStorageFileHandle applets de commande et Close-AzStorageFileHandle sont incluses dans le module Az PowerShell version 2.4 ou ultérieure. Pour installer le dernier module Az PowerShell, consultez Installer le module Azure PowerShell.

Impossible de monter un partage de fichiers Azure instantané sur Linux

« Erreur de montage(22) : argument non valide » lors de la tentative de montage d’un partage de fichiers Azure instantané sur Linux

Cause

Si l’option snapshot de la mount commande n’est pas passée dans un format reconnu, la mount commande peut échouer avec cette erreur. Pour le confirmer, case activée messages du journal du noyau (dmesg) et dmesg affiche une entrée de journal telle que cifs: Bad value for 'snapshot'.

Solution

Assurez-vous que vous transmettez l’option snapshot pour la mount commande dans le format correct. Reportez-vous à la page manuelle mount.cifs (par exemple man mount.cifs). Une erreur courante consiste à passer l’horodatage GMT dans un format incorrect, par exemple en utilisant des traits d’union ou des points-virgules à la place de points. Pour plus d’informations, consultez Monter un partage de fichiers instantané.

« Jeton de instantané incorrect » lors de la tentative de montage d’un partage de fichiers Azure instantané sur Linux

Cause

Si l’option instantané mount est passée à partir @GMTde , mais que le format est toujours incorrect (par exemple, en utilisant des traits d’union et des points au lieu de points), la mount commande peut échouer avec cette erreur.

Solution

Assurez-vous que vous transmettez l’horodatage GMT au format correct, qui est @GMT-year.month.day-hour.minutes.seconds. Pour plus d’informations, consultez Monter un partage de fichiers instantané.

« Erreur de montage(2) : aucun fichier ou répertoire de ce type » lors de la tentative de montage d’un partage de fichiers Azure instantané

Cause

Si le instantané que vous essayez de monter n’existe pas, la mount commande peut échouer avec cette erreur. Pour le confirmer, case activée messages de journal du noyau (dmesg) et dmesg affichent une entrée de journal telle que :

[Mon Dec 12 10:34:09 2022] CIFS: Attempting to mount \\snapshottestlinux.file.core.windows.net\snapshot-test-share1
[Mon Dec 12 10:34:09 2022] CIFS: VFS: cifs_mount failed w/return code = -2

Solution

Vérifiez que le instantané que vous essayez de monter existe. Pour plus d’informations sur la façon de répertorier les instantanés disponibles pour un partage de fichiers Azure donné, consultez Monter un partage de fichiers instantané.

Quota de disque ou erreurs réseau dues à un trop grand nombre de handles ouverts

Sélectionnez l’onglet Windows ou Linux en fonction du système d’exploitation client que vous utilisez pour accéder aux partages de fichiers Azure.

Fenêtres

Erreur 1816 - Quota insuffisant disponible pour traiter cette commande

Cause

L’erreur 1816 se produit lorsque vous atteignez la limite supérieure de handles ouverts simultanés autorisés pour un fichier ou un répertoire sur le partage de fichiers Azure. Pour plus d’informations, consultez Azure Files cibles de mise à l’échelle.

Solution

Réduisez le nombre de handles ouverts simultanés en fermant certains handles, puis réessayez. Pour plus d’informations, consultez Stockage Microsoft Azure liste de contrôle des performances et de la scalabilité.

Pour afficher les descripteurs ouverts pour un partage de fichiers, un répertoire ou un fichier, utilisez l’applet de commande PowerShell Get-AzStorageFileHandle .

Pour fermer les descripteurs ouverts d’un partage de fichiers, d’un répertoire ou d’un fichier, utilisez l’applet de commande PowerShell Close-AzStorageFileHandle .

Remarque

Les Get-AzStorageFileHandle applets de commande et Close-AzStorageFileHandle sont incluses dans le module Az PowerShell version 2.4 ou ultérieure. Pour installer le dernier module Az PowerShell, consultez Installer le module Azure PowerShell.

ERROR_UNEXP_NET_ERR (59) lors de l’exécution d’opérations sur un handle

Cause

Si vous mettez en cache/conservez un grand nombre de handles ouverts pendant une longue période, vous pouvez voir cette défaillance côté serveur pour des raisons de limitation. Lorsqu’un grand nombre de handles sont mis en cache par le client, la plupart de ces handles peuvent passer en même temps à une phase de reconnexion, créant une file d’attente sur le serveur qui doit être limitée. La logique de nouvelle tentative et la limitation sur le back-end pour la reconnexion prennent plus de temps que le délai d’expiration du client. Cette situation se manifeste par le fait qu’un client ne peut pas utiliser de handle existant pour une opération, toutes les opérations échouent avec ERROR_UNEXP_NET_ERR (59).

Il existe également des cas de périphérie dans lesquels le handle client est déconnecté du serveur (par exemple, une panne réseau de plusieurs minutes) qui peuvent provoquer cette erreur.

Solution

Ne gardez pas un grand nombre de handles mis en cache. Fermez les handles, puis réessayez. Utilisez Get-AzStorageFileHandle et Close-AzStorageFileHandle les applets de commande PowerShell pour afficher/fermer les descripteurs ouverts.

Si vous utilisez des partages de fichiers Azure pour stocker des conteneurs de profils ou des images de disque pour un déploiement de bureau virtuel à grande échelle ou d’autres charges de travail qui ouvrent des handles sur des fichiers, des répertoires et/ou le répertoire racine, vous pouvez atteindre les limites de mise à l’échelle supérieure pour les handles ouverts simultanés. Dans ce cas, utilisez un partage de fichiers Azure supplémentaire et distribuez les conteneurs ou les images entre les partages.

Linux

« [autorisation refusée] Quota de disque dépassé » lorsque vous essayez d’ouvrir un fichier

Dans Linux, vous pouvez recevoir un message d’erreur semblable à ce qui suit :

<filename> [autorisation refusée] Quota de disque dépassé

Cause

Vous avez atteint la limite supérieure des descripteurs ouverts simultanés autorisés pour un fichier ou un répertoire.

Azure Files prend en charge 10 000 handles ouverts sur le répertoire racine et 2 000 handles ouverts par fichier et répertoire au sein du partage.

Solution

Réduisez le nombre de handles ouverts simultanés en fermant certains handles, puis recommencez l’opération.

Pour afficher les descripteurs ouverts pour un partage de fichiers, un répertoire ou un fichier, utilisez l’applet de commande PowerShell Get-AzStorageFileHandle .

Pour fermer les descripteurs ouverts d’un partage de fichiers, d’un répertoire ou d’un fichier, utilisez l’applet de commande PowerShell Close-AzStorageFileHandle .

Remarque

Les Get-AzStorageFileHandle applets de commande et Close-AzStorageFileHandle sont incluses dans le module Az PowerShell version 2.4 ou ultérieure. Pour installer le dernier module Az PowerShell, consultez Installer le module Azure PowerShell.

Erreur « Vous copiez un fichier vers une destination qui ne prend pas en charge le chiffrement »

Lorsqu’un fichier est copié sur le réseau, le fichier est déchiffré sur l’ordinateur source, transmis en texte clair et rechiffré à la destination. Toutefois, vous pouvez voir l’erreur suivante lorsque vous essayez de copier un fichier chiffré : « Vous copiez le fichier vers une destination qui ne prend pas en charge le chiffrement ».

Cause

Ce problème peut se produire si vous utilisez le système de fichiers EFS (Encrypting File System). Les fichiers chiffrés par BitLocker peuvent être copiés dans Azure Files. Toutefois, Azure Files ne prend pas en charge NTFS EFS.

Solution de contournement

Pour copier un fichier sur le réseau, vous devez d’abord le déchiffrer. Appliquez l’une des méthodes suivantes :

• Utilisez la commande copy /d . Il permet d’enregistrer les fichiers chiffrés en tant que fichiers déchiffrés à la destination.
• Définissez la clé de Registre suivante :
  • Chemin = HKLM\Software\Policies\Microsoft\Windows\System
  • Type de valeur = DWORD
  • Name = CopyFileAllowDecryptedRemoteDestination
  • Valeur = 1

N’oubliez pas que la définition de la clé de Registre affecte toutes les opérations de copie effectuées sur les partages réseau.

Erreur ConditionHeadersNotSupported à partir d’une application web à l’aide de Azure Files à partir du navigateur

L’erreur ConditionHeadersNotSupported se produit lors de l’accès au contenu hébergé dans Azure Files via une application qui utilise des en-têtes conditionnels, comme un navigateur web, l’accès échoue. L’erreur indique que les en-têtes de condition ne sont pas pris en charge.

Cause

Les en-têtes conditionnels ne sont pas encore pris en charge. Les applications qui les implémentent devront demander le fichier complet chaque fois que le fichier est accessible.

Solution de contournement

Lorsqu’un nouveau fichier est chargé, la propriété CacheControl par défaut est sans cache. Pour forcer l’application à demander le fichier à chaque fois, la propriété CacheControl du fichier doit être mise à jour de no-cache à no-cache, no-store, must-revalidate. Pour ce faire, vous pouvez utiliser Explorateur Stockage Azure.

Voir aussi

• Résoudre les problèmes Azure Files
• Résoudre les problèmes de performances Azure Files
• Résoudre les problèmes d’authentification et d’autorisation Azure Files (SMB)
• Résoudre les problèmes Azure Files SMB généraux sur Linux
• Résoudre les problèmes Azure Files NFS généraux sur Linux
• Résoudre les problèmes de Azure File Sync

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.