Delen via

Connectiviteits- en toegangsproblemen met Azure Files oplossen (SMB)

  • Artikel

In dit artikel vindt u veelvoorkomende problemen die kunnen optreden wanneer u verbinding probeert te maken met en toegang probeert te krijgen tot Azure-bestandsshares van Server Message Block (SMB) van Windows- of Linux-clients. Het biedt ook mogelijke oorzaken en oplossingen voor deze problemen.

Notitie

Was dit artikel nuttig? Uw input is belangrijk voor ons. Gebruik de knop Feedback op deze pagina om ons te laten weten hoe goed dit artikel voor u heeft gewerkt of hoe we het kunnen verbeteren.

Belangrijk

Dit artikel is alleen van toepassing op SMB-shares. Zie Problemen met Azure NFS-bestandsshares oplossen voor meer informatie over NFS-shares (Network File System).

Van toepassing op

Bestands sharetype SMB NFS
Standaardbestandsshares (GPv2), LRS/ZRS
Standaardbestandsshares (GPv2), GRS/GZRS
Premium bestandsshares (FileStorage), LRS/ZRS

Kan geen verbinding maken met of koppelen aan een Azure-bestandsshare

Selecteer het tabblad Windows of Linux, afhankelijk van het clientbesturingssysteem dat u gebruikt voor toegang tot Azure-bestandsshares.

Wanneer u verbinding probeert te maken met een Azure-bestandsshare in Windows, ontvangt u mogelijk de volgende foutberichten.

Fout 5 wanneer u een Azure-bestandsshare koppelt

  • Systeemfout 5 heeft zich voorgedaan. Toegang wordt geweigerd.

Oorzaak 1: niet-versleuteld communicatiekanaal

Verbindingen met Azure-bestandsshares worden uit veiligheidsoverwegingen geblokkeerd als het communicatiekanaal niet is versleuteld en als de verbindingspoging niet is ondernomen vanuit hetzelfde datacentrum als waar de Azure-bestandsshares zich bevinden. Als de instelling Beveiligde overdracht vereist is ingeschakeld op de opslagaccount, worden niet-versleutelde verbindingen binnen hetzelfde datacentrum ook geblokkeerd. Een versleuteld communicatiekanaal wordt alleen geleverd als het besturingssysteem van de eindgebruiker SMB-encryptie ondersteunt.

Windows 8, Windows Server 2012 en latere versies van elk systeem onderhandelt over aanvragen die SMB 3 bevatten.x, die versleuteling ondersteunt.

Oplossing voor oorzaak 1

  1. Verbinding maken vanaf een client die ondersteuning biedt voor SMB-versleuteling (Windows 8/Windows Server 2012 of hoger).
  2. Maak verbinding vanaf een virtuele machine (VM) in hetzelfde datacentrum als het Azure-opslagaccount dat wordt gebruikt voor de Azure-bestandsshare.
  3. Controleer of de instelling Beveiligde overdracht vereist is uitgeschakeld op het opslagaccount als de client geen SMB-encryptie ondersteunt.

Oorzaak 2: er zijn regels voor het virtuele netwerk of de firewall ingeschakeld in het opslagaccount

Netwerkverkeer wordt geweigerd als er regels voor het VNET (virtueel netwerk) of de firewall zijn geconfigureerd in het opslagaccount, tenzij het IP-adres van de client of het virtuele netwerk op de toelatingslijst staat.

Oplossing voor oorzaak 2

Controleer of regels voor het virtuele netwerk of de firewall juist zijn geconfigureerd in het opslagaccount. Als u wilt testen of het probleem wordt veroorzaakt door regels voor het virtuele netwerk of de firewall, wijzigt u de instelling in het opslagaccount in Toegang toestaan vanaf alle netwerken. Zie Firewalls en virtuele netwerken voor Azure Storage configureren voor meer informatie.

Oorzaak 3: machtigingen op shareniveau zijn onjuist bij gebruik van identiteitsgebaseerde verificatie

Als gebruikers toegang krijgen tot de Azure bestandsshare met behulp van Active Directory (AD) of Microsoft Entra Domeinservices verificatie, mislukt de toegang tot de bestandsshare met de foutmelding "Toegang geweigerd" als de rechten op share-niveau onjuist zijn.

Oplossing voor oorzaak 3

Controleer of machtigingen juist zijn geconfigureerd:

  • Active Directory-domein Services (AD DS) zie Machtigingen op shareniveau toewijzen.

    Machtigingstoewijzingen op shareniveau worden ondersteund voor groepen en gebruikers die zijn gesynchroniseerd van AD DS naar Microsoft Entra ID met behulp van Microsoft Entra Connect Sync of Microsoft Entra Connect-cloudsynchronisatie. Controleer of groepen en gebruikers aan wie machtigingen op shareniveau worden toegewezen, niet worden ondersteund door alleen cloudgroepen.

  • Microsoft Entra Domain Services zie Machtigingen op shareniveau toewijzen.

Fout 53, Fout 67 of Fout 87 wanneer u een Azure-bestandsshare koppelt of ontkoppelt

Wanneer u probeert een bestandsshare te koppelen vanuit een on-premises of een ander datacenter, krijgt u mogelijk de volgende fouten:

  • Systeemfout 53 heeft zich voorgedaan. Het netwerkpad is niet gevonden.
  • Systeemfout 67 heeft zich voorgedaan. De naam van het netwerk kan niet worden gevonden.
  • Systeemfout 87 heeft zich voorgedaan. De parameter is onjuist.

Oorzaak 1: Poort 445 is geblokkeerd

Systeemfout 53 of systeemfout 67 kunnen optreden als uitgaande communicatie vanuit poort 445 naar een Azure Files-datacenter is geblokkeerd. Ga naar TechNet voor een overzicht van welke internetproviders toegang via poort 445 toestaan en welke niet.

Gebruik het hulpprogramma AzFileDiagnostics of de cmdlet Test-NetConnection om te controleren of poort 445 wordt geblokkeerd op basis van uw firewall of internetprovider.

Als u de Test-NetConnection cmdlet wilt gebruiken, moet de Azure PowerShell-module zijn geïnstalleerd. Zie Azure PowerShell-module installeren voor meer informatie. Vergeet niet om <your-storage-account-name> en <your-resource-group-name> te vervangen door de betreffende namen van uw opslagaccount.

$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

Als de verbinding is geslaagd, hoort u de volgende uitvoer te zien:

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

Notitie

Met deze opdracht wordt het huidige IP-adres van het opslagaccount geretourneerd. Dit IP-adres blijft niet noodzakelijkerwijs hetzelfde en kan op elk moment veranderen. Codeer dit IP-adres niet in scripts of in een firewallconfiguratie.

Oplossingen voor oorzaak 1

Oplossing 1: Gebruik Azure File Sync als een QUIC-eindpunt . U kunt Azure File Sync gebruiken als tijdelijke oplossing voor toegang tot Azure Files vanaf clients waarvoor poort 445 is geblokkeerd. Hoewel Azure Files SMB niet rechtstreeks ondersteunt via QUIC, biedt Windows Server 2022 Azure Edition wel ondersteuning voor het QUIC-protocol. U kunt een lichtgewicht cache van uw Azure-bestandsshares maken op een Windows Server 2022 Azure Edition-VM met behulp van Azure File Sync. Deze configuratie maakt gebruik van poort 443, dat veel uitgaand is voor ondersteuning van HTTPS, in plaats van poort 445. Zie SMB via QUIC met Azure File Sync voor meer informatie over deze optie.

Oplossing 2: gebruik VPN of ExpressRoute door een virtueel particulier netwerk (VPN) of ExpressRoute in te stellen van on-premises naar uw Azure-opslagaccount, waarbij Azure Files beschikbaar wordt gemaakt op uw interne netwerk met behulp van privé-eindpunten, het verkeer via een beveiligde tunnel loopt in plaats van via internet. Volg de instructies voor het instellen van een VPN voor toegang tot Azure Files vanuit Windows.

Oplossing 3: blokkering van poort 445 opheffen met hulp van uw internetprovider/IT-beheerder Werk samen met uw IT-afdeling of internetprovider om poort 445 uitgaand naar Azure IP-bereiken te openen.

Oplossing 4: gebruik op REST API gebaseerde hulpprogramma's, zoals Storage Explorer of PowerShell Azure Files, biedt ook ondersteuning voor REST naast SMB. REST-toegang werkt via poort 443 (standaard TCP). Er zijn verschillende hulpprogramma's die zijn geschreven met behulp van REST API die een uitgebreide ui-ervaring mogelijk maken. Storage Explorer is daar een van. Download en installeer Storage Explorer en maak verbinding met de bestandsshare die door Azure Files wordt ondersteund. U kunt ook PowerShell gebruiken die ook gebruikmaakt van REST API.

Oorzaak 2: NTLMv1 is ingeschakeld

Systeemfout 53 of systeemfout 87 kunnen optreden als NTLMv1-communicatie is ingeschakeld op de client. Azure Files biedt alleen ondersteuning voor NTLMv2-verificatie. Als NTLMv1 is ingeschakeld, is de client minder veilig. Om deze reden wordt communicatie geblokkeerd voor Azure Files.

Als u wilt bepalen of dit de oorzaak van de fout is, controleert u of de volgende registersubsleutel niet is ingesteld op een waarde kleiner dan 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

Zie het onderwerp LmCompatibilityLevel in TechNet voor meer informatie.

Oplossing voor oorzaak 2

Zet de waarde LmCompatibilityLevel terug naar de standaardwaarde 3 in de volgende registersubsleutel:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Mislukt met foutcode 0x800704b3

Wanneer u probeert een Azure-bestandsshare te koppelen, wordt de volgende fout weergegeven:

Foutcode: 0x800704b3
Symbolische naam: ERROR_NO_NET_OR_BAD_PATH
Foutbeschrijving: het netwerkpad is onjuist getypt, bestaat niet of de netwerkprovider is momenteel niet beschikbaar. Probeer het pad opnieuw te opgeven of neem contact op met de netwerkbeheerder.

Oorzaak

Deze fout kan optreden als een van de belangrijkste Windows-netwerkservices is uitgeschakeld als een service die expliciet afhankelijk is van die netwerkservices, kan niet worden gestart.

Oplossing

Controleer of een van de volgende services de status Gestopt heeft op de Windows-VM:

  • Netwerkverbindingen
  • Netwerklijstservice
  • Netwerklocatiebewustzijn
  • Network Store Interface Service
  • DHCP-client
  • TCP/IP NetBIOS Helper
  • Werkstation

Als u er een hebt gevonden, start u de service(s) en probeert u de Azure-bestandsshare opnieuw te koppelen.

Toepassing of service heeft geen toegang tot een gekoppeld Azure Files-station

Oorzaak

Stations worden per gebruiker gekoppeld. Als uw toepassing of service wordt uitgevoerd onder een ander gebruikersaccount dan het account dat het station heeft gekoppeld, ziet de toepassing het station niet.

Oplossing

Gebruik een van de volgende oplossingen:

  • Koppel het station vanuit hetzelfde gebruikersaccount dat de toepassing bevat. U kunt een hulpprogramma zoals PsExec gebruiken.

  • Geef de naam en sleutel van het opslagaccount door in de parameters gebruikersnaam en wachtwoord van de net use opdracht.

  • Gebruik de cmdkey opdracht om de referenties toe te voegen aan Credential Manager. Voer deze actie uit vanaf een opdrachtregel onder de context van het serviceaccount, via een interactieve aanmelding of met behulp van runas.

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

  • Wijs de share rechtstreeks toe zonder een toegewezen stationsletter te gebruiken. Sommige toepassingen maken mogelijk niet opnieuw verbinding met de stationsletter, dus het gebruik van het volledige UNC-pad is mogelijk betrouwbaarder:

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

Nadat u deze instructies hebt gevolgd, wordt mogelijk het volgende foutbericht weergegeven wanneer u netgebruik uitvoert voor het systeem-/netwerkserviceaccount: 'Systeemfout 1312 is opgetreden. Er bestaat geen opgegeven aanmeldingssessie. Het is mogelijk al beëindigd." Als deze fout wordt weergegeven, moet u ervoor zorgen dat de gebruikersnaam die wordt doorgegeven aan net use domeingegevens bevat (bijvoorbeeld: [storage account name].file.core.windows.net).

Geen map met een stationsletter in 'Mijn computer' of 'Deze pc'

Als u een Azure-bestandsshare als beheerder toe wijst met behulp van de net use opdracht, lijkt de share te ontbreken.

Oorzaak

Windows Bestandenverkenner wordt standaard niet uitgevoerd als beheerder. Als u een opdrachtprompt met beheerdersrechten uitvoert net use , wijst u het netwerkstation toe als beheerder. Omdat toegewezen stations gebruikersgericht zijn, worden de stations niet weergegeven in het gebruikersaccount dat is aangemeld als ze zijn gekoppeld onder een ander gebruikersaccount.

Oplossing

Koppel de share vanaf een opdrachtregel die geen beheerder is. U kunt dit TechNet-onderwerp ook volgen om de EnableLinkedConnections registerwaarde te configureren.

De opdracht net use mislukt als het opslagaccount een slash bevat

Oorzaak

De net use opdracht interpreteert een slash (/) als een opdrachtregeloptie. Als de naam van uw gebruikersaccount begint met een slash, mislukt de stationstoewijzing.

Oplossing

U kunt een van de volgende stappen gebruiken om het probleem te omzeilen:

  • Voer de volgende PowerShell-opdracht uit:

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

    Vanuit een batchbestand kunt u de opdracht op deze manier uitvoeren:

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

  • Plaats dubbele aanhalingstekens rond de sleutel om dit probleem te omzeilen, tenzij de slash het eerste teken is. Als dat het geval is, gebruikt u de interactieve modus en voert u uw wachtwoord afzonderlijk in of genereert u uw sleutels opnieuw om een sleutel op te halen die niet begint met een slash.

De opdracht New-PSDrive mislukt met de fout 'het netwerkresourcetype is niet juist'

Oorzaak

Mogelijk ziet u dit foutbericht als de bestandsshare niet toegankelijk is. Poort 445 is bijvoorbeeld geblokkeerd of er is een PROBLEEM met dns-omzetting.

Oplossing

Zorg ervoor dat poort 445 is geopend en controleer de DNS-resolutie en connectiviteit met uw bestandsshare.

Kan een Azure-bestandsshare (of share-momentopname) niet openen, wijzigen of verwijderen

Fout 'De gebruikersnaam of het wachtwoord is onjuist' na een door de klant geïnitieerde failover

In een door de klant geïnitieerd failoverscenario met geografisch redundante opslagaccounts worden bestandsingangen en leases niet bewaard bij failover. Clients moeten de bestandsshares ontkoppelen en opnieuw koppelen.

Fout 'Geen toegang' wanneer u probeert een Azure-bestandsshare te openen of te verwijderen

Wanneer u probeert een Azure-bestandsshare te openen of te verwijderen met behulp van Azure Portal, wordt mogelijk de volgende fout weergegeven:

Geen toegangscode: 403

Oorzaak 1: Regels voor virtueel netwerk of firewall zijn ingeschakeld voor het opslagaccount

Oplossing voor oorzaak 1

Controleer of regels voor het virtuele netwerk of de firewall juist zijn geconfigureerd in het opslagaccount. Als u wilt testen of het probleem wordt veroorzaakt door regels voor virtuele netwerken of firewalls, wijzigt u de instelling in het opslagaccount tijdelijk in Toegang vanuit alle netwerken toestaan. Zie Firewalls en virtuele netwerken voor Azure Storage configureren voor meer informatie.

Oorzaak 2: Uw gebruikersaccount heeft geen toegang tot het opslagaccount

Oplossing voor oorzaak 2

Blader naar het opslagaccount waarin de Azure-bestandsshare zich bevindt, selecteer Toegangsbeheer (IAM) en controleer of uw gebruikersaccount toegang heeft tot het opslagaccount. Zie Uw opslagaccount beveiligen met op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) voor meer informatie.

Bestandsvergrendelingen en leases

Als u een Azure-bestandsshare of -momentopname niet kunt wijzigen of verwijderen, kan dit worden veroorzaakt door bestandsvergrendelingen of leases. Azure Files biedt twee manieren om onbedoelde wijziging of verwijdering van Azure-bestandsshares en momentopnamen van shares te voorkomen:

  • Resourcevergrendelingen voor opslagaccounts: Alle Azure-resources, inclusief het opslagaccount, ondersteunen resourcevergrendelingen. Vergrendelingen kunnen door een beheerder of door services zoals Azure Backup in het opslagaccount worden geplaatst. Er bestaan twee variaties van resourcevergrendelingen: wijzigen, waardoor alle wijzigingen in het opslagaccount en de bijbehorende resources worden voorkomen en verwijderd, waardoor alleen verwijderingen van het opslagaccount en de bijbehorende resources worden voorkomen. Wanneer u shares wijzigt of verwijdert via de Microsoft.Storage resourceprovider, worden resourcevergrendelingen afgedwongen op Azure-bestandsshares en momentopnamen van shares. De meeste portalbewerkingen, Azure PowerShell-cmdlets voor Azure Files met Rm in de naam (bijvoorbeeld Get-AzRmStorageShare), en Azure CLI-opdrachten in de share-rm opdrachtgroep (bijvoorbeeld az storage share-rm list) gebruiken de Microsoft.Storage resourceprovider. Sommige hulpprogramma's en hulpprogramma's, zoals Storage Explorer, verouderde Azure Files PowerShell-beheer-cmdlets zonder Rm in de naam (bijvoorbeeld Get-AzStorageShare), en verouderde Azure Files CLI-opdrachten onder de share opdrachtgroep (bijvoorbeeld az storage share list) gebruiken verouderde API's in de FileREST-API die de Microsoft.Storage resourceprovider en resourcevergrendelingen omzeilen. Zie het besturingsvlak in Azure Files voor meer informatie over verouderde beheer-API's die beschikbaar zijn in de FileREST-API.

  • Leases voor share-/sharemomentopnamen: Share-leases zijn een soort eigen vergrendeling voor Azure-bestandsshares en momentopnamen van bestandsshares. Leases kunnen worden geplaatst op afzonderlijke Azure-bestandsshares of momentopnamen van bestandsshares door beheerders door de API aan te roepen via een script of door services met toegevoegde waarde, zoals Azure Backup. Wanneer een lease wordt geplaatst op een Momentopname van een Azure-bestandsshare of -bestandsshare, kan het wijzigen of verwijderen van de momentopname van de bestandsshare/share worden uitgevoerd met de lease-id. Beheerders kunnen de lease ook vrijgeven voordat bewerkingen worden gewijzigd. Hiervoor is de lease-id vereist of wordt de lease onderbroken. Hiervoor is de lease-id niet vereist. Zie de leaseshare voor meer informatie over het delen van leases.

Omdat resourcevergrendelingen en leases de beoogde beheerdersbewerkingen op uw opslagaccount/Azure-bestandsshares kunnen verstoren, kunt u eventuele resourcevergrendelingen/leases verwijderen die handmatig of automatisch op uw resources zijn geplaatst door services met toegevoegde waarde, zoals Azure Backup. Met het volgende script worden alle resourcevergrendelingen en leases verwijderd. Vergeet niet om de juiste waarden voor uw omgeving te vervangen en <storage-account> te vervangen<resource-group>.

Voordat u het volgende script uitvoert, moet u de nieuwste versie van de Azure Storage PowerShell-module installeren.

Belangrijk

Services met toegevoegde waarde die resourcevergrendelingen maken en momentopnameleases delen/delen op uw Azure Files-resources, kunnen periodiek opnieuw worden toegepast op vergrendelingen en leases. Het wijzigen of verwijderen van vergrendelde resources door services met toegevoegde waarde kan van invloed zijn op de normale werking van deze services, zoals het verwijderen van momentopnamen van shares die worden beheerd door Azure Backup.

# 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 { }
    }

Kan een bestand of map niet wijzigen, verplaatsen/hernoemen of verwijderen

Selecteer het tabblad Windows of Linux, afhankelijk van het clientbesturingssysteem dat u gebruikt voor toegang tot Azure-bestandsshares.

In Windows ziet u mogelijk de volgende fouten.

Zwevende bestandsingangen of leases

Een van de belangrijkste doelen van een bestandsshare is dat meerdere gebruikers en toepassingen tegelijkertijd kunnen communiceren met bestanden en mappen in de share. Bestandsshares bieden verschillende manieren om toegang tot bestanden en mappen te verlenen om deze interactie te ondersteunen.

Wanneer u een bestand opent vanuit een gekoppelde Azure-bestandsshare via SMB, vraagt uw toepassing/besturingssysteem een bestandsingang aan. Dit is een verwijzing naar het bestand. Uw toepassing geeft onder andere een modus voor het delen van bestanden op wanneer er een bestandsingang wordt aangevraagd, waarmee het niveau van exclusiviteit van uw toegang tot het bestand wordt opgegeven dat wordt afgedwongen door Azure Files:

  • None: u hebt exclusieve toegang.
  • Read: anderen kunnen het bestand lezen terwijl u het hebt geopend.
  • Write: anderen kunnen naar het bestand schrijven terwijl u het hebt geopend.
  • ReadWrite: een combinatie van zowel de als Write de Read modus voor delen.
  • Delete: anderen kunnen het bestand verwijderen terwijl u het hebt geopend.

Hoewel het FileREST-protocol als staatloos protocol geen concept bestandsingangen heeft, biedt het een vergelijkbaar mechanisme voor het mediaten van toegang tot bestanden en mappen die uw script, toepassing of service kan gebruiken: bestandsleases. Wanneer een bestand wordt geleased, wordt het beschouwd als gelijkwaardig aan een bestandsingang met een modus voor het delen van bestanden.None

Hoewel bestandsingangen en leases een belangrijk doel dienen, kunnen soms bestandsingangen en leases zwevend zijn. Als dit gebeurt, kan dit problemen veroorzaken bij het wijzigen of verwijderen van bestanden. Mogelijk ziet u foutmeldingen zoals:

  • Het proces kan het bestand niet openen omdat het bestand door een ander proces wordt gebruikt.
  • Kan de actie niet voltooien omdat het bestand is geopend in een ander programma.
  • Het document is vergrendeld voor bewerking door een andere gebruiker.
  • De opgegeven resource is gemarkeerd voor verwijdering door een SMB-client.

De oplossing voor dit probleem is afhankelijk van of dit wordt veroorzaakt door een zwevende bestandsingang of lease.

Notitie

REST-leases worden door toepassingen gebruikt om te voorkomen dat bestanden worden verwijderd of gewijzigd. Voordat u leases onderbreekt, moet u bepalen welke toepassing deze verkrijgt. Anders kan het gedrag van de toepassing worden verbroken.

Oorzaak 1

Een bestandsingang voorkomt dat een bestand/map wordt gewijzigd of verwijderd. U kunt de Cmdlet Get-AzStorageFileHandle PowerShell gebruiken om geopende ingangen weer te geven.

Als alle SMB-clients hun geopende ingangen voor een bestand/map hebben gesloten en het probleem zich blijft voordoen, kunt u afdwingen dat een bestandsingang wordt gesloten.

Oplossing 1

Als u wilt afdwingen dat een bestandsingang wordt gesloten, gebruikt u de PowerShell-cmdlet Close-AzStorageFileHandle .

Notitie

De Get-AzStorageFileHandle en Close-AzStorageFileHandle cmdlets zijn opgenomen in Az PowerShell-moduleversie 2.4 of hoger. Zie De Azure PowerShell-module installeren om de meest recente Az PowerShell-module te installeren.

Oorzaak 2

Een bestandslease voorkomt dat een bestand kan worden gewijzigd of verwijderd. U kunt controleren of een bestand een bestandslease heeft met de volgende PowerShell-opdrachten. Vervang , <storage-account>, <file-share>en <path-to-file> door <resource-group>de juiste waarden voor uw omgeving.

# 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

Als een bestand een lease heeft, moet het geretourneerde object de volgende eigenschappen hebben:

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Oplossing 2

Als u een lease uit een bestand wilt verwijderen, kunt u de lease vrijgeven of de lease onderbreken. Voor het vrijgeven van de lease hebt u de LeaseId van de lease nodig. Deze hebt u ingesteld bij het maken van de lease. U hebt de LeaseId niet nodig om de lease te verbreken.

In het volgende voorbeeld ziet u hoe u de lease voor het bestand dat is aangegeven in oorzaak 2 onderbreekt (in dit voorbeeld worden de PowerShell-variabelen van oorzaak 2 voortgezet):

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

Kan geen momentopname van een Azure-bestandsshare koppelen in Linux

'Koppelingsfout(22): Ongeldig argument' bij het koppelen van een momentopname van een Azure-bestandsshare in Linux

Oorzaak

Als de snapshot optie voor de mount opdracht niet wordt doorgegeven in een herkende indeling, kan de mount opdracht mislukken met deze fout. Als u dit wilt bevestigen, controleert u kernellogboekberichten (dmesg) en geeft dmesg een logboekvermelding weer, zoals cifs: Bad value for 'snapshot'.

Oplossing

Zorg ervoor dat u de snapshot optie voor de mount opdracht in de juiste indeling doorgeeft. Raadpleeg de handmatige pagina mount.cifs (bijvoorbeeld man mount.cifs). Een veelvoorkomende fout is het doorgeven van de GMT-tijdstempel in de verkeerde indeling, zoals het gebruik van afbreekstreepjes of dubbele punten in plaats van punten. Zie Een momentopname van een bestandsshare koppelen voor meer informatie.

'Ongeldig momentopnametoken' bij het koppelen van een momentopname van een Azure-bestandsshare in Linux

Oorzaak

Als de momentopnameoptie mount wordt doorgegeven, beginnend met @GMT, maar de indeling nog steeds onjuist is (zoals het gebruik van afbreekstreepjes en dubbele punten in plaats van punten), kan de mount opdracht mislukken met deze fout.

Oplossing

Zorg ervoor dat u de GMT-tijdstempel doorgeeft in de juiste indeling.@GMT-year.month.day-hour.minutes.seconds Zie Een momentopname van een bestandsshare koppelen voor meer informatie.

'Fout bij koppelen(2): Geen dergelijk bestand of dergelijke map' bij het koppelen van een momentopname van een Azure-bestandsshare

Oorzaak

Als de momentopname die u probeert te koppelen niet bestaat, kan de mount opdracht mislukken met deze fout. Als u dit wilt bevestigen, controleert u kernellogboekberichten (dmesg) en geeft dmesg een logboekvermelding weer, zoals:

[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

Oplossing

Zorg ervoor dat de momentopname die u probeert te koppelen bestaat. Zie Een momentopname van een bestandsshare koppelen voor meer informatie over het weergeven van de beschikbare momentopnamen voor een bepaalde Azure-bestandsshare.

Schijfquotum of netwerkfouten van te veel geopende ingangen

Selecteer het tabblad Windows of Linux, afhankelijk van het clientbesturingssysteem dat u gebruikt voor toegang tot Azure-bestandsshares.

Fout 1816: er is onvoldoende quotum beschikbaar om deze opdracht te verwerken

Oorzaak

Fout 1816 treedt op wanneer u de bovengrens bereikt van gelijktijdige geopende ingangen die zijn toegestaan voor een bestand of map op de Azure-bestandsshare. Zie Azure Files-schaalbaarheidsdoelen voor meer informatie.

Oplossing

Verminder het aantal gelijktijdige geopende ingangen door enkele ingangen te sluiten en probeer het vervolgens opnieuw. Zie de controlelijst voor prestaties en schaalbaarheid van Microsoft Azure Storage voor meer informatie.

Gebruik de Get-AzStorageFileHandle PowerShell cmdlet om de openstaande ingangen voor een bestandsshare, map of bestand te bekijken.

Als u geopende ingangen voor een bestandsshare, map of bestand wilt sluiten, gebruikt u de PowerShell-cmdlet Close-AzStorageFileHandle.Az PowerShell-module.

Notitie

De Get-AzStorageFileHandle en Close-AzStorageFileHandle cmdlets zijn opgenomen in Az PowerShell-moduleversie 2.4 of hoger. Zie De Azure PowerShell-module installeren om de meest recente Az PowerShell-module te installeren.

ERROR_UNEXP_NET_ERR (59) bij het uitvoeren van bewerkingen op een ingang

Oorzaak

Als u een groot aantal geopende ingangen gedurende een lange periode in de cache opgeslagen in de cache opgeslagen, kan dit mislukken aan de serverzijde vanwege beperkingsredenen. Wanneer een groot aantal ingangen door de client in de cache wordt opgeslagen, kunnen veel van deze ingangen tegelijkertijd in een fase voor opnieuw verbinding worden gemaakt, waardoor een wachtrij wordt opgebouwd op de server die moet worden beperkt. De logica voor opnieuw proberen en de beperking op de back-end duurt langer dan de time-out van de client. Deze situatie treedt op als een client die geen bestaande ingang voor een bewerking kan gebruiken, waarbij alle bewerkingen mislukken met ERROR_UNEXP_NET_ERR (59).

Er zijn ook edge-gevallen waarin de clientgreep wordt verbroken van de server (bijvoorbeeld een netwerkstoring van enkele minuten) die deze fout kan veroorzaken.

Oplossing

Houd niet een groot aantal ingangen in de cache. Sluit ingangen en probeer het opnieuw. Gebruik Get-AzStorageFileHandle en Close-AzStorageFileHandle PowerShell-cmdlets om geopende ingangen weer te geven/te sluiten.

Als u Azure-bestandsshares gebruikt om profielcontainers of schijfinstallatiekopieën op te slaan voor een grootschalige virtuele bureaubladimplementatie of andere workloads die ingangen openen voor bestanden, mappen en/of de hoofdmap, bereikt u mogelijk de bovengrens voor gelijktijdige open ingangen. In dit geval gebruikt u een extra Azure-bestandsshare en distribueert u de containers of installatiekopieën tussen de shares.

Fout 'U kopieert een bestand naar een bestemming die geen versleuteling ondersteunt'

Wanneer een bestand via het netwerk wordt gekopieerd, wordt het bestand ontsleuteld op de broncomputer, verzonden in tekst zonder opmaak en opnieuw versleuteld op het doel. Mogelijk ziet u echter de volgende fout wanneer u een versleuteld bestand probeert te kopiëren: 'U kopieert het bestand naar een bestemming die geen versleuteling ondersteunt'.

Oorzaak

Dit probleem kan optreden als u Encrypting File System (EFS) gebruikt. Met BitLocker versleutelde bestanden kunnen worden gekopieerd naar Azure Files. Azure Files biedt echter geen ondersteuning voor NTFS EFS.

Tijdelijke oplossing

Als u een bestand via het netwerk wilt kopiëren, moet u het eerst ontsleutelen. Hanteer één van de volgende methoden:

  • Gebruik de opdracht copy /d . Hiermee kunnen de versleutelde bestanden worden opgeslagen als ontsleutelde bestanden op de bestemming.
  • Stel de volgende registersleutel in:
    • Pad = HKLM\Software\Policies\Microsoft\Windows\System
    • Waardetype = DWORD
    • Naam = CopyFileAllowDecryptedRemoteDestination
    • Waarde = 1

Houd er rekening mee dat het instellen van de registersleutel van invloed is op alle kopieerbewerkingen die worden uitgevoerd op netwerkshares.

Error ConditionHeadersNotSupported from a Web Application using Azure Files from Browser

De fout ConditionHeadersNotSupported treedt op bij het openen van inhoud die wordt gehost in Azure Files via een toepassing die gebruikmaakt van voorwaardelijke headers, zoals een webbrowser, mislukt de toegang. De fout geeft aan dat voorwaardeheaders niet worden ondersteund.

Schermopname van het foutbericht ConditionHeadersNotSupported.

Oorzaak

Voorwaardelijke headers worden nog niet ondersteund. Toepassingen die ze implementeren, moeten het volledige bestand aanvragen telkens wanneer het bestand wordt geopend.

Tijdelijke oplossing

Wanneer een nieuw bestand wordt geüpload, is de eigenschap CacheControl standaard geen cache. Als u wilt afdwingen dat de toepassing het bestand elke keer aanvraagt, moet de eigenschap CacheControl van het bestand worden bijgewerkt van no-cache naar no-cache, no-store en moet deze opnieuw worden gevalideerd. Dit kan worden bereikt met behulp van Azure Storage Explorer.

Screeshot met de eigenschap CacheControl-bestand.

Zie ook

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.