Dela via

Felsöka Azure Files-problem i Linux (SMB)

  • Artikel

Den här artikeln innehåller vanliga problem som kan uppstå när du använder SMB Azure-filresurser med Linux-klienter. Det ger också möjliga orsaker och lösningar på dessa problem.

Du kan använda AzFileDiagnostics för att automatisera symptomidentifieringen och se till att Linux-klienten har rätt förutsättningar. 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-filresurser.

Viktigt!

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

Gäller för

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

Tidsstämplar gick förlorade när filer kopierades

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

Orsak

Force-flaggan f i COPYFILE resulterar i att cp -p -f den körs 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:

  • str_acc_name=[storage account name]
  • sudo useradd $str_acc_name
  • sudo passwd $str_acc_name
  • su $str_acc_name
  • cp -p filename.txt /share

ls: kan inte komma åt "<sökväg>": Indata-/utdatafel

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

ls: kan inte komma åt sökvägen<>: Indata-/utdatafel

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 den symboliska länken "t": Åtgärden stöds inte

Orsak

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

sudo ln -s linked -n t

ln: failed to create symbolic link 't': Operation not supported

Lösning

Linux SMB-klienten stöder inte att skapa symboliska länkar i Windows-stil via SMB 2- eller 3-protokollet. För närvarande stöder Linux-klienten en annan typ av symboliska länkar med namnet Minshall+French symlinks för både skapa och följa åtgärder. Kunder som behöver symboliska länkar kan använda monteringsalternativet "mfsymlinks". Vi rekommenderar "mfsymlinks" 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 SMB-monteringskommandot:

,mfsymlinks

Kommandot ser alltså ut 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 symlänkar enligt förslag på wikin.

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 du ä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. Du kan dock ladda upp filer till dessa mappar via Azure Portal.

Orsak

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

Lösning

Använd mapchars-alternativet på resursen när du monterar resursen i 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

DNS-problem med direktmigrering av Azure Storage-konton

Fil-I/Os på det monterade filsystemet börjar ge felen "Värden är nere" eller "Behörighet nekad". Linux dmesg-loggar på klienten visar upprepade fel som:

Status code returned 0xc000006d STATUS_LOGON_FAILURE
cifs_setup_session: 2 callbacks suppressed
CIFS VFS: \\contoso.file.core.windows.net Send error in SessSetup = -13

Du ser också att serverns FQDN nu matchar en annan IP-adress än den som den för närvarande är ansluten till. Det här problemet kan inträffa i alla scenarier där serverns IP-adress kan ändras, till exempel kontomigrering. Ett annat känt scenario är redundansväxling av lagringskonto eftersom DNS-mappningen kan ändras.

Orsak

För kapacitetsbelastningsutjämning migreras lagringskonton ibland direkt från ett lagringskluster till ett annat. Kontomigrering utlöser Azure Files-trafik som omdirigeras från källklustret till målklustret genom att uppdatera DNS-mappningarna så att de pekar på målklustret. Detta blockerar all trafik till källklustret från det kontot. Det förväntas att SMB-klienten hämtar DNS-uppdateringarna och omdirigerar ytterligare trafik till målklustret. Men på grund av en bugg i Linux SMB-kernelklienten börjar den här omdirigeringen inte gälla. Därför fortsätter datatrafiken att gå till källklustret, som har slutat att betjäna kontot efter migreringen.

Lösning

Du kan åtgärda det här problemet genom att starta om klientoperativsystemet, men du kan stöta på problemet igen om du inte uppgraderar klientoperativsystemet till en Linux-distributionsversion med stöd för kontomigrering.

Det kan verka som om det verkar lösa problemet tillfälligt att demontera och demontera resursen, men det är inte en permanent lösning. När klienten återansluter till servern kan problemet inträffa igen. Den tillfälliga åtgärden beror på att en ny monteringsåtgärd kringgår SMB-kernelcachen och löser DNS-adressen i användarutrymmet. Kernel-DNS-cachen används dock under alla återställningar av nätverksavkoppling, vilket kan orsaka att problemet uppstår igen. Det här beteendet kvarstår även utanför migreringar av lagringskonton.

Om du vill lösa det här problemet på ett bättre sätt rensar du dns-lösencachen för kernel:

  1. Visa status för kernelmodulen dns_resolver genom att köra följande kommando:

    grep '.dns_resolver' /proc/keys

    Du bör se kommandoutdata som i följande exempel:

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: 1

  2. Rensa dns-matchningscache för kernel genom att köra följande kommando:

    sudo keyctl clear $((16#$(grep '.dns_resolver' /proc/keys | cut -f1 -d\ ) ))

  3. Visa status för kernelmodulen dns_resolver igen:

    grep '.dns_resolver' /proc/keys

    Du bör se kommandoutdata som i följande exempel som anger att cacheminnet nu är tomt:

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty

  4. Demontera och återmontera resursen för att åtgärda problemet.

Kommentar

På vissa äldre Linux-distributioner kanske åtgärdsstegen inte fungerar. I sådana fall löser omstart av klientoperativsystemet problemet tillfälligt. För en permanent korrigering kan du lägga till en privat slutpunkt till ditt lagringskonto och ansluta till filresursen med hjälp av en privat länk.

Lösning

Om du vill ha en permanent korrigering uppgraderar du klientoperativsystemet till en Linux-distributionsversion med stöd för kontomigrering. Flera korrigeringar för Linux SMB-kernelklienten har skickats till Huvudlinjens Linux-kernel. Följande distributioner har korrigeringarna:

  • Ubuntu: 20.04, 22.04, 24.04 och AKS 22.04 (korrigeringarna distribueras i kernelversion 5.15.0-1068)
  • RHEL: 8.6+
  • SLES: 15SP2, 15SP3, 15SP4 och 15SP5
  • Azure Linux: 2.0 (korrigeringarna distribueras i kernelversion 5.15.159.1) och 3.0

Vissa distributioner har bakåtporterat dessa korrigeringar. Du kan kontrollera om följande korrigeringar finns i distributionsversionen som du använder:

Det går inte att montera SMB-filresursen när FIPS är aktiverat

När FIPS (Federal Information Processing Standard) är aktiverat på en virtuell Linux-dator kan SMB-filresursen inte monteras. Linux-dmesg-loggarna på klienten visar fel som:

kernel: CIFS: VFS: Could not allocate crypto hmac(md5)
kernel: CIFS: VFS: Error -2 during NTLMSSP authentication
kernel: CIFS: VFS: \\contoso.file.core.windows.net Send error in SessSetup = -2
kernel: CIFS: VFS: cifs_mount failed w/return code = -2

Viktigt!

FIPS är en uppsättning standarder som den amerikanska regeringen använder för att säkerställa säkerhet och integritet för datorsystem. När ett system är i FIPS-läge följer det specifika kryptografiska krav som beskrivs i dessa standarder.

Orsak

Klienten för SMB-filresursen använder NTLMSSP-autentiseringen, vilket kräver MD5-hashalgoritmen. Men i FIPS-läge är MD5-algoritmen begränsad eftersom den inte är FIPS-kompatibel. MD5 är en hash-funktion som ger ett 128-bitars hash-värde. MD5 anses dock vara osäkert i kryptografiska syften.

Så här kontrollerar du om FIPS-läget är aktiverat

Kontrollera om FIPS-läget är aktiverat på klienten genom att köra följande kommando. Om värdet är inställt på 1 aktiveras FIPS.

sudo cat /proc/sys/crypto/fips_enabled

Lösning

Lös problemet genom att aktivera Kerberos-autentisering för SMB-filresurs. Om FIPS är aktiverat oavsiktligt läser du alternativ 2 för att inaktivera det.

Alternativ 1: Aktivera Kerberos-autentisering för SMB-filresurs

Om du vill montera en SMB-filresurs på den virtuella Linux-dator där FIPS är aktiverat använder du Kerberos/Azure AD-autentisering. Mer information finns i Aktivera Active Directory-autentisering via SMB för Linux-klienter som har åtkomst till Azure Files.

Alternativ 2: Inaktivera FIPS för att montera Samba-resursen

  1. Ändra sysctl-värdet crypto.fips_enabled till 0 i /etc/sysctl.conf.

  2. GRUB_CMDLINE_LINUX_DEFAULT Ändra i /etc/default/grub -filen och ta bort parametern fips=1.

  3. Återskapade grub2-konfigurationsfilen med följande kommando:

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

  4. Återskapa initramfs-avbildningen med följande kommando:

    sudo dracut -fv

  5. Starta om den virtuella datorn.

Mer information finns i följande dokument från Linux-distributörer:

Behöver du hjälp?

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

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.