Dela via

Felsöka anslutning och åtkomstproblem för Azure Files (SMB)

  • Artikel

Den här artikeln innehåller vanliga problem som kan uppstå när du försöker ansluta till och få åtkomst till Azure-filresurser (Server Message Block) från Windows- eller Linux-klienter. Det ger också möjliga orsaker och lösningar på dessa problem.

Kommentar

Var den här artikeln till hjälp? Dina indata är viktiga för oss. Använd feedbackknappen på den här sidan för att informera oss om hur bra den här artikeln fungerade för dig eller hur vi kan förbättra den.

Viktigt!

Den här artikeln gäller endast för SMB-resurser. Mer information om NFS-resurser (Network File System) finns i Felsöka Azure NFS-filresurser.

Gäller för

Typ av filresurs SMB NFS
Standardfilresurser (GPv2), LRS/ZRS
Standardfilresurser (GPv2), GRS/GZRS
Premiumfilresurser (FileStorage), LRS/ZRS

Det går inte att ansluta till eller montera en Azure-filresurs

Välj fliken Windows eller Linux beroende på vilket klientoperativsystem du använder för att få åtkomst till Azure-filresurser.

När du försöker ansluta till en Azure-fildelning i Windows kan du få följande felmeddelanden.

Fel 5 när du monterar en Azure-filresurs

  • Systemfel 5 har uppstått. Åtkomst nekas.

Orsak 1: Okrypterad kommunikationskanal

Av säkerhetsskäl blockeras anslutningar till Azure-filresurser om kommunikationskanalen inte är krypterad och om anslutningsförsöket inte görs från samma datacenter där Azure-fildelningarna finns. Om inställningen Säker överföring krävs är aktiverad på lagringskontot blockeras även okrypterade anslutningar inom samma datacenter. En krypterad kommunikationskanal tillhandahålls endast om slutanvändarens klientoperativsystem stöder SMB-kryptering.

Windows 8, Windows Server 2012 och senare versioner av varje system förhandlar om begäranden som innehåller SMB 3.x, som stöder kryptering.

Lösning för orsak 1

  1. Anslut från en klient som stöder SMB-kryptering (Windows 8/Windows Server 2012 eller senare).
  2. Anslut från en virtuell dator i samma datacenter som Azure-lagringskontot som används för Azure-fildelningen.
  3. Verifiera att inställningen Säker överföring krävs är inaktiverad på lagringskontot om klienten inte stöder SMB-kryptering.

Orsak 2: Virtuellt nätverk eller brandväggsregler har aktiverats för lagringskontot

Nätverkstrafik tillåts inte om ett virtuellt nätverk (VNET) och brandväggsregler har konfigurerats på lagringskontot, såvida inte åtkomst tillåts för klientens IP-adress eller virtuella nätverk.

Lösning för orsak 2

Kontrollera att det virtuella nätverket och brandväggsreglerna har konfigurerats korrekt på lagringskontot. Om du vill ta reda på om det virtuella nätverket eller brandväggsreglerna orsakar problemet kan du tillfälligt ändra inställningen på lagringskontot för att tillåta åtkomst från alla nätverk. Mer information finns i Konfigurera Azure Storage-brandväggar och virtuella nätverk.

Orsak 3: Behörigheterna på resursnivå är felaktiga när du använder identitetsbaserad autentisering

Om användarna kommer åt Azure-filresursen med identitetsbaserad autentisering misslyckas åtkomsten till filresursen med felet "Åtkomst nekas" om behörigheter på resursnivå är felaktiga.

Lösning för orsak 3

Kontrollera att behörigheter på resursnivå har konfigurerats korrekt. Se Tilldela behörigheter på resursnivå. Behörighetstilldelningar på resursnivå stöds för grupper och användare som har synkroniserats från AD DS till Microsoft Entra-ID med Microsoft Entra Connect Sync eller Microsoft Entra Connect-molnsynkronisering. Bekräfta att grupper och användare som tilldelas behörigheter på resursnivå inte stöds "endast molngrupper".

Fel 53, fel 67 eller fel 87 när du monterar eller demonterar en Azure-filresurs

När du försöker montera en filresurs från en lokal plats eller ett annat datacenter kan följande fel uppstå:

  • Systemfel 53 har uppstått. Det gick inte att hitta nätverkssökvägen.
  • Systemfel 67 har uppstått. Nätverksnamnet kan inte hittas.
  • Systemfel 87 har uppstått. Parametern är felaktig.

Orsak 1: Port 445 är blockerad

Systemfel 53 eller systemfel 67 kan inträffa om utgående kommunikation via port 445 till ett Azure Files-datacenter blockeras. En översikt över Internetleverantörer som tillåter och inte tillåter åtkomst från port 445 finns på TechNet.

Du kan kontrollera om din brandvägg eller Internetleverantör blockerar port 445 med verktyget AzFileDiagnostics eller cmdleten Test-NetConnection.

Om du vill använda Test-NetConnection cmdleten måste Azure PowerShell-modulen installeras. Se Installera Azure PowerShell-modulen för mer information. Kom ihåg att ersätta <your-storage-account-name> och <your-resource-group-name> med gällande namn för ditt lagringskonto.

$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

Om en anslutning upprättades bör du se följande utdata:

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

Kommentar

Det här kommandot returnerar lagringskontots aktuella IP-adress. Det är inte säkert att IP-adressen förblir densamma, och den kan ändras när som helst. Hårdkoda inte den här IP-adressen i några skript eller i en brandväggskonfiguration.

Lösningar för orsak 1

Lösning 1 – Använd Azure File Sync som en QUIC-slutpunkt Du kan använda Azure File Sync som en lösning för att komma åt Azure Files från klienter som har port 445 blockerad. Även om Azure Files inte har direkt stöd för SMB via QUIC stöder Windows Server 2022 Azure Edition QUIC-protokollet. Du kan skapa en enkel cache med dina Azure-filresurser på en virtuell Windows Server 2022 Azure Edition-dator med Azure File Sync. Denna konfiguration använder port 443, som är allmänt öppen utgående för att stödja HTTPS, i stället för port 445. Mer information om detta alternativ finns i SMB över QUIC med Azure File Sync.

Lösning 2 – Använd VPN eller ExpressRoute Genom att konfigurera ett virtuellt privat nätverk (VPN) eller ExpressRoute lokalt till ditt Azure Storage-konto, med Azure Files exponerat i ditt interna nätverk med privata slutpunkter, går trafiken via en säker tunnel i stället för via Internet. Följ anvisningarna för att konfigurera ett VPN för åtkomst till Azure Files från Windows.

Lösning 3 – Avblockera port 445 med hjälp av internetleverantören/IT-administratören Arbeta med IT-avdelningen eller Internetleverantören för att öppna port 445 utgående till Azure IP-intervall.

Lösning 4 – Använd REST API-baserade verktyg som Storage Explorer eller PowerShell Azure Files stöder även REST utöver SMB. REST-åtkomst fungerar via port 443 (standard-TCP). Det finns olika verktyg som skrivs med hjälp av REST API som möjliggör en omfattande användargränssnittsupplevelse. Storage Explorer är ett av dem. Ladda ned och installera Storage Explorer och anslut till din filresurs som backas av Azure Files. Du kan också använda PowerShell som även använder REST API.

Orsak 2: NTLMv1 är aktiverat

Systemfel 53 eller systemfel 87 kan inträffa om NTLMv1-kommunikation är aktiverad på klienten. Azure Files stöder endast NTLMv2-autentisering. När NTLMv1 är aktiverad är klienten mindre säker. Därför blockeras kommunikation för Azure Files.

Kontrollera om det här är orsaken till felet genom att kontrollera att följande registerundernyckel inte är inställd på ett värde som är mindre än 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

Mer information finns i ämnet LmCompatibilityLevel på TechNet.

Lösning för orsak 2

Återställ värdet LmCompatibilityLevel till standardvärdet 3 i följande registerundernyckel:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Misslyckades med felkoden 0x800704b3

När du försöker montera en Azure-filresurs får du följande fel:

Felkod: 0x800704b3
Symboliskt namn: ERROR_NO_NET_OR_BAD_PATH
Felbeskrivning: Nätverkssökvägen har antingen skrivits felaktigt, finns inte eller så är nätverksprovidern inte tillgänglig för närvarande. Försök att skriva om sökvägen eller kontakta nätverksadministratören.

Orsak

Det här felet kan inträffa om några centrala Windows-nätverksrelaterade tjänster inaktiveras eftersom alla tjänster som uttryckligen är beroende av dessa nätverkstjänster inte startar.

Lösning

Kontrollera om någon av följande tjänster är i tillståndet Stoppad på den virtuella Windows-datorn:

  • Nätverksanslutningar
  • Tjänst för nätverkslista
  • Nätverksplatsmedvetenhet
  • Nätverkslagringsgränssnittstjänst
  • DHCP-klient
  • TCP/IP NetBIOS-hjälp
  • Arbetsstation

Om du hittar några startar du tjänsterna och försöker montera Azure-filresursen igen.

Programmet eller tjänsten kan inte komma åt en monterad Azure Files-enhet

Orsak

Enheter monteras per användare. Om programmet eller tjänsten körs under ett annat användarkonto än det som monterade enheten visas inte enheten.

Lösning

Använd någon av följande lösningar:

  • Montera enheten från samma användarkonto som innehåller programmet. Du kan använda ett verktyg som PsExec.

  • Skicka lagringskontots namn och nyckel i parametrarna användarnamn och lösenord för net use kommandot.

  • cmdkey Använd kommandot för att lägga till autentiseringsuppgifterna i Credential Manager. Utför den här åtgärden från en kommandorad under tjänstkontokontexten, antingen via en interaktiv inloggning eller med hjälp runasav .

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

  • Mappa resursen direkt utan att använda en mappad enhetsbeteckning. Vissa program kanske inte återansluter till enhetsbeteckningen korrekt, så det kan vara mer tillförlitligt att använda den fullständiga UNC-sökvägen:

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

När du har följt de här anvisningarna kan du få följande felmeddelande när du kör net use för system-/nätverkstjänstkontot: "Systemfel 1312 har inträffat. En angiven inloggningssession finns inte. Det kan redan ha avslutats." Om det här felet visas kontrollerar du att användarnamnet som skickas till net use innehåller domäninformation (till exempel: [storage account name].file.core.windows.net).

Ingen mapp med en enhetsbeteckning i "Min dator" eller "Den här datorn"

Om du mappar en Azure-filresurs som administratör med hjälp net use av kommandot verkar resursen saknas.

Orsak

Windows Utforskaren körs som standard inte som administratör. Om du kör net use från en administrativ kommandotolk mappar du nätverksenheten som administratör. Eftersom mappade enheter är användarcentrerade visar inte användarkontot som är inloggade enheterna om de monteras under ett annat användarkonto.

Lösning

Montera resursen från en kommandorad som inte är administratör. Du kan också följa det här TechNet-avsnittet för att konfigurera EnableLinkedConnections registervärdet.

Kommandot "net use" misslyckas om lagringskontot innehåller ett snedstreck

Orsak

Kommandot net use tolkar ett snedstreck (/) som ett kommandoradsalternativ. Om ditt användarkontonamn börjar med ett snedstreck misslyckas enhetsmappningen.

Lösning

Du kan använda något av följande steg för att lösa problemet:

  • Kör följande PowerShell-kommando:

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

    Från en batchfil kan du köra kommandot på det här sättet:

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

  • Placera dubbla citattecken runt nyckeln för att kringgå det här problemet – såvida inte snedstrecket är det första tecknet. Om så är fallet använder du antingen det interaktiva läget och anger lösenordet separat eller återskapar dina nycklar för att hämta en nyckel som inte börjar med ett snedstreck.

Kommandot New-PSDrive misslyckas med felet "nätverksresurstypen är inte korrekt"

Orsak

Du kan se det här felmeddelandet om filresursen inte är tillgänglig. Till exempel blockeras port 445 eller så finns det ett DNS-matchningsproblem.

Lösning

Kontrollera att port 445 är öppen och kontrollera DNS-matchning och anslutning till filresursen.

Det går inte att komma åt, ändra eller ta bort en Azure-filresurs (eller resursögonblicksbild)

Felet "Användarnamnet eller lösenordet är felaktigt" efter en kundinitierad redundansväxling

I ett kundinitierat redundansscenario med geo-redundanta lagringskonton behålls inte filhandtag och lån vid redundansväxling. Klienter måste demontera och montera om filresurserna.

Felet "Ingen åtkomst" när du försöker komma åt eller ta bort en Azure-filresurs

När du försöker komma åt eller ta bort en Azure-filresurs med hjälp av Azure Portal kan du få följande fel:

Felkod utan åtkomst: 403

Orsak 1: Virtuella nätverk eller brandväggsregler är aktiverade på lagringskontot

Lösning för orsak 1

Kontrollera att det virtuella nätverket och brandväggsreglerna har konfigurerats korrekt på lagringskontot. Om du vill testa om det virtuella nätverket eller brandväggsreglerna orsakar problemet ändrar du tillfälligt inställningen för lagringskontot till Tillåt åtkomst från alla nätverk. Mer information finns i Konfigurera Azure Storage-brandväggar och virtuella nätverk.

Orsak 2: Ditt användarkonto har inte åtkomst till lagringskontot

Lösning för orsak 2

Bläddra till lagringskontot där Azure-filresursen finns, välj Åtkomstkontroll (IAM) och kontrollera att ditt användarkonto har åtkomst till lagringskontot. Mer information finns i Så här skyddar du ditt lagringskonto med rollbaserad åtkomstkontroll i Azure (Azure RBAC).

Fillås och lån

Om du inte kan ändra eller ta bort en Azure-filresurs eller ögonblicksbild kan det bero på fillås eller lån. Azure Files innehåller två sätt att förhindra oavsiktlig ändring eller borttagning av Azure-filresurser och resursögonblicksbilder:

  • Lagringskontoresurslås: Alla Azure-resurser, inklusive lagringskontot, stöder resurslås. Lås kan placeras på lagringskontot av en administratör eller av tjänster som Azure Backup. Det finns två varianter av resurslås: ändra, vilket förhindrar alla ändringar av lagringskontot och dess resurser, och ta bort, vilket endast förhindrar borttagningar av lagringskontot och dess resurser. När du ändrar eller tar bort resurser via Microsoft.Storage resursprovidern tillämpas resurslås på Azure-filresurser och resursögonblicksbilder. De flesta portalåtgärder, Azure PowerShell-cmdletar för Azure Files med Rm i namnet (till exempel Get-AzRmStorageShare) och Azure CLI-kommandon i share-rm kommandogruppen (till exempel az storage share-rm list) använder Microsoft.Storage resursprovidern. Vissa verktyg och verktyg som Storage Explorer, äldre Azure Files PowerShell-hanterings-cmdletar utan Rm i namnet (till exempel Get-AzStorageShare) och äldre Azure Files CLI-kommandon under share kommandogruppen (till exempel az storage share list) använder äldre API:er i FileREST-API:et som kringgår Microsoft.Storage resursprovidern och resurslåsen. Mer information om äldre hanterings-API:er som exponeras i FileREST-API:et finns i kontrollplanet i Azure Files.

  • Lån för resurs-/resursögonblicksbilder: Resurslån är ett slags proprietärt lås för Azure-filresurser och ögonblicksbilder av filresurser. Lån kan sättas på enskilda Azure-filresurser eller ögonblicksbilder av filresurser av administratörer genom att anropa API:et via ett skript eller av mervärdestjänster som Azure Backup. När ett lån läggs på en Azure-filresurs eller en ögonblicksbild av filresursen kan du ändra eller ta bort ögonblicksbilden av filresursen/resursen med låne-ID:t. Administratörer kan också frigöra lånet före ändringsåtgärder, vilket kräver låne-ID eller bryta lånet, vilket inte kräver låne-ID: t. Mer information om resurslån finns i lånresurs.

Eftersom resurslås och lån kan störa avsedda administratörsåtgärder på ditt lagringskonto/Azure-filresurser kanske du vill ta bort eventuella resurslås/lån som har lagts på dina resurser manuellt eller automatiskt av mervärdestjänster som Azure Backup. Följande skript tar bort alla resurslås och lån. Kom ihåg att ersätta <resource-group> och <storage-account> med lämpliga värden för din miljö.

Innan du kör följande skript bör du installera den senaste versionen av Azure Storage PowerShell-modulen.

Viktigt!

Mervärdestjänster som tar resurslås och lån för resurs-/resursögonblicksbilder på dina Azure Files-resurser kan regelbundet återanvända lås och lån. Att ändra eller ta bort låsta resurser av mervärdestjänster kan påverka den regelbundna driften av dessa tjänster, till exempel att ta bort resursögonblicksbilder som hanterades av 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 { }
    }

Det går inte att ändra, flytta/byta namn på eller ta bort en fil eller katalog

Välj fliken Windows eller Linux beroende på vilket klientoperativsystem du använder för att få åtkomst till Azure-filresurser.

I Windows kan följande fel visas.

Överblivna filhandtag eller lån

Ett av de viktigaste syftena med en filresurs är att flera användare och program kan interagera samtidigt med filer och kataloger i resursen. För att hjälpa till med den här interaktionen ger filresurser flera sätt att förmedla åtkomst till filer och kataloger.

När du öppnar en fil från en monterad Azure-filresurs via SMB kommer programmet/operativsystemet att begära en filreferens, vilket är en referens till filen. Ditt program anger bland annat ett fildelningsläge när det begär ett filhandtag, vilket anger hur exklusiv din åtkomst till filen som tillämpas av Azure Files:

  • None: du har exklusiv åtkomst.
  • Read: andra kan läsa filen medan du har den öppen.
  • Write: andra kan skriva till filen medan du har den öppen.
  • ReadWrite: en kombination av både lägena Read och Write delningslägena.
  • Delete: andra kan ta bort filen medan du har den öppen.

Även om FileREST-protokollet som ett tillståndslöst protokoll inte har något begrepp för filhandtag, ger det en liknande mekanism för att förmedla åtkomst till filer och mappar som skriptet, programmet eller tjänsten kan använda: fillån. När en fil hyrs behandlas den som likvärdig med ett filhandtag med fildelningsläget None.

Även om filhandtag och lån har ett viktigt syfte kan filhandtag och lån ibland vara överblivna. När detta händer kan detta orsaka problem med att ändra eller ta bort filer. Du kan se felmeddelanden som:

  • Processen kan inte komma åt filen eftersom filen används i en annan process.
  • Åtgärden kan inte slutföras eftersom filen är öppen i ett annat program.
  • Dokumentet är låst för redigering av en annan användare.
  • Den angivna resursen har markerats för borttagning av en SMB-klient.

Lösningen på det här problemet beror på om detta orsakas av ett överblivet filhandtag eller lån.

Kommentar

REST-lån används av program för att förhindra att filer tas bort eller ändras. Innan du bryter några lån bör du identifiera vilket program som hämtar dem. Annars kan du bryta programbeteendet.

Orsak 1

En filreferens förhindrar att en fil/katalog ändras eller tas bort. Du kan använda PowerShell-cmdleten Get-AzStorageFileHandle för att visa öppna referenser.

Om alla SMB-klienter har stängt sina öppna referenser i en fil/katalog och problemet kvarstår kan du tvinga fram en stängning av en filreferens.

Lösning 1

Om du vill tvinga en filreferens att stängas använder du PowerShell-cmdlet Close-AzStorageFileHandle .

Kommentar

Cmdletarna Get-AzStorageFileHandle och Close-AzStorageFileHandle ingår i Az PowerShell-modulen version 2.4 eller senare. Information om hur du installerar den senaste Az PowerShell-modulen finns i Installera Azure PowerShell-modulen.

Orsak 2

Ett fillån förhindrar att en fil ändras eller tas bort. Du kan kontrollera om en fil har ett fillån med följande PowerShell-kommandon. Ersätt <resource-group>, <storage-account>, <file-share>och <path-to-file> med lämpliga värden för din miljö.

# 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

Om en fil har ett lån, måste det returnerade objektet innehålla följande egenskaper:

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Lösning 2

Om du vill ta bort ett lån från en fil kan du frigöra lånet eller avbryta det. Om du vill frigöra lånet behöver du lånets LeaseId, vilket du anger när du skapar lånet. Du behöver inte LeaseId för att bryta lånet.

I följande exempel visas hur du bryter lånet för filen som anges i orsak 2 (det här exemplet fortsätter med PowerShell-variablerna från orsak 2):

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

Det går inte att montera en ögonblicksbild av En Azure-filresurs i Linux

"Monteringsfel(22): Ogiltigt argument" när du försöker montera en ögonblicksbild av En Azure-filresurs i Linux

Orsak

snapshot Om alternativet för mount kommandot inte skickas i ett känt format mount kan kommandot misslyckas med det här felet. Bekräfta det genom att kontrollera kernelloggmeddelanden (dmesg) och dmesg visar en loggpost, cifs: Bad value for 'snapshot'till exempel .

Lösning

Kontrollera att du skickar snapshot alternativet för mount kommandot i rätt format. Se den manuella sidan mount.cifs (t.ex. man mount.cifs). Ett vanligt fel är att gmt-tidsstämpeln skickas i fel format, till exempel genom att använda bindestreck eller kolon i stället för perioder. Mer information finns i Montera en ögonblicksbild av en filresurs.

"Felaktig ögonblicksbildstoken" när du försöker montera en ögonblicksbild av En Azure-filresurs i Linux

Orsak

Om alternativet för ögonblicksbilder mount skickas från och med @GMT, men formatet fortfarande är fel (till exempel att använda bindestreck och kolon i stället för perioder), mount kan kommandot misslyckas med det här felet.

Lösning

Kontrollera att du skickar GMT-tidsstämpeln i rätt format, vilket är @GMT-year.month.day-hour.minutes.seconds. Mer information finns i Montera en ögonblicksbild av en filresurs.

"Monteringsfel(2): Ingen sådan fil eller katalog" när du försöker montera en ögonblicksbild av En Azure-filresurs

Orsak

Om ögonblicksbilden som du försöker montera inte finns mount kan kommandot misslyckas med det här felet. Bekräfta det genom att kontrollera kernelloggmeddelanden (dmesg) och dmesg visar en loggpost som:

[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

Lösning

Kontrollera att ögonblicksbilden som du försöker montera finns. Mer information om hur du listar tillgängliga ögonblicksbilder för en viss Azure-filresurs finns i Montera en ögonblicksbild av filresursen.

Diskkvot- eller nätverksfel från för många öppna referenser

Välj fliken Windows eller Linux beroende på vilket klientoperativsystem du använder för att få åtkomst till Azure-filresurser.

Fel 1816 – Det finns inte tillräckligt med kvot för att bearbeta det här kommandot

Orsak

Fel 1816 inträffar när du når den övre gränsen för samtidiga öppna referenser som tillåts för en fil eller katalog på Azure-filresursen. Läs mer i informationen om skalningsmål för Azure Files.

Lösning

Minska antalet samtidiga öppna referenser genom att stänga vissa handtag och försök sedan igen. Mer information finns i Checklista för prestanda och skalbarhet i Microsoft Azure Storage.

Visa öppna referenser för en filresurs, katalog eller fil med hjälp av PowerShell-cmdleten Get-AzStorageFileHandle.

Du kan stänga öppna referenser för en filresurs, katalog eller fil med hjälp av PowerShell-cmdleten Close-AzStorageFileHandle.

Kommentar

Cmdletarna Get-AzStorageFileHandle och Close-AzStorageFileHandle ingår i Az PowerShell-modulen version 2.4 eller senare. Information om hur du installerar den senaste Az PowerShell-modulen finns i Installera Azure PowerShell-modulen.

ERROR_UNEXP_NET_ERR (59) när du utför åtgärder på ett handtag

Orsak

Om du cachelagrar/har ett stort antal öppna referenser under en längre tid kan det här felet på serversidan uppstå på grund av begränsningsorsaker. När ett stort antal referenser cachelagras av klienten kan många av dessa referenser gå in i en återanslutningsfas samtidigt och skapa en kö på servern som måste begränsas. Omförsökslogiken och begränsningen på serverdelen för återanslutning tar längre tid än klientens tidsgräns. Den här situationen visas som en klient som inte kan använda ett befintligt handtag för någon åtgärd, där alla åtgärder misslyckas med ERROR_UNEXP_NET_ERR (59).

Det finns också gränsfall där klienthandtaget kopplas från från servern (till exempel ett nätverksfel som varar i flera minuter) som kan orsaka det här felet.

Lösning

Behåll inte ett stort antal handtag cachelagrade. Stäng handtagen och försök sedan igen. Använd Get-AzStorageFileHandle och Close-AzStorageFileHandle PowerShell-cmdletar för att visa/stänga öppna referenser.

Om du använder Azure-filresurser för att lagra profilcontainrar eller diskavbildningar för en storskalig distribution av virtuella skrivbord eller andra arbetsbelastningar som öppnar referenser på filer, kataloger och/eller rotkatalogen, kan du nå de övre skalningsgränserna för samtidiga öppna referenser. I det här fallet använder du ytterligare en Azure-filresurs och distribuerar containrar eller avbildningar mellan resurserna.

Fel : "Du kopierar en fil till ett mål som inte stöder kryptering"

När en fil kopieras över nätverket dekrypteras filen på källdatorn, överförs i klartext och krypteras igen på målet. Du kan dock se följande fel när du försöker kopiera en krypterad fil: "Du kopierar filen till ett mål som inte stöder kryptering."

Orsak

Det här problemet kan uppstå om du använder EFS (Encrypting File System). BitLocker-krypterade filer kan kopieras till Azure Files. Azure Files stöder dock inte NTFS EFS.

Lösning

Om du vill kopiera en fil över nätverket måste du först dekryptera den. Använd en av följande metoder:

  • Använd kommandot kopiera /d. Det gör att de krypterade filerna kan sparas som dekrypterade filer på målet.
  • Ange följande registernyckel:
    • Path = HKLM\Software\Policies\Microsoft\Windows\System
    • Värdetyp = DWORD
    • Namn = CopyFileAllowDecryptedRemoteDestination
    • Värde = 1

Tänk på att inställningen av registernyckeln påverkar alla kopieringsåtgärder som görs till nätverksresurser.

Fel: ConditionHeadersNotSupported från ett webbprogram som använder Azure Files från webbläsaren

Felet ConditionHeadersNotSupported uppstår vid åtkomst till innehåll som finns i Azure Files via ett program som använder villkorsstyrda rubriker, till exempel en webbläsare, och åtkomsten misslyckas. Felet anger att villkorsrubriker inte stöds.

Skärmbild som visar felmeddelandet ConditionHeadersNotSupported.

Orsak

Villkorsstyrda rubriker stöds ännu inte. Program som implementerar dem måste begära hela filen varje gång filen används.

Lösning

När en ny fil laddas upp är egenskapen CacheControl som standard ingen cache. För att tvinga programmet att begära filen varje gång måste filens CacheControl-egenskap uppdateras från no-cache till no-cache, no-store, must-revalidate. Detta kan uppnås med Hjälp av Azure Storage Explorer.

Screeshot som visar filegenskapen CacheControl.

Se även

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.