Partager via

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

  • Article

Cet article répertorie les problèmes courants qui peuvent se produire lorsque vous essayez de vous connecter aux 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 de ces problèmes.

Note

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.

Important

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

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

Connexion ou montage impossible d’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.

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 à l’aide de l’authentification basée sur l’identité, l’accès au partage de fichiers échoue avec l’erreur « Accès refusé » si les autorisations au niveau du partage sont incorrectes.

Solution pour la cause 3

Vérifiez que les autorisations au niveau du partage sont configurées correctement. 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 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.

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

Note

Cette commande retourne l’adresse IP actuelle du compte de stockage. Cette adresse IP est susceptible de changer à tout moment. Ne codez pas cette adresse IP en dur dans un script 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 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.

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

Erreur « Nom d’utilisateur ou mot de passe 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 handles 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 tentez d’accéder à un partage de fichiers Azure ou d’en supprimer un

Quand vous tentez d’accéder à un partage de fichiers Azure ou d’en supprimer un dans le portail, vous recevrez peut-être l’erreur suivante :

Aucun accès Code d’erreur : 403

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

Solution pour la cause 1

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 des 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 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 en savoir plus, consultez Guide pratique pour sécuriser votre compte de stockage avec le contrôle d’accès Azure en fonction du rôle (Azure RBAC).

Verrous et baux de fichiers

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

  • Verrous de ressource sur le compte de stockage : toutes les ressources Azure, notamment le compte de stockage, prennent en charge les verrous de ressource. Les verrous peuvent être placés sur le compte de stockage par un administrateur ou par des services tels que Sauvegarde Azure. Deux variantes de verrous de ressources existent : modifier, ce qui empêche toutes les modifications apportées au compte de stockage et à ses ressources, et supprime, ce qui empêche uniquement les suppressions du compte de stockage et de ses ressources. Quand vous modifiez ou supprimez des partages par le biais du fournisseur de ressources Microsoft.Storage, des verrous de ressource sont appliqués sur les partages de fichiers et les instantanés de partage Azure. La plupart des opérations du portail, des applets de commande Azure PowerShell pour Azure Files avec Rm le nom (par exemple, Get-AzRmStorageShare) et les commandes Azure CLI dans le share-rm groupe de commandes (par exemple) az storage share-rm listutilisent le Microsoft.Storage fournisseur de ressources. Certains outils et utilitaires tels que Explorateur Stockage, les applets de commande de gestion Azure Files PowerShell héritées sans Rm nom (par exempleGet-AzStorageShare), et les commandes Azure Files CLI héritées 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 le plan de contrôle dans Azure Files.

  • Baux de partage/d’instantanés de partage : les baux de partage sont un type de verrou propriétaire pour les partages de fichiers et les instantanés de partage de fichiers Azure. 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. Quand un bail est placé sur un partage de fichiers ou un instantané de partage de fichiers Azure, il est possible de modifier ou de supprimer le partage ou l’instantané de partage de fichiers avec l’ID de bail. Les administrateurs peuvent également libérer le bail avant les opérations de modification, qui nécessitent l’ID de bail ou interrompre le bail, ce qui ne nécessite pas l’ID de bail. Pour plus d’informations sur les baux de partage, consultez Lease Share.

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

Avant d’exécuter le script suivant, vous devriez installer la préversion 3.10.1 du module PowerShell Stockage Azure.

Important

Les services à valeur ajoutée qui prennent des verrous de ressource et des baux de partage/instantantés de partage sur vos ressources Azure Files peuvent réappliquer périodiquement les verrous et les baux. La modification ou la suppression de ressources verrouillées par des services à valeur ajoutée peut avoir un impact sur le fonctionnement normal de ces services, comme la suppression d’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.

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.

Note

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

Notes

Les cmdlets Get-AzStorageFileHandle et Close-AzStorageFileHandle sont incluses au module Az PowerShell version 2.4 ou ultérieure. Pour installer le module PowerShell Az le plus récent, consultez Installer le module Azure PowerShell.

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

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

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

Cause :

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

Solution

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

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

Cause :

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

Solution

Vérifiez que vous passez l’horodatage GMT dans le format correct, c’est-à-dire @GMT-year.month.day-hour.minutes.seconds. Pour plus d’informations, consultez Monter un instantané de partage de fichiers.

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

Cause

Si l’instantané que vous tentez de monter n’existe pas, la mount commande peut échouer avec cette erreur. Pour le confirmer, vérifiez les messages du journal du noyau (dmesg) et dmesg affiche une entrée de journal comme :

[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 l’instantané que vous tentez de monter existe. Pour plus d’informations sur la liste des instantanés disponibles pour un partage de fichiers Azure donné, consultez Monter un instantané de partage de fichiers.

Quota de disque ou erreurs réseau provenant d’un trop grand nombre de descripteurs 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.

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.

Note

Les cmdlets Get-AzStorageFileHandle et Close-AzStorageFileHandle sont incluses au module Az PowerShell version 2.4 ou ultérieure. Pour installer le module PowerShell Az le plus récent, consultez Installer le module Azure PowerShell.

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.

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 clair, puis de nouveau chiffré une fois à destination. Toutefois, vous pouvez voir l’erreur suivante quand 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 survenir si vous utilisez le système de fichiers EFS (Encrypting File System). Les fichiers chiffrés BitLocker peuvent être copiés vers Azure Files. Toutefois, Azure Files ne prend pas en charge EFS NTFS.

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. Les fichiers chiffrés peuvent ainsi être enregistrés comme fichiers déchiffrés une fois à destination.
  • Définissez la clé de Registre suivante :
    • Chemin d’accès = HKLM\Software\Policies\Microsoft\Windows\System
    • Type de valeur = DWORD
    • Nom = CopyFileAllowDecryptedRemoteDestination
    • Valeur = 1

Notez bien que la définition de la clé de Registre affecte toutes les opérations de copie sur les partages réseau.

Erreur ConditionHeadersNotSupported sur une application web utilisant Azure Files à partir du navigateur

L’erreur ConditionHeadersNotSupported se produit quand vous accédez à du contenu hébergé dans Azure Files à partir d’une application utilisant des en-têtes conditionnels (par exemple, un navigateur web) et que l’accès échoue. L’erreur indique que les en-têtes de condition ne sont pas pris en charge.

Capture d’écran montrant le message d’erreur ConditionHeadersNotSupported.

Cause

Les en-têtes conditionnels ne sont pas encore pris en charge. Les applications qui utilisent ces en-têtes doivent demander le fichier complet pour chaque accès au fichier.

Solution de contournement

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

Screeshot qui affiche la propriété du fichier CacheControl.

Voir aussi

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.