Felsöka Azure Files i Linux (SMB)

I den här artikeln listas vanliga problem som rör Azure Files när du ansluter från Linux-klienter. Det ger också möjliga orsaker och lösningar på dessa problem.

Förutom felsökningsstegen i den här artikeln kan du använda AzFileDiagnostics för att säkerställa att Linux-klienten har rätt förutsättningar. AzFileDiagnostics automatiserar identifieringen av de flesta symptom som nämns i den här artikeln. Det hjälper dig att konfigurera din miljö för att få optimala prestanda. Du hittar även den här informationen i felsökaren för Azure Files-resurser. Felsökaren innehåller steg som hjälper dig med problem med att ansluta, mappa och montera Azure Files resurser.

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

Orsak

Vanliga orsaker till det här problemet är:

• Du använder en Linux-distribution med en inaktuell SMB-klient. Mer information om vanliga Linux-distributioner som är tillgängliga i Azure och som har kompatibla klienter finns i Använda Azure Files med Linux.
• SMB-verktyg (cifs-utils) är inte installerade på klienten.
• Den lägsta SMB-versionen, 2.1, är inte tillgänglig på klienten.
• SMB 3.x-kryptering stöds inte på klienten. Tabellen ovan innehåller en lista över Linux-distributioner som stöder montering från lokal plats och mellan regioner med hjälp av kryptering. Andra distributioner kräver kernel 4.11 och senare versioner.
• Du försöker ansluta till en Azure-filresurs från en virtuell Azure-dator och den virtuella datorn är inte i samma region som lagringskontot.
• Om inställningen Säker överföring krävs är aktiverad på lagringskontot Azure Files endast anslutningar som använder SMB 3.x med kryptering.

Lösning

Lös problemet genom att använda felsökningsverktyget för att Azure Files monteringsfel på Linux. Det här verktyget:

• Hjälper dig att verifiera den klient som kör miljön.
• Identifierar den inkompatibla klientkonfigurationen som skulle orsaka åtkomstfel för Azure Files.
• Ger vägledning om självbetjäning.
• Samlar in diagnostikspårningarna.

”Monteringsfel(13): Åtkomst nekad” när monterar en Azure-filresurs

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-filresurserna finns. Okrypterade anslutningar inom samma datacenter kan också blockeras om inställningen Säker överföring krävs är aktiverad på lagringskontot. En krypterad kommunikationskanal tillhandahålls endast om användarens klientoperativsystem stöder SMB-kryptering.

Mer information finns i Krav för att montera en Azure-filresurs med Linux och paketet cifs-utils.

Lösning för orsak 1

1. Anslut från en klient som stöder SMB-kryptering eller ansluter från en virtuell dator i samma datacenter som Det Azure-lagringskonto som används för Azure-filresursen.
2. Kontrollera 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

Om virtuellt nätverk (VNET) och brandväggsregler har konfigurerats på lagringskontot tillåts inte nätverkstrafik om 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 testa om det virtuella nätverket eller brandväggsreglerna som 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.

"[behörighet nekad] Diskkvoten har överskridits" när du försöker öppna en fil

I Linux visas ett felmeddelande som liknar följande:

<filename> [behörighet nekad] Diskkvoten har överskridits

Orsak

Du har nått den övre gränsen för samtidiga öppna referenser som tillåts för en fil eller katalog.

Det finns en kvot på 2 000 öppna referenser på en enskild fil eller katalog. När du har 2 000 öppna referenser visas ett felmeddelande om att kvoten har nåtts.

Lösning

Minska antalet samtidiga öppna referenser genom att stänga några referenser och försök sedan igen.

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.

Långsam filkopiering till och från Azure Files i Linux

• Om du inte har ett specifikt minimikrav för I/O-storlek rekommenderar vi att du använder 1 MiB som I/O-storlek för optimala prestanda.
• Använd rätt kopieringsmetod:
  • Använd AzCopy för all överföring mellan två filresurser.
  • Om du använder cp eller dd parallellt kan kopieringshastigheten förbättras. Antalet trådar beror på ditt användningsfall och din arbetsbelastning. I följande exempel används sex:
  • cp-exempel (cp använder standardblockstorleken för filsystemet som segmentstorlek): find * -type f | parallel --will-cite -j 6 cp {} /mntpremium/ & .
  • dd-exempel (det här kommandot anger uttryckligen segmentstorleken till 1 MiB): find * -type f | parallel --will-cite-j 6 dd if={} of=/mnt/share/{} bs=1M
  • Verktyg från tredje part med öppen källkod, till exempel:
    • GNU Parallel.
    • Fpart – Sorterar filer och paketeras i partitioner.
    • Fpsync – Använder Fpart och ett kopieringsverktyg för att skapa flera instanser för att migrera data från src_dir till dst_url.
    • Multi – Flertrådig cp och md5sum baserat på GNU coreutils.
• Genom att ange filstorleken i förväg, i stället för att göra varje skrivning till en utökad skrivning, kan du förbättra kopieringshastigheten i scenarier där filstorleken är känd. Om du behöver undvika att utöka skrivningar kan du ange en målfilstorlek med truncate - size <size><file> kommandot . Därefter kopierar dd if=<source> of=<target> bs=1M conv=notrunc kommandot en källfil utan att behöva uppdatera målfilens storlek upprepade gånger. Du kan till exempel ange målfilstorleken för varje fil som du vill kopiera (anta att en resurs är monterad under /mnt/share):
  • $ for i in `` find * -type f``; do truncate --size ``stat -c%s $i`` /mnt/share/$i; done
  • och sedan – kopiera filer utan att utöka skrivningar parallellt: $find * -type f | parallel -j6 dd if={} of =/mnt/share/{} bs=1M conv=notrunc

"Monteringsfel(115): Åtgärden pågår nu" när du monterar Azure Files med hjälp av SMB 3.x

Orsak

Vissa Linux-distributioner stöder ännu inte krypteringsfunktioner i SMB 3.x. Användarna kan få felmeddelandet "115" om de försöker montera Azure Files med hjälp av SMB 3.x på grund av att en funktion saknas. SMB 3.x med fullständig kryptering stöds endast när du använder Ubuntu 16.04 eller senare.

Lösning

Krypteringsfunktionen för SMB 3.x för Linux introducerades i kerneln 4.11. Den här funktionen möjliggör montering av en Azure-filresurs från en lokal plats eller från en annan Azure-region. Vissa Linux-distributioner kan ha bakåtportar ändringar från 4.11-kerneln till äldre versioner av Linux-kerneln som de underhåller. Som hjälp för att avgöra om din version av Linux stöder SMB 3.x med kryptering kan du läsa Använda Azure Files med Linux.

Om din Linux SMB-klient inte stöder kryptering monterar du Azure Files med SMB 2.1 från en virtuell Linux-dator på Azure som är i samma datacenter som filresursen. Kontrollera att inställningen Säker överföring krävs är aktiverad för lagringskontot.

Fel : "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 i portalen kan följande felmeddelande visas:

Ingen åtkomst
Felkod: 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 som 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 2: Ditt användarkonto har inte åtkomst till lagringskontot

Lösning för orsak 2

Bläddra till lagringskontot där Azure-filresursen finns, klicka på Å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).

Det går inte att ta bort en fil eller katalog i en Azure-filresurs

Orsak

Det här problemet uppstår vanligtvis om filen eller katalogen har en öppen referens.

Lösning

Om SMB-klienterna har stängt alla öppna referenser och problemet kvarstår, gör du följande:

• Använd PowerShell-cmdleten Get-AzStorageFileHandle för att visa öppna referenser.

• Använd PowerShell-cmdleten Close-AzStorageFileHandle för att stänga öppna referenser.

Dåliga prestanda för en Azure-filresurs monterad i en virtuell Linux-dator

Orsak 1: Cachelagring

En möjlig orsak till långsamma prestanda är inaktiverad cachelagring. Cachelagring kan vara användbart om du använder en fil upprepade gånger, annars kan det vara en extra belastning. Kontrollera om du använder cachen innan du inaktiverar den.

Lösning för orsak 1

Du kan kontrollera om cachelagring är inaktiverat genom att leta efter cache=-posten.

Cache = ingen anger att cachelagring är inaktiverad. Återmontera resursen med standardmonteringskommandot eller genom att uttryckligen lägga till alternativet cache=strict till monteringskommandot för att säkerställa att standardläget för cachelagring eller "strikt" cachelagring är aktiverat.

I vissa scenarier kan monteringsalternativet serverino göra så att kommandot ls kör stat mot varje katalogpost. Det här beteendet resulterar i prestandaförsämring när du visar en stor katalog. Du kan kontrollera monteringsalternativen i posten /etc/fstab:

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

Du kan också kontrollera om rätt alternativ används genom att köra kommandot sudo mount | grep cifs och kontrollera dess utdata. Följande är exempel på utdata:

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

Om alternativet cache=strict eller serverino inte finns demonterar du och monterar Azure Files igen genom att köra monteringskommandot från dokumentationen. Kontrollera sedan att posten /etc/fstab har rätt alternativ.

Orsak 2: Begränsning

Det är möjligt att du har begränsningar och att dina begäranden skickas till en kö. Du kan kontrollera detta genom att använda Azure Storage mått i Azure Monitor.

Lösning för orsak 2

Se till att din app är inom Azure Files skalningsmål.

Tidsstämplar förlorades när filer kopierades från Windows till Linux

På Linux/Unix-plattformar misslyckas kommandot cp-p om olika användare äger fil 1 och fil 2.

Orsak

Force-flaggan f i COPYFILE resulterar i körning av cp -p -f på Unix. Det här kommandot kan inte heller bevara tidsstämpeln för filen som du inte äger.

Lösning

Använd lagringskontoanvändaren för att kopiera filerna:

• Useadd : [storage account name]
• Passwd [storage account name]
• Su [storage account name]
• Cp -p filename.txt /share

ls: cannot access ' < path > ': Input/output error

När du försöker lista filer i en Azure-filresurs med hjälp av kommandot ls låser sig kommandot när du visar en lista över filer. Du får följande fel:

ls: cannot access' < path > ': Input/output error

Lösning

Uppgradera Linux-kerneln till följande versioner som har en korrigering för det här problemet:

• 4.4.87+
• 4.9.48+
• 4.12.11+
• Alla versioner som är större än eller lika med 4.13

Det går inte att skapa symboliska länkar – ln: det gick inte att skapa symbolisk länk "t": Åtgärden stöds inte

Orsak

Som standard aktiverar montering av Azure-filresurser på Linux med hjälp av CIFS inte stöd för symboliska länkar (symlinks). Du ser ett fel som liknar detta:

ln -s linked -n t
ln: failed to create symbolic link 't': Operation not supported

Lösning

Linux CIFS-klienten stöder inte skapandet av Windows symboliska länkar via SMB 2- eller 3-protokollet. Linux-klienten stöder för närvarande ett annat format med symboliska länkar som kallas Minshall+franska symlinks för både åtgärder för att skapa och följa. Kunder som behöver symboliska länkar kan använda monteringsalternativet "sinsymlinks". Vi rekommenderar "formatssymlinks" eftersom det också är det format som Mac-datorer använder.

Om du vill använda symlinks lägger du till följande i slutet av CIFS-monteringskommandot:

,mfsymlinks

Kommandot ser ut ungefär så här:

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-name> <mount-point> -o vers=<smb-version>,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks

Du kan sedan skapa symlinks enligt förslaget på wikin.

Fel ConditionHeadersNotSupported från ett webb program med Azure Files från webbläsare

ConditionHeadersNotSupported-felet uppstår vid åtkomst till innehåll som finns i Azure Files via ett program som använder villkorliga rubriker, till exempel en webbläsare, åtkomsten Miss lyckas. Felet anger att villkors rubriker inte stöds.

Orsak

Villkorliga rubriker stöds inte ännu. Program som implementerar dem måste begära den fullständiga filen varje gång filen öppnas.

Lösning

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

"Monteringsfel(112): Värden är nere" på grund av en time out för återanslutning

Monteringsfel 112 uppstår på Linux-klienten när klienten har varit inaktiv under en längre tid. Tidsgränsen för anslutningen nås efter en längre tids inaktivitet och klienten kopplas från.

Orsak

Anslutningen kan vara inaktiv av följande skäl:

• Nätverkskommunikationsfel som förhindrar att en TCP-anslutning till servern återupprättas när standardalternativet ”mjukmontering” används
• Nya återanslutningskorrigeringar som inte finns i äldre kernlar

Lösning

Det här återanslutningsproblemet i Linux-kernel har nu åtgärdats som en del av följande ändringar:

• Korrigering av återanslutning för att inte skjuta upp smb3-sessionsåteranslutning långt efter socketåteranslutning
• Anrop av ekotjänst omedelbart efter socketåteranslutning
• CIFS: Korrigering av en möjlig minnesskada under återanslutning
• CIFS: Korrigering av möjlig dubbel låsning av mutex under återanslutning (för kernel v4.9 och senare)

De här ändringarna kan emellertid inte portas ännu till alla Linux-distributioner. Om du använder en populär Linux-distribution kan du kontrollera vilken version av distributionen som har de nödvändiga kerneländringarna i Använd Azure Files linux.

Lösning

Du kan undvika det här problemet genom att ange en hårdmontering. Med en hårdmontering tvingas klienten vänta tills en anslutning har upprättats eller tills den avbryts explicit. Du kan använda den för att undvika fel på grund av att tidsgränsen nås för nätverket. Den här lösningen kan dock orsaka obestämd väntan. Var beredd på att stoppa anslutningar vid behov.

Om du inte kan uppgradera till de senaste kernel-versionerna kan du lösa problemet genom att behålla en fil i Azure-filresursen som du skriver till minst var 30:e sekund. Detta måste vara en skrivåtgärd, till exempel omskrivning av datumet (skapad eller ändrad) i filen. Annars kan du få cachelagrade resultat och åtgärden kanske inte utlöser återanslutningen.

"CIFS VFS: fel -22 på ioctl för att hämta gränssnittslistan" när du monterar en Azure-filresurs med hjälp av SMB 3.x

Orsak

Det här felet loggas eftersom Azure Files för närvarande inte stöder SMB multichannel.

Lösning

Det här felet kan ignoreras.

Det går inte att komma åt mappar eller filer som har ett blanksteg eller en punkt i slutet

Du kan inte komma åt mappar eller filer från Azure-filresursen när den är monterad på Linux. Kommandon som du och ls och/eller program från tredje part kan misslyckas med felet "Ingen sådan fil eller katalog" vid åtkomst till resursen, men du kan ladda upp filer till dessa mappar via portalen.

Orsak

Mapparna eller filerna har laddats upp från ett system som kodar tecknen i slutet av namnet till ett annat tecken, filer som laddats upp från en Mac-dator kan ha ett "0xF028"- eller "0xF029"-tecken i stället för 0x20 (blanksteg) eller 0X2E (punkt).

Lösning

Använd alternativet mapchars på resursen när du monterar resursen på Linux:

Istället för:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino

använd:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,mapchars

Behöver du hjälp? Kontakta supporten.

Om du fortfarande behöver hjälp kan du kontakta supporten för att lösa problemet snabbt.