Problemen Azure Files in Windows (SMB) oplossen

In dit artikel worden veelvoorkomende problemen beschreven die betrekking hebben op Microsoft Azure Files wanneer u verbinding maakt Windows clients. Het biedt ook mogelijke oorzaken en oplossingen voor deze problemen. Naast de stappen voor probleemoplossing in dit artikel kunt u ook AzFileDiagnostics gebruiken om ervoor te zorgen dat de Windows clientomgeving de juiste vereisten heeft. AzFileDiagnostics automatiseert de detectie van de meeste symptomen die in dit artikel worden genoemd en helpt bij het instellen van uw omgeving voor optimale prestaties.

Van toepassing op

Bestands sharetype	SMB	NFS
Standaardbestands shares (GPv2), LRS/ZRS
Standaardbestands shares (GPv2), GRS/GZRS
Premium (FileStorage), LRS/ZRS

Fout 5 bij het toevoegen van een Azure-bestands share

Wanneer u probeert een bestands share te maken, wordt mogelijk de volgende fout weergegeven:

• 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 datacenter als waar de Azure-bestandsshares zich bevinden. Niet-versleutelde verbindingen binnen hetzelfde datacenter kunnen ook worden geblokkeerd als de instelling Veilige overdracht vereist is ingeschakeld in het opslagaccount. Er wordt alleen een versleuteld communicatiekanaal geboden als het clientbesturingssysteem van de gebruiker ondersteuning biedt voor SMB-versleuteling.

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

Oplossing voor oorzaak 1

1. Verbinding maken vanaf een client die ondersteuning biedt voor SMB-versleuteling (Windows 8, Windows Server 2012 of hoger) of maak verbinding vanaf een virtuele machine in hetzelfde datacenter als het Azure-opslagaccount dat wordt gebruikt voor de Azure-bestands share.
2. Controleer of de instelling Veilige overdracht vereist is uitgeschakeld voor het opslagaccount als de client geen ondersteuning biedt voor SMB-versleuteling.

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

Als er regels voor het VNET (virtueel netwerk) of de firewall zijn geconfigureerd in het opslagaccount, wordt netwerkverkeer de toegang geweigerd, tenzij het IP-adres van de client of het virtuele netwerk toegang heeft.

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 het gebruik van verificatie op basis van identiteit

Als gebruikers toegang hebben tot de Azure-bestands share via Active Directory (AD) of Azure Active Directory Domain Services-verificatie (Azure AD DS), mislukt de toegang tot de bestands share met de fout 'Toegang wordt geweigerd' als de machtigingen op shareniveau onjuist zijn.

Oplossing voor oorzaak 3

Controleer of de machtigingen correct zijn geconfigureerd:

• Active Directory (AD) zie Machtigingen op shareniveau toewijzen aan een identiteit.

  Machtigingstoewijzingen op shareniveau worden ondersteund voor groepen en gebruikers die zijn gesynchroniseerd vanuit Active Directory (AD) naar Azure Active Directory (Azure AD) met behulp van Azure AD Verbinding maken. Controleer of groepen en gebruikers aan toegewezen machtigingen op shareniveau niet-ondersteunde 'alleen-cloud'-groepen zijn.

• Azure Active Directory Domain Services (Azure AD DS) zie Toegangsmachtigingen toewijzen aan een identiteit.

Fout 53, fout 67 of fout 87 bij het toevoegen of ontkoppelen van een Azure-bestands share

Wanneer u probeert een bestands share te maken vanaf on-premises of vanuit een ander datacenter, kunnen de volgende fouten optreden:

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

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

Als u de cmdlet wilt gebruiken, moet Azure PowerShell module zijn geïnstalleerd. Zie De Test-NetConnection module Azure PowerShell 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, run Login-AzAccount 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

Oplossing voor oorzaak 1

Oplossing 1: Azure File Sync gebruiken

Azure File Sync kunt uw on-premises Windows Server transformeren naar een snelle cache van uw Azure-bestands share. U kunt elk protocol dat beschikbaar is in Windows Server, inclusief SMB, NFS en FTPS, gebruiken voor lokale toegang tot uw gegevens. Azure File Sync werkt via poort 443 en kan daarom worden gebruikt als tijdelijke oplossing voor toegang tot Azure Files vanaf clients waarbij poort 445 is geblokkeerd. Meer informatie over het instellen Azure File Sync.

Oplossing 2: VPN gebruiken

Door een VPN in te stellen voor uw Storage account, loopt het verkeer via een beveiligde tunnel in plaats van via internet. Volg de instructies voor het instellen van VPN om toegang te krijgen tot Azure Files vanuit Windows.

Oplossing 3: Poort 445 deblokkeren met behulp van uw internetprovider/IT-beheerder

Werk samen met uw IT-afdeling of ISP om poort 445 uitgaand naar Azure IP-adresbereiken te openen.

Oplossing 4: Hulpprogramma’s op basis van REST API gebruiken, zoals Storage Explorer/PowerShell

Azure Files biedt naast SMB ook ondersteuning voor REST. REST-toegang werkt via poort 443 (standaard TCP). Er zijn verschillende hulpprogramma's die zijn geschreven met REST API die een uitgebreide UI-ervaring bieden. Storage Explorer is er 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 gebruikersaccounts REST API.

Oorzaak 2: NTLMv1 is ingeschakeld

Systeemfout 53 of systeemfout 87 kan 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.

Controleer of de volgende registersubsleutel niet is ingesteld op een waarde lager dan 3 om te bepalen of dit de oorzaak van de fout is:

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

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

Oorzaak

Fout 1816 teert wanneer u de bovengrens bereikt van gelijktijdige geopende grepen die zijn toegestaan voor een bestand of map op de Azure-bestands share. Zie Azure Files-schaalbaarheidsdoelen voor meer informatie.

Oplossing

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

Als u geopende grepen voor een bestands share, map of bestand wilt weergeven, gebruikt u de PowerShell-cmdlet Get-AzStorageFileHandle.

Als u geopende grepen voor een bestands share, map of bestand wilt sluiten, gebruikt u de PowerShell-cmdlet Close-AzStorageFileHandle.

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

Wanneer u een Azure-bestands share probeert te openen of verwijderen in de portal, wordt mogelijk de volgende fout weergegeven:

Geen toegang
Foutcode: 403

Oorzaak 1: Regels voor virtuele netwerken of firewalls 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 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 2: Uw gebruikersaccount heeft geen toegang tot het opslagaccount

Oplossing voor oorzaak 2

Blader naar het opslagaccount waar de Azure-bestands share zich bevindt, klik op 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.

Kan een Azure-bestands share (of momentopnamen van share) niet wijzigen of verwijderen vanwege vergrendelingen of leases

Azure Files twee manieren om onbedoeld wijzigen of verwijderen van Azure-bestands shares en momentopnamen van shares te voorkomen:

• Storage accountresource wordt vergrendeld: alle Azure-resources, inclusief het opslagaccount, ondersteunen resourcevergrendelingen. Vergrendelingen kunnen door een beheerder op het opslagaccount worden gezet of door services met toegevoegde waarde, zoals Azure Backup. Er bestaan twee variaties van resourcevergrendelingen: wijzigen, waardoor alle wijzigingen in het opslagaccount en de resources worden voorkomen, en worden verwijderd, waardoor alleen het opslagaccount en de resources worden verwijderd. Bij het wijzigen of verwijderen van shares via de resourceprovider worden resourcevergrendelingen afgedwongen op Azure-bestands Microsoft.Storage shares en momentopnamen van shares. De meeste portalbewerkingen, Azure PowerShell cmdlets voor Azure Files met in de naam (dat wil zeggen ), en Azure CLI-opdrachten in de opdrachtgroep (dat wil zeggen ) gebruiken de Rm Get-AzRmStorageShare share-rm az storage share-rm list Microsoft.Storage resourceprovider. Sommige hulpprogramma's, zoals Storage Explorer, verouderde Azure Files PowerShell-beheer-cmdlets zonder in de naam (dat wil zeggen ), en verouderde Azure Files CLI-opdrachten onder de opdrachtgroep (dat wil zeggen ) gebruiken verouderde API's in de FileREST-API die de resourceprovider en Rm Get-AzStorageShare share az storage share list Microsoft.Storage resourcevergrendelingen omzeilen. Zie besturingsvlak in Azure Files voor meer informatie over verouderde beheer-API'sdie beschikbaar worden gemaakt in de FileREST-API.

• Share-/share-leases voor momentopnamen: Share-leases zijn een soort eigen vergrendeling voor Azure-bestands shares en momentopnamen van bestandsdelingen. Leases kunnen worden gemaakt op afzonderlijke Azure-bestands shares of momentopnamen van bestands share door beheerders door de API aan te roepen via een script of door services met toegevoegde waarde, zoals Azure Backup. Wanneer een lease wordt gemaakt op een Azure-bestands share of momentopname van een bestands share, kan het wijzigen of verwijderen van de momentopname van de bestands share/share worden uitgevoerd met de lease-id. Gebruikers kunnen de lease ook vrijgeven voordat ze bewerkingen wijzigen, waarvoor de lease-id is vereist, of de lease breken, waarvoor de lease-id niet is vereist. Zie lease-share voor meer informatie over share-leases.

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

Als u het volgende script wilt uitvoeren, moet u de preview-versie 3.10.1 van de Azure Storage PowerShell-module installeren.

# 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

Een van de belangrijkste doeleinden van een bestands share is dat meerdere gebruikers en toepassingen tegelijkertijd kunnen communiceren met bestanden en mappen in de share. Om te helpen bij deze interactie bieden bestands shares verschillende manieren om toegang tot bestanden en mappen te bemiddelen.

Wanneer u een bestand opent vanuit een gemonteerde Azure-bestands share via SMB, vraagt uw toepassing/besturingssysteem een bestandsing handle aan. Dit is een verwijzing naar het bestand. Uw toepassing geeft onder andere een modus voor het delen van bestanden op wanneer een bestandsingingsing wordt gevraagd, waarmee het niveau van exclusiviteit wordt opgegeven voor uw toegang tot het bestand dat wordt afgedwongen door Azure Files:

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

Hoewel het FileREST-protocol een staatloos protocol is, heeft het geen concept van bestandsing handles, maar het biedt wel een vergelijkbaar mechanisme voor het mediaaleren van toegang tot bestanden en mappen die uw script, toepassing of service kan gebruiken: bestandsleases. Wanneer een bestand wordt geleased, wordt dit beschouwd als een bestandsingingsingal met de modus voor bestandsdeling van None .

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

• Het proces kan het bestand niet openen omdat het door een ander proces wordt gebruikt.
• 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 is gemarkeerd voor verwijdering door een SMB-client.

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

Oorzaak 1

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

Als alle SMB-clients hun geopende grepen in een bestand/map hebben gesloten en het probleem zich blijft voordoen, kunt u een bestandsing handle geforceerde sluiten.

Oplossing 1

Gebruik de PowerShell-cmdlet Close-AzStorageFileHandle om af te dwingen dat een bestandsing handle wordt gesloten.

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, zodat u , , en vervangt door de juiste <resource-group> <storage-account> waarden voor uw <file-share> <path-to-file> 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 onderbreken.

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

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

Bestanden worden langzaam gekopieerd van en naar Azure Files in Windows

Mogelijk ziet u trage prestaties wanneer u bestanden probeert over te dragen naar de Azure File-service.

• Als u geen specifieke minimale I/O-grootte vereist, wordt u aangeraden 1 MiB als de I/O-grootte te gebruiken voor optimale prestaties.
• Als u weet wat de uiteindelijke grootte is van een bestand dat u uitbreidt met schrijf- en schrijfproblemen en uw software geen compatibiliteitsproblemen heeft wanneer de niet-geschreven staart op het bestand nullen bevat, stelt u de bestandsgrootte vooraf in in plaats van elke schrijf-uitbreiding een uitbreiding van de schrijf-schrijven te maken.
• Gebruik de juiste kopieermethode:
  • Gebruik AzCopy voor elke overdracht tussen twee bestands shares.
  • Gebruik Robocopy tussen bestands shares op een on-premises computer.

Overwegingen voor Windows 8.1 of Windows Server 2012 R2

Zorg ervoor dat voor clients met Windows 8.1 of Windows Server 2012 R2 de hotfix KB3114025 is geïnstalleerd. Deze hotfix verbetert de prestaties van het maken en sluiten van grepen.

U kunt het volgende script uitvoeren om te controleren of de hotfix is geïnstalleerd:

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

Als hotfix is geïnstalleerd, wordt de volgende uitvoer weergegeven:

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

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

Als u een Azure-bestands share als beheerder toekent met behulp van net use, lijkt de share te ontbreken.

Oorzaak

Standaard wordt Windows Bestandenverkenner niet uitgevoerd als beheerder. Als u net use vanaf een opdrachtprompt voor beheerders uit te voeren, kunt u het netwerkstation als beheerder. Omdat de stations die zijn toegeschreven op de gebruiker zijn gericht, worden de stations niet weergegeven in het gebruikersaccount dat is aangemeld als ze zijn bevestigd onder een ander gebruikersaccount.

Oplossing

De share vanaf een niet-beheerder opdrachtregel. U kunt ook dit TechNet-onderwerp volgen om de registerwaarde EnableLinkedConnections te configureren.

De opdracht Net use mislukt als het opslagaccount een slash bevat

Oorzaak

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

Oplossing

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

• 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 kunnen oplossen, tenzij de slash het eerste teken is. Als dat zo is, gebruikt u de interactieve modus en voert u uw wachtwoord afzonderlijk in of gebruikt u uw sleutels opnieuw om een sleutel op te halen die niet met een slash begint.

Toepassing of service heeft geen toegang tot een Azure Files station

Oorzaak

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

Oplossing

Gebruik een van de volgende oplossingen:

• Bevestig 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 opdracht net use.

• Gebruik de opdracht cmdkey om de referenties toe te voegen aan Aanmeldingsgegevensbeheer. Voer dit 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 gebruik te maken van een kaartstationletter. Sommige toepassingen maken mogelijk niet opnieuw verbinding met de letter van het station, zodat het volledige UNC-pad betrouwbaarder kan zijn.

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

Nadat u deze instructies hebt gevolgd, ontvangt u mogelijk het volgende foutbericht wanneer u net use voor het systeem-/netwerkserviceaccount hebt uitgevoerd: 'Systeemfout 1312 is opgetreden. Er bestaat geen opgegeven aanmeldingssessie. Deze is mogelijk al beëindigd. Als dit het geval is, moet u ervoor zorgen dat de gebruikersnaam die wordt doorgegeven aan net use domeingegevens bevat (bijvoorbeeld[naam van opslagaccount].file.core.windows.net).

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 als tekst zonder tekst 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. De Azure Files echter geen ondersteuning voor NTFS EFS.

Tijdelijke oplossing

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

• Gebruik de kopiëren /d opdracht. 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

Let erop dat het instellen van de registersleutel van invloed is op alle kopieerbewerkingen die naar netwerk shares worden gemaakt.

Langzame enumeratie van bestanden en mappen

Oorzaak

Dit probleem kan optreden als er onvoldoende cache op de clientmachine is voor grote directories.

Oplossing

U kunt dit probleem oplossen door de registerwaarde DirectoryCacheEntrySizeMax aan te passen zodat grotere mapvermeldingen op de clientmachine kunnen worden opgeslagen in de caching:

• Locatie: HKLM\System\CCS\Services\Lanmanworkstation\Parameters
• Waardemane: DirectoryCacheEntrySizeMax
• Waardetype:DWORD

U kunt deze bijvoorbeeld instellen op 0x100000 en zien of de prestaties beter worden.

Fout AadDsTenantNotFound bij het inschakelen van Azure Active Directory Domain Service-verificatie (Azure AD DS) voor Azure Files 'Kan actieve tenants niet vinden met tenant-id aad-tenant-id'

Oorzaak

Fout AadDsTenantNotFound teert wanneer u Azure Active Directory Domain Services-verificatie (Azure AD DS) wilt inschakelen op Azure Files in een opslagaccount waarin Azure AD Domain Service (Azure AD DS) niet is gemaakt in de Azure AD-tenant van het gekoppelde abonnement.

Oplossing

Schakel Azure AD DS voor de Azure AD-tenant van het abonnement waarmee uw opslagaccount is geïmplementeerd. U hebt beheerdersbevoegdheden van de Azure AD-tenant nodig om een beheerd domein te maken. Als u niet de beheerder van de Azure AD-tenant bent, neem dan contact op met de beheerder en volg de stapsgewijs richtlijnen voor het maken en configureren van een Azure Active Directory Domain Services beheerd domein.

Fout ConditionHeadersNotSupported vanuit een webtoepassing met behulp van Azure Files vanuit de browser

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

Oorzaak

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

Tijdelijke oplossing

Wanneer een nieuw bestand wordt geüpload, is de eigenschap Cache-Control standaard ingesteld op ' no-cache '. Om ervoor te zorgen dat de toepassing het bestand elke keer kan aanvragen, moet de eigenschap Cache-Control van het bestand worden bijgewerkt van ' no-cache ' in ' no-cache ', no-Store, moet opnieuw worden gevalideerd '. Dit kan worden bereikt met behulp van Azure Storage Explorer.

Kan geen Azure Files met AD-referenties

Stappen voor zelfdiagnose

Zorg er eerst voor dat u alle vier de stappen hebt gevolgd om ad Azure Files verificatie in te schakelen.

Probeer ten tweede de Azure-bestands share te mounten met de opslagaccountsleutel. Als het niet lukt om de client te bevestigen, downloadt u AzFileDiagnostics.ps1 om de clientomgeving te valideren, de incompatibele clientconfiguratie te detecteren die toegangsfout zou veroorzaken voor Azure Files, geeft u prescriptieve richtlijnen voor zelffixing en verzamelt u de diagnostische traceringen.

Ten derde kunt u de cmdlet Debug-AzStorageAccountAuth uitvoeren om een set basiscontroles uit te voeren op uw AD-configuratie met de aangemelde AD-gebruiker. Deze cmdlet wordt ondersteund met versie AzFilesHybrid v 0.1.2 en hoger. U moet deze cmdlet uitvoeren met een AD-gebruiker die de machtiging Eigenaar heeft voor het doelopslagaccount.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose

De cmdlet voert de onderstaande controles op volgorde uit en biedt richtlijnen voor fouten:

1. CheckADObjectPasswordIsCorrect: zorg ervoor dat het wachtwoord dat is geconfigureerd voor de AD-identiteit die het opslagaccount vertegenwoordigt, overeenkomt met dat van de kerb1- of kerb2-sleutel van het opslagaccount. Als het wachtwoord onjuist is, kunt u Update-AzStorageAccountADObjectPassword uitvoeren om het wachtwoord opnieuw in te stellen.
2. CheckADObject: controleer of er een object in de Active Directory is dat het opslagaccount vertegenwoordigt en de juiste SPN (service-principal name) heeft. Als de SPN niet juist is ingesteld, moet u de Set-AD-cmdlet uitvoeren die is geretourneerd in de cmdlet voor foutopsporing om de SPN te configureren.
3. CheckDomainJoined: controleer of de clientmachine lid is van een domein in AD. Als uw computer geen lid is van een domein aan AD, raadpleegt u dit artikel voor instructies voor domein-join.
4. CheckPort445Connectivity: Controleer of poort 445 is geopend voor de SMB-verbinding. Als de vereiste poort niet is geopend, raadpleegt u het hulpprogramma voor probleemoplossingAzFileDiagnostics.ps1verbindingsproblemen met Azure Files.
5. CheckSidHasAadUser: controleer of de aangemelde AD-gebruiker is gesynchroniseerd met Azure AD. Als u wilt controleren of een specifieke AD-gebruiker is gesynchroniseerd met Azure AD, kunt u de -UserName en -Domain opgeven in de invoerparameters.
6. CheckGetKerberosTicket: probeer een Kerberos-ticket te verkrijgen om verbinding te maken met het opslagaccount. Als er geen geldig Kerberos-token is, voer dan de cmdlet klist get cifs/storage-account-name.file.core.windows.net uit en bekijk de foutcode om de fout bij het ophalen van het ticket op te halen.
7. CheckStorageAccountDomainJoined: Controleer of de AD-verificatie is ingeschakeld en of de AD-eigenschappen van het account zijn ingevuld. Als dat niet het beste is, raadpleegt u deze instructie om verificatie AD DS in te schakelen op Azure Files.
8. CheckUserRbacAssignment: controleer of de AD-gebruiker de juiste RBAC-roltoewijzing heeft om machtigingen op shareniveau te bieden voor toegang tot Azure Files. Zo niet, raadpleegt u de instructie hier om de machtiging op shareniveau te configureren. (Ondersteund op AzFilesHybrid v0.2.3+ versie)
9. CheckUserFileAccess: controleer of de AD-gebruiker de juiste machtigingen voor directory's/bestanden (Windows ACL's) heeft voor toegang tot Azure Files. Zo niet, raadpleegt u de instructie hier om de machtiging op map-/bestandsniveau te configureren. (Ondersteund op AzFilesHybrid v0.2.3+ versie)

Kan geen machtigingen op map-/bestandsniveau (Windows ACL's) configureren met Windows Bestandenverkenner

Symptoom

U kunt een van beide symptomen ervaren die hieronder worden beschreven bij het configureren Windows ACL's met Verkenner op een aaneengestelde bestands share:

• Nadat u onder het tabblad Beveiliging op De machtigingsmachtiging hebt geklikt, wordt de wizard Machtiging niet geladen.
• Wanneer u een nieuwe gebruiker of groep selecteert, wordt op de domeinlocatie niet het juiste AD DS weergegeven.

Oplossing

U wordt aangeraden het hulpprogramma icacls te gebruiken om machtigingen op map-/bestandsniveau te configureren als tijdelijke oplossing.

Fouten bij het uitvoeren Join-AzStorageAccountForAuth cmdlet

Fout: 'De adreslijstservice kan geen relatieve id toewijzen'

Deze fout kan optreden als een domeincontroller met de FSMO-rol RID-master niet beschikbaar is of is verwijderd uit het domein en is hersteld vanuit de back-up. Controleer of alle domeincontrollers actief en beschikbaar zijn.

Fout: ‘Kan de positieparameters niet binden, omdat er geen namen zijn opgegeven’

Deze fout wordt waarschijnlijk veroorzaakt door een syntaxisfout in de opdracht Join-AzStorageAccountforAuth. Controleer de opdracht op spelfouten of syntaxisfouten en controleer of de nieuwste versie van de AzFilesHybrid-module https://github.com/Azure-Samples/azure-files-samples/releases) ( is geïnstalleerd.

Azure Files on-premises AD DS ondersteuning voor AES 256 Kerberos-versleuteling

We hebben ondersteuning voor AES 256 Kerberos-versleuteling geïntroduceerd voor Azure Files on-AD DS-verificatie met AzFilesHybrid-module v0.2.2. Als u AD DS hebt ingeschakeld met een moduleversie lager dan v0.2.2, moet u de meest recente AzFilesHybrid-module (v0.2.2+) downloaden en de onderstaande PowerShell uitvoeren. Als u de verificatie AD DS uw opslagaccount nog niet hebt ingeschakeld, kunt u deze richtlijnen volgen voor inschakelen.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

Hebt u hulp nodig? Neem contact op met ondersteuning.

Als u nog steeds hulp nodig hebt, kunt u contact opnemen met de ondersteuning om uw probleem snel op te lossen.