Dela via

Felsöka Azure Files anslutningsproblem (SMB)

  • Artikel

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

Obs!

Var den här artikeln användbar? Dina indata är viktiga för oss. Använd knappen Feedback på den här sidan för att berätta 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

Filresurstyp SMB NFS
Standardfilresurser (GPv2), LRS/ZRS
Standardfilresurser (GPv2), GRS/GZRS
Premium-filresurser (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-filresurs i Windows kan följande felmeddelanden visas.

Fel 5 när du monterar en Azure-filresurs

  • Systemfel 5 har inträffat. Åtkomst nekas.

Orsak 1: Okrypterad kommunikationskanal

För säkerhet blockeras anslutningar till Azure-filresurser om kommunikationskanalen inte är krypterad och anslutningsförsöket inte görs från samma datacenter där Azure-filresurserna finns. Om inställningen Säker överföring krävs är aktiverad på lagringskontot blockeras även okrypterade anslutningar i 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 inkluderar 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 (VM) i samma datacenter som azure-lagringskontot som används för Azure-filresursen.
  3. Kontrollera att inställningen Säker överföring krävs är inaktiverad för lagringskontot om klienten inte stöder SMB-kryptering.

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

Nätverkstrafik nekas om det virtuella nätverket (VNET) och brandväggsreglerna har konfigurerats på lagringskontot, såvida inte klientens IP-adress eller virtuella nätverk tillåts.

Lösning för orsak 2

Kontrollera att regler för virtuella nätverk och brandväggar är korrekt konfigurerade 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 3: Behörigheter på share-nivå är felaktiga när du använder identitetsbaserad autentisering

Om användarna kommer åt Azure-filresursen med hjälp av Active Directory (AD) eller Microsoft Entra Domain Services 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örigheterna är korrekt konfigurerade:

  • Active Directory Domain Services (AD DS) finns i 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 hjälp av 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 i molnet".

  • Microsoft Entra Domain Services se Tilldela behörigheter på resursnivå.

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 inträffat. Nätverkssökvägen hittades inte
  • Systemfel 67 har uppstått. Det går inte att hitta nätverksnamnet.
  • 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. Om du vill se en sammanfattning av internetleverantörer som tillåter eller inte tillåter åtkomst från port 445 går du till TechNet.

Om du vill kontrollera om din brandvägg eller ISP blockerar port 445 använder du verktyget AzFileDiagnostics eller cmdleten Test-NetConnection .

Om du vill använda cmdleten Test-NetConnection måste Azure PowerShell-modulen installeras. Mer information finns i Installera Azure PowerShell modul. Kom ihåg att ersätta <your-storage-account-name> och <your-resource-group-name> med relevanta 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 anslutningen lyckades 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

Obs!

Det här kommandot returnerar lagringskontots aktuella IP-adress. Den här IP-adressen är inte garanterad att förbli densamma och 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 över QUIC stöder Windows Server 2022 Azure Edition QUIC-protokollet. Du kan skapa en enkel cache av dina Azure-filresurser på en virtuell Windows Server 2022 Azure Edition-dator med hjälp av Azure File Sync. Den här konfigurationen 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 det här alternativet finns i SMB over QUIC with Azure File Sync (SMB over QUIC with Azure File Sync).

Lösning 2 – Använd VPN eller ExpressRoute Genom att konfigurera ett virtuellt privat nätverk (VPN) eller ExpressRoute från en lokal plats till ditt Azure Storage-konto, där Azure Files exponeras 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 att få åtkomst till Azure Files från Windows.

Lösning 3 – Avblockera port 445 med hjälp av din ISP/IT-administratör Kontakta 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 en av dem. Ladda ned och installera Storage Explorer och anslut till filresursen som backas upp 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. Om NTLMv1 är aktiverat skapas en mindre säker klient. Därför blockeras kommunikationen 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 avsnittet LmCompatibilityLevel om 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 felkod 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 är inaktiverade 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 ett stoppat tillstånd på den virtuella Windows-datorn:

  • Nätverksanslutningar
  • Nätverkslistetjänst
  • Nätverksplatsmedvetenhet
  • Gränssnittstjänst för nätverkslager
  • 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 i programmet.

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 för användarnamn och lösenord för net use kommandot.

  • cmdkey Använd kommandot för att lägga till autentiseringsuppgifterna i Autentiseringshanteraren. 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 kanske redan har 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 inloggat 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.

New-PSDrive kommandot 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 filreferenser och lån vid redundansväxling. Klienter måste demontera och återmontera 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 följande fel visas:

Felkod utan åtkomst: 403

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

Lösning för orsak 1

Kontrollera att regler för virtuella nätverk och brandväggar är korrekt konfigurerade 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 Skydda 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 finns två sätt att förhindra oavsiktlig ändring eller borttagning av Azure-filresurser och resursögonblicksbilder:

  • Lagringskontots resurslå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 framtvingas 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 finns i kontrollplanet i Azure Files.

  • Lån för resurs-/resursögonblicksbilder: Resurslån är ett slags eget lås för Azure-filresurser och ögonblicksbilder av filresurser. Lån kan placeras 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 sätts på en ögonblicksbild av en Azure-filresurs eller filresurs 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. Mer information om resurslån finns i Avsnittet om låneresurs.

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 placerats 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 tillämpa lås och lån igen. 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 filreferenser eller lån

Ett av huvudsyftena 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 tillhandahåller 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 begär ditt program/operativsystem en filreferens, vilket är en referens till filen. Ditt program anger bland annat ett fildelningsläge när det begär en filreferens, som anger hur exklusiv åtkomsten 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 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 ett begrepp för filreferenser, 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 en filreferens med fildelningsläget None.

Även om filreferenser och lån har ett viktigt syfte kan filreferenser och lån ibland bli överblivna. När detta inträffar kan det orsaka problem med att ändra eller ta bort filer. Du kan se felmeddelanden som:

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

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

Obs!

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 på en fil/katalog och problemet kvarstår kan du tvinga fram en filreferens.

Lösning 1

Om du vill tvinga ett filhandtag att stängas använder du PowerShell-cmdleten Close-AzStorageFileHandle .

Obs!

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

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 ska 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 bryta lånet. För att frigöra lånet behöver du LeaseId för lånet, som du angav när du skapade 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 skicka GMT-tidsstämpeln i fel format, till exempel med bindestreck eller kolon i stället för punkter. Mer information finns i Montera en ögonblicksbild av filresursen.

"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 punkter), 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 filresursen.

"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. Kontrollera kernelloggmeddelanden (dmesg) för att bekräfta det, så visar dmesg en loggpost, till exempel:

[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. Mer information finns i Azure Files skalningsmål.

Lösning

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

Om du vill visa öppna referenser för en filresurs, katalog eller fil använder du PowerShell-cmdleten Get-AzStorageFileHandle .

Om du vill stänga öppna referenser för en filresurs, katalog eller fil använder du PowerShell-cmdleten Close-AzStorageFileHandle .

Obs!

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

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

Orsak

Om du cachelagrar/håller ett stort antal öppna referenser under en längre tid kan det här felet på serversidan visas på grund av begränsningar. 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. Återförsökslogiken och begränsningen på serverdelen för återanslutning tar längre tid än klientens tidsgräns. Den här situationen visar sig vara att en klient 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 servern (till exempel ett nätverksfel som varar i flera minuter) som kan orsaka det här felet.

Lösning

Håll inte ett stort antal handtag cachelagrade. Stäng handtagen och försök 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.

Felet "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 inträffa om du använder EFS (Encrypting File System). BitLocker-krypterade filer kan kopieras till Azure Files. Men Azure Files stöder inte NTFS EFS.

Lösning

Om du vill kopiera en fil över nätverket måste du först dekryptera den. Detta gör du genom att använda någon av följande metoder.

  • Använd kommandot copy /d . Det gör att krypterade filer 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.

Felet ConditionHeadersNotSupported från ett webbprogram med hjälp av Azure Files från webbläsaren

Felet ConditionHeadersNotSupported inträffar när åtkomst till innehåll som finns i Azure Files via ett program som använder villkorliga huvuden, till exempel en webbläsare, misslyckas åtkomsten. Felet anger att villkorshuvuden inte stöds.

Skärmbild som visar felmeddelandet ConditionHeadersNotSupported.

Orsak

Villkorliga rubriker stöds inte ännu. 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 cacheControl-egenskapen som standard ingen cache. Om du vill 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.

Skärmbild 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.