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

Lorsque vous essayez de vous connecter à un partage de fichiers Azure sur Windows, vous pourriez recevoir les messages d’erreurs suivants.

Error 5 quand vous montez un partage de fichiers Azure

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

Cause 1 : Canal de communication non chiffré

Par sécurité, les connexions aux partages de fichiers Azure sont bloquées si le canal de communication n’est pas chiffré et si la tentative de connexion n’est pas effectuée depuis le centre de données sur lequel résident les partages de fichiers Azure. Les connexions non chiffrées dans le 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 uniquement fourni 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 système négocient les demandes qui incluent SMB 3.x, qui prend en charge le chiffrement.

Solution pour la cause 1

1. Connectez-vous depuis un client qui prend en charge le chiffrement SMB (Windows 8/Windows Server 2012 ou version ultérieure).
2. Connectez-vous depuis une machine virtuelle située 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é obligatoire est désactivé sur le compte de stockage si le client ne prend pas en charge le chiffrement SMB.

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

Si les règles de pare-feu et de réseau virtuel sont configurées sur le compte de stockage, le trafic réseau n’a pas d’accès, sauf si l’adresse IP du client ou le réseau virtuel figure dans la liste d’autorisation.

Solution pour la cause 2

Vérifiez que les règles de pare-feu et de réseau virtuel sont configurées correctement sur le compte de stockage. Pour vérifier si les règles de pare-feu ou de réseau virtuel sont à l’origine du problème, définissez temporairement le paramètre du compte de stockage sur Autoriser l’accès à partir de tous les réseaux. Pour plus d’informations, consultez Configurer les pare-feu et les réseaux virtuels dans le 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 en utilisant l’authentification Active Directory (AD) ou 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 configurées correctement :

• Active Directory Domain Services (AD DS), voir Assigner 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 entre AD DS et Microsoft Entra ID à l’aide de Microsoft Entra Connect Sync ou microsoft Entra Connect Cloud Sync. Vérifiez que les groupes et les utilisateurs auxquels les autorisations au niveau du partage sont attribuées ne sont pas des groupes « cloud uniquement » non pris en charge.

• Microsoft Entra Domain Services, veuillez consulter la section Attribuer des autorisations au niveau du partage.

Les messages « Erreur 53 », « Erreur 67 » ou « Erreur 87 » s’affichent 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 :

• Erreur système 53. Le chemin d’accès réseau est introuvable.
• Erreur système 67. Le nom du réseau est introuvable.
• Erreur système 87. Le paramètre est incorrect.

Cause 1 : Le port 445 est bloqué

Une erreur système 53 ou 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écapitulatif des FAI qui autorisent ou interdisent l’accès depuis le port 445, consultez TechNet.

Pour vérifier si votre pare-feu ou votre ISP bloque le port 445, utilisez l'outil AzFileDiagnostics ou la cmdlet Test-NetConnection.

Pour utiliser la cmdlet Test-NetConnection, vous devez avoir installé le module Azure PowerShell. Consultez Installer le module Azure PowerShell pour plus d’informations. N’oubliez pas de remplacer <your-storage-account-name> et <your-resource-group-name> avec les noms appropriés de 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 devez 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

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 qu’Azure Files ne prenne 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 d’Azure File Sync. Cette configuration utilise le port 443, qui est largement ouvert en mode sortant 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 : utilisez VPN ou ExpressRoute en configurant un réseau privé virtuel (VPN) ou ExpressRoute local vers votre compte de stockage Azure, avec Azure Files exposé sur votre réseau interne à l’aide de points de terminaison privés, le trafic transite par un tunnel sécurisé par opposition à 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 fai pour ouvrir le port 445 sortant vers les plages d’adresses IP Azure.

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

Cause 2 : NTLMv1 est activé

Les messages Erreur système 53 ou Erreur système 87 peuvent également s’afficher si la communication NTLMv1 est activée sur le client. Azure Files prend uniquement en charge l’authentification NTLMv2. Le fait d’activer NTLMv1 crée un client moins sécurisé. Par conséquent, les communications sont bloquées 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

Restaurez la valeur LmCompatibilityLevel à la 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 taper à nouveau le chemin d’accès ou contactez votre administrateur réseau.

Cause

Cette erreur peut se produire si les services liés au réseau Windows de base sont désactivés en tant que service qui dépend explicitement de ces services réseau ne parviennent pas à démarrer.

Solution

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

• Connexions réseau
• Service Liste des réseaux
• Connaissance des emplacements réseau
• Service Interface du magasin réseau
• Client DHCP
• Assistance NetBIOS sur TCP/IP
• Station de travail

Si vous le 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 l’utilisateur. Si vous n’exécutez pas l’application ou service depuis le compte utilisateur ayant monté le lecteur, l’application ou service ne verra pas le lecteur.

Solution

Utilisez l’une des solutions suivantes :

• Montez le lecteur depuis le compte utilisateur qui dispose de 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 commande net use.

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

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

• Mappez le partage directement sans l’aide d’une lettre de lecteur mappée. Certaines applications peuvent ne pas se reconnecter correctement à la lettre de lecteur, de sorte que l’utilisation du chemin UNC complet peut ê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 en exécutant net use pour le compte de service réseau ou système : « Erreur système 1312. Une session ouverte spécifiée n’existe pas. Elle a peut-être déjà été arrêtée. Si cette erreur s’affiche, vérifiez que le nom d’utilisateur passé à net use inclure 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 commande net use, le partage n’apparaît pas.

Cause

Par défaut, l’Explorateur de fichiers Windows ne s’exécute pas en tant qu’administrateur. Si vous exécutez net use depuis une invite de commandes administrateur, vous mappez le lecteur réseau en tant qu’administrateur. Du fait que les lecteurs mappés sont orientés utilisateur, le compte d’utilisateur qui est connecté n’affiche pas les lecteurs qui sont montés sur un compte d’utilisateur différent.

Solution

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

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

Cause

La commande net use interprète une barre oblique (/) comme une option de ligne de commande. Si le nom de votre compte utilisateur commence par une barre oblique, le mappage du 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"
  

  Depuis 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 résoudre 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.

La commande New-PSDrive é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 existe un problème de résolution DNS.

Solution

Vérifiez que le port 445 est ouvert et vérifiez la résolution DNS et la connectivité à votre partage de fichiers.

Causes courantes de ce problème :

• Vous utilisez une distribution Linux avec un client SMB obsolète. Consultez Utiliser Azure Files avec Linux pour plus d’informations sur les distributions Linux courantes disponibles dans Azure et dont les clients sont compatibles.
• Les utilitaires SMB (cifs-utils) ne sont pas installés sur le client.
• La version de SMB minimale, à savoir 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 de Linux qui prennent en charge le montage à partir d’emplacements locaux et entre les régions grâce au chiffrement. Les autres distributions requièrent un noyau 4.11 et versions ultérieures.
• Vous tentez de vous connecter à un partage de fichiers Azure à partir d’une machine virtuelle Azure qui 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 utilisant SMB 3.x avec chiffrement.

Solution

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

• Il vous permet de valider l’environnement d’exécution du client.
• Il détecte la configuration client incompatible qui provoquerait l’échec de l’accès d’Azure Files.
• Il fournit des instructions pour la résolution automatique.
• Il collecte les suivis des diagnostics.

« Erreur de montage (13) : Autorisation refusée » quand 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 où résident les partages de fichiers Azure. Les connexions non chiffrées dans le 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 en savoir plus, 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 prenant 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é obligatoire est désactivé sur le compte de stockage si le client ne prend pas en charge le chiffrement SMB.

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

Si des règles de pare-feu et de réseau virtuel sont configurées sur le compte de stockage, le trafic réseau n’a pas d’accès, sauf si l’adresse IP du client ou un réseau virtuel est autorisé à accéder.

Solution pour la cause 2

Vérifiez que les règles de réseau virtuel et de pare-feu sont configurées correctement sur le compte de stockage et que le port 445 est autorisé. Pour tester si des réseaux virtuels ou des règles de pare-feu provoquent le problème, vous pouvez modifier temporairement le paramètre sur le compte de stockage pour autoriser l’accès à partir de tous les réseaux. Pour plus d’informations, consultez Configurer les pare-feu et les réseaux virtuels dans le Stockage Azure.

Cause 3 : le client SMB est configuré pour utiliser NTLMv1

Azure Files prend uniquement en charge NTLMv2 et Kerberos pour les partages de fichiers SMB. Les versions 4.4 et ultérieures du noyau activent NTLMv2 par défaut et désactivent LANMAN. Sous les configurations par défaut, NTLMv1 est conservé en tant qu’option de négociation uniquement. Pour plus d’informations, consultez la documentation de votre système d’exploitation.

Solution pour la cause 3

Vérifiez que les commandes de montage SMB ne remplacent pas l’authentification NTLMv2 par défaut via l’option sec . L’option sec ne doit jamais utiliser ntlm ou ntlmi lors de la connexion à des partages de fichiers Azure SMB. Si vous définissez des options globales dans /etc/samba/smb.conf, veillez à ne pas désactiver NTLMv2.

Cause 4 : L’accès à la clé du compte de stockage est désactivé ou interdit par le biais d’une stratégie

Lorsque l’accès à la clé du compte de stockage est désactivé ou interdit pour un compte de stockage, les jetons SAP et les clés d’accès ne fonctionnent pas.

Solution pour la cause 4

Utilisez l’authentification basée sur l’identité. Le partage de fichiers doit être joint à un domaine Active Directory local Domain Servies (AD DS) ou Microsoft Entra Domain Services, et le client Linux doit être configuré pour utiliser l’authentification Kerberos.

« Erreur de montage (115) : L’opération est en cours » quand 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. Il est possible que les utilisateurs reçoivent un message d’erreur « 115 » s’ils essaient de monter Azure Files en utilisant 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 pour 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 antérieures du noyau Linux qu’elles maintiennent. Pour aider à 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 se trouvant 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 hors service » en raison de l’expiration du délai de reconnexion

L’erreur de montage 112 se produit sur le client Linux s’il est resté inactif pendant une période prolongée. 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 la nouvelle établissement d’une connexion TCP au serveur lorsque l’option de montage « réversible » 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 :

• Résoudre le problème de reconnexion pour ne pas différer la reconnexion de la session SMB3 longtemps après la reconnexion du socket
• Appeler le service d’écho immédiatement après la reconnexion du socket
• CIFS : Corriger une éventuelle corruption de la mémoire pendant la reconnexion
• CIFS : Corriger un éventuel double verrouillage du mutex pendant la reconnexion (pour les noyaux v4.9 et ultérieurs)

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 vérifier 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 inconditionnel. Un montage inconditionnel force le client à attendre jusqu'à ce qu’une connexion soit établie ou jusqu'à ce qu’elle soit explicitement interrompue. Vous pouvez l’utiliser pour empêcher des erreurs dues à des délais d’attente réseau. Toutefois, cette solution de contournement peut provoquer des attentes indéfinies. Préparez-vous à arrêter les connexions si nécessaire.

Si vous ne pouvez pas effectuer de 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 au plus. Il doit s’agir d’une opération d’écriture, telle que la réécriture de la date de création ou de modification du fichier. Sinon, vous pouvez obtenir les résultats mis en cache, et votre opération peut ne pas déclencher la reconnexion.

Sous Windows, les erreurs suivantes peuvent s’afficher :

Descripteurs ou baux de fichiers orphelins

L’un des principaux objectifs d’un partage de fichiers est que plusieurs utilisateurs et applications puissent interagir simultanément avec les fichiers et les répertoires du partage. Pour faciliter cette interaction, les partages de fichiers offrent plusieurs moyens de négocier l’accès aux fichiers et aux répertoires.

Quand vous ouvrez un fichier à partir d’un partage de fichiers Azure monté via 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 alors que vous l’avez ouvert.
• Write : d’autres utilisateurs peuvent écrire dans le fichier alors que vous l’avez ouvert.
• ReadWrite : combinaison des modes de partage Read et Write.
• Delete : d’autres utilisateurs peuvent supprimer le fichier alors que vous l’avez ouvert.

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

Bien que les descripteurs de fichiers et les baux jouent un rôle important, il peut arriver que les descripteurs de fichiers et les baux soient orphelins. Quand cela se produit, cela peut causer 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 ce fichier est utilisé par un autre processus.
• L’action ne peut pas être effectuée, 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 varie selon qu’il est dû à un descripteur de fichier ou à un bail orphelin.

Cause 1

Un descripteur de fichier empêche la modification ou la suppression d’un fichier/répertoire. Vous pouvez utiliser la cmdlet 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 persiste, vous pouvez forcer la fermeture d’un descripteur de fichier.

Solution 1

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

Cause 2

Un bail de fichier empêche la modification ou la suppression d’un fichier. Vous pouvez vérifier 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 correspondant à 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 ou rompre le bail. Pour libérer le bail, vous avez besoin du LeaseId du bail, que vous définissez lors de sa création. Vous n’avez pas besoin du LeaseId pour rompre le bail.

L’exemple suivant montre comment rompre le bail pour le fichier indiqué en 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

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

Ouvrir des descripteurs sur des fichiers ou des répertoires

Cause

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

Solution

Si les clients SMB ont fermé tous les descripteurs ouverts et que le problème persiste, effectuez les étapes suivantes :

• 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.

Erreur 1816 - Quota insuffisant pour traiter cette commande

Cause

L'erreur 1816 se produit lorsque vous atteignez la limite autorisée de descripteurs ouverts simultanément pour un fichier ou un répertoire du partage de fichiers Azure. Pour plus d’informations, consultez la page sur la de tarification Azure Files.

Solution

Réduisez le nombre de handles ouverts simultanément en fermant certains d’entre eux, puis réessayez. Pour plus d’informations, consultez Liste de contrôle des performances et de l’extensibilité de Microsoft Azure Storage.

Pour afficher les descripteurs ouverts pour un partage de fichiers, un annuaire ou un fichier, utilisez la cmdlet PowerShell Get-AzStorageFileHandle.

Pour fermer les descripteurs ouverts d'un partage de fichiers, d'un annuaire ou d'un fichier, utilisez la cmdlet PowerShell Close-AzStorageFileHandle.

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

Cause

Si vous mettez en cache/conservez un grand nombre de descripteurs ouverts pendant une longue période, vous pouvez voir cette défaillance côté serveur en raison de la limitation. Lorsqu’un grand nombre de descripteurs sont mis en cache par le client, la plupart de ces descripteurs peuvent passer en même temps à une phase de reconnexion, en créant une file d’attente sur le serveur qui doit être limitée. La logique de nouvelle tentative et la limitation sur le serveur principal pour la reconnexion prend plus de temps que le délai d’expiration du client. Cette situation se manifeste en tant que client qui n’est pas en mesure d’utiliser un descripteur 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 descripteur client est déconnecté du serveur (par exemple, une panne réseau de plusieurs minutes) qui peut provoquer cette erreur.

Solution

Ne conservez 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 d’échelle supérieures 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.

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

Dans Linux, vous recevez un message d’erreur semblable au suivant :

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

Cause

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

Azure Files prend en charge 10 000 descripteurs ouverts sur le répertoire racine et 2 000 descripteurs 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 réessayez l’opération.

Pour afficher les descripteurs ouverts pour un partage de fichiers, un annuaire ou un fichier, utilisez la cmdlet PowerShell Get-AzStorageFileHandle.

Pour fermer les descripteurs ouverts d'un partage de fichiers, d'un annuaire ou d'un fichier, utilisez la cmdlet PowerShell Close-AzStorageFileHandle.