Problemen met Azure Files connectiviteit en toegang (SMB) oplossen

  • Artikel

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

Opmerking

Was dit artikel nuttig? Uw inbreng 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

Type bestandsshare SMB NFS
Standaardbestandsshares (GPv2), LRS/ZRS
Standaard bestandsshares (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 is opgetreden. De toegang wordt geweigerd.

Oorzaak 1: Niet-versleuteld communicatiekanaal

Voor de beveiliging worden verbindingen met Azure-bestandsshares geblokkeerd als het communicatiekanaal niet is versleuteld en de verbindingspoging niet wordt uitgevoerd vanuit hetzelfde datacenter waar de Azure-bestandsshares zich bevinden. Als de instelling Beveiligde overdracht vereist is ingeschakeld voor het opslagaccount, worden niet-versleutelde verbindingen binnen hetzelfde datacenter ook geblokkeerd. Er wordt alleen een versleuteld communicatiekanaal opgegeven als het clientbesturingssysteem van de eindgebruiker SMB-versleuteling ondersteunt.

Windows 8, Windows Server 2012 en latere versies van elk systeem onderhandelen over aanvragen die SMB 3 bevatten.x, dat ondersteuning biedt voor versleuteling.

Oplossing voor oorzaak 1

  1. Maak verbinding 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 datacenter als het Azure-opslagaccount dat wordt gebruikt voor de Azure-bestandsshare.
  3. Controleer of de instelling Beveiligde overdracht vereist is uitgeschakeld voor het opslagaccount als de client geen ondersteuning biedt voor SMB-versleuteling.

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

Netwerkverkeer wordt geweigerd als het virtuele netwerk (VNET) en de firewallregels zijn geconfigureerd voor het opslagaccount, tenzij het IP-adres van de client of het virtuele netwerk is toegestaan.

Oplossing voor oorzaak 2

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

Oorzaak 3: Machtigingen op shareniveau zijn onjuist bij het gebruik van verificatie op basis van identiteit

Als gebruikers toegang hebben tot de Azure-bestandsshare met behulp van Active Directory (AD) of Microsoft Entra Domeinservices verificatie, mislukt de toegang tot de bestandsshare met de fout 'Toegang is geweigerd' als machtigingen op shareniveau onjuist zijn.

Oplossing voor oorzaak 3

Controleer of de machtigingen correct zijn geconfigureerd:

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

    Machtigingstoewijzingen op shareniveau worden ondersteund voor groepen en gebruikers die vanuit AD DS zijn gesynchroniseerd met Microsoft Entra ID met behulp van Microsoft Entra Connect Sync of Microsoft Entra Connect-cloudsynchronisatie. Controleer of groepen en gebruikers waaraan machtigingen op shareniveau zijn toegewezen, geen niet-ondersteunde 'cloud-only'-groepen zijn.

  • Microsoft Entra Domeinservicesmachtigingen 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, kunnen de volgende fouten worden weergegeven:

  • Systeemfout 53 is opgetreden. Kan het netwerkpad niet vinden.
  • Systeemfout 67 is opgetreden. De netwerknaam kan niet worden gevonden.
  • Systeemfout 87 is opgetreden. De parameter is onjuist.

Oorzaak 1: poort 445 is geblokkeerd

Systeemfout 53 of Systeemfout 67 kan optreden als uitgaande communicatie via poort 445 naar een Azure Files datacenter is geblokkeerd. Als u het overzicht wilt zien van ISP's die toegang vanaf poort 445 toestaan of weigeren, gaat u naar TechNet.

Als u wilt controleren of uw firewall of internetprovider poort 445 blokkeert, gebruikt u het hulpprogramma AzFileDiagnostics of de Test-NetConnection cmdlet.

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 en te vervangen door <your-storage-account-name><your-resource-group-name> de relevante namen voor 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, ziet u de volgende uitvoer:

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

Opmerking

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

Oplossingen voor oorzaak 1

Oplossing 1: Azure File Sync gebruiken als QUIC-eindpunt U kunt Azure File Sync gebruiken als tijdelijke oplossing voor toegang tot Azure Files van clients waarvoor poort 445 is geblokkeerd. Hoewel Azure Files SMB niet rechtstreeks ondersteunt via QUIC, ondersteunt Windows Server 2022 Azure Edition wel 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, die algemeen uitgaand is om HTTPS te ondersteunen, in plaats van poort 445. Zie SMB via QUIC met Azure File Sync voor meer informatie over deze optie.

Oplossing 2: VPN of ExpressRoute gebruiken Door een virtueel particulier netwerk (VPN) of ExpressRoute in te stellen van on-premises naar uw Azure-opslagaccount, met Azure Files beschikbaar op uw interne netwerk met behulp van privé-eindpunten, gaat het verkeer via een beveiligde tunnel 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 Neem contact op met uw IT-afdeling of internetprovider om uitgaande poort 445 te openen naar Azure IP-bereiken.

Oplossing 4: Gebruik op REST API gebaseerde hulpprogramma's zoals Storage Explorer of PowerShell Azure Files naast SMB ook REST ondersteunt. REST-toegang werkt via poort 443 (standaard tcp). Er zijn verschillende hulpprogramma's die zijn geschreven met behulp van REST API die een uitgebreide gebruikersinterface-ervaring mogelijk maken. Storage Explorer is er één van. Download en installeer Storage Explorer en maak verbinding met de bestandsshare die wordt ondersteund door Azure Files. U kunt ook PowerShell gebruiken dat ook gebruikmaakt van REST API.

Oorzaak 2: NTLMv1 is ingeschakeld

Systeemfout 53 of systeemfout 87 kan optreden als NTLMv1-communicatie is ingeschakeld op de client. Azure Files ondersteunt alleen NTLMv2-verificatie. Als U NTLMv1 hebt ingeschakeld, maakt u een minder veilige client. Daarom 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 op TechNet voor meer informatie.

Oplossing voor oorzaak 2

Herstel de LmCompatibilityLevel waarde naar de standaardwaarde 3 in de volgende registersubsleutel:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Fout met foutcode 0x800704b3

Wanneer u een Azure-bestandsshare probeert te koppelen, wordt het volgende foutbericht 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. Typ het pad opnieuw of neem contact op met uw netwerkbeheerder.

Oorzaak

Deze fout kan optreden als een windows-kernnetwerk is uitgeschakeld omdat een service die expliciet afhankelijk is van deze netwerkservices niet kan 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
  • Workstation

Als u een of meer services 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 waarmee het station is 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 gebruikersnaam en wachtwoordparameters van de net use opdracht.

  • Gebruik de cmdkey opdracht om de referenties toe te voegen aan Referentiebeheer. Voer deze actie uit vanaf een opdrachtregel in 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 goed verbinding met de stationsletter, dus het volledige UNC-pad kan betrouwbaarder zijn:

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

Nadat u deze instructies hebt gevolgd, wordt mogelijk het volgende foutbericht weergegeven wanneer u net use 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 waaraan wordt doorgegeven 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 toegeeft met behulp van de net use opdracht, lijkt de share te ontbreken.

Oorzaak

Windows Bestandenverkenner wordt standaard niet uitgevoerd als beheerder. Als u uitvoert net use vanaf een beheerdersopdrachtprompt, 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 aan een ander gebruikersaccount.

Oplossing

Koppel de share vanaf een niet-beheerders opdrachtregel. U kunt ook dit TechNet-onderwerp 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 schuine schuine streep, 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 als volgt 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 te krijgen die niet begint met een schuine streep.

New-PSDrive opdracht 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 de DNS-omzetting.

Oplossing

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

Kan een Azure-bestandsshare (of momentopname van de share) 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 de Azure Portal, wordt mogelijk de volgende fout weergegeven:

Geen toegang Foutcode: 403

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

Oplossing voor oorzaak 1

Controleer of de regels voor het virtuele netwerk en de firewall juist zijn geconfigureerd voor het opslagaccount. Als u wilt testen of het probleem wordt veroorzaakt door regels voor virtuele netwerken of firewalls, wijzigt u de instelling voor het opslagaccount tijdelijk in Toegang vanaf alle netwerken toestaan. Zie Azure Storage-firewalls en virtuele netwerken 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 van opslagaccounts: alle Azure-resources, inclusief het opslagaccount, ondersteunen resourcevergrendelingen. Vergrendelingen kunnen op het opslagaccount worden geplaatst door een beheerder of door services zoals Azure Backup. Er bestaan twee variaties van resourcevergrendelingen: wijzigen, waardoor alle wijzigingen in het opslagaccount en de bijbehorende resources worden voorkomen, en verwijderen, 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 besturingsvlak in Azure Files voor meer informatie over verouderde beheer-API's die beschikbaar zijn in de FileREST-API.

  • Leases van 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 Azure-bestandsshare of momentopname van een 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 vóór wijzigingsbewerkingen, waarvoor de lease-id is vereist, of de lease verbreken, waarvoor de lease-id niet is vereist. Zie Leaseshare voor meer informatie over leases van aandelen.

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

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 en leases van share-/sharemomentopnamen op uw Azure Files resources nemen, kunnen vergrendelingen en leases periodiek opnieuw toepassen. 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 zijn 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 bemiddelen om te helpen bij deze interactie.

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 deze een bestandshandgreep aanvraagt, waarmee het exclusiviteitsniveau 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 de Read modi en Write delen.
  • Delete: anderen kunnen het bestand verwijderen terwijl u het hebt geopend.

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

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

  • Het proces heeft geen toegang tot het bestand omdat het bestand wordt gebruikt door een ander proces.
  • De actie kan niet worden voltooid omdat het bestand is geopend in een ander programma.
  • Het document is vergrendeld voor bewerking door een andere gebruiker.
  • De opgegeven resource wordt gemarkeerd voor verwijdering door een SMB-client.

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

Opmerking

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

Oorzaak 1

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

Als alle SMB-clients hun geopende ingangen in een bestand/map hebben gesloten en het probleem zich blijft voordoen, kunt u een bestandsgreep geforceerd sluiten.

Oplossing 1

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

Opmerking

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

Oorzaak 2

Een bestandslease voorkomt dat een bestand wordt gewijzigd of verwijderd. U kunt controleren of een bestand een bestandslease heeft met de volgende PowerShell-opdrachten. Vervang <resource-group>, <storage-account>, <file-share>en <path-to-file> door 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 bevatten:

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 verbreken. Als u de lease wilt vrijgeven, hebt u de LeaseId van de lease nodig, die u instelt wanneer u de lease maakt. U hebt de LeaseId niet nodig om de lease te verbreken.

In het volgende voorbeeld ziet u hoe u de lease kunt verbreken voor het bestand dat wordt aangegeven in oorzaak 2 (dit voorbeeld gaat verder met de PowerShell-variabelen uit oorzaak 2):

$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. Om dit te bevestigen, controleert u kernellogboekberichten (dmesg) en toont dmesg een logboekvermelding, 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 notatie, zoals het gebruik van afbreekstreepjes of dubbele punten in plaats van punten. Zie 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 optie voor de momentopname mount wordt doorgegeven vanaf @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, namelijk @GMT-year.month.day-hour.minutes.seconds. Zie Momentopname van een bestandsshare koppelen voor meer informatie.

'Koppelingsfout(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. Om dit te bevestigen, controleert u kernellogboekberichten (dmesg) en toont dmesg een logboekvermelding 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 open ingangen die zijn toegestaan voor een bestand of map op de Azure-bestandsshare. Zie Azure Files schaaldoelen voor meer informatie.

Oplossing

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

Als u geopende ingangen voor een bestandsshare, map of bestand wilt weergeven, gebruikt u de PowerShell-cmdlet Get-AzStorageFileHandle .

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

Opmerking

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

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

Oorzaak

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

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

Oplossing

Houd een groot aantal ingangen niet in de cache. Sluit de grepen 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 implementatie van een virtueel bureaublad of andere workloads die ingangen openen voor bestanden, mappen en/of de hoofdmap, bereikt u mogelijk de maximale schaal voor gelijktijdige open ingangen. Gebruik in dit geval een extra Azure-bestandsshare en distribueer de containers of installatiekopieën tussen de shares.

Fout 'U kopieert een bestand naar een bestemming die geen ondersteuning biedt voor versleuteling'

Wanneer een bestand via het netwerk wordt gekopieerd, wordt het bestand ontsleuteld op de broncomputer, verzonden in tekst zonder opmaak en opnieuw versleuteld op de bestemming. 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 ondersteuning biedt voor versleuteling'.

Oorzaak

Dit probleem kan optreden als u Efs (Encrypting File System) 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. Gebruik een 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
    • Name = CopyFileAllowDecryptedRemoteDestination
    • Waarde = 1

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

Fout ConditionHeadersNotSupported from a Web Application using Azure Files from Browser

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

Schermopname van het foutbericht ConditionHeadersNotSupported.

Oorzaak

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

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 geen cache naar no-cache, no-store, must-revalidate. Dit kan worden bereikt met behulp van Azure Storage Explorer.

Screeshot waarin de eigenschap CacheControl wordt weergegeven.

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 Feedback-community van Azure.