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

Filresurstyp SMB NFS
Standardfilresurser (GPv2), LRS/ZRS
Standardfilresurser (GPv2), GRS/GZRS
Premium-filresurser (FileStorage), LRS/ZRS

Tidsstämplar förlorades vid kopiering av filer

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 körning 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:

  • 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: 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 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 (symlänkar). 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 har inte stöd för att skapa symboliska länkar i Windows-format över SMB 2- eller 3-protokollet. För närvarande stöder Linux-klienten en annan typ av symboliska länkar som kallas Minshall+ franska 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 symlinks 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-portalen.

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 alternativet mapchars 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ända:

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 matchas till en annan IP-adress än den som den för närvarande är ansluten till.

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

Även om det kan verka som om avmontering och återmontering av resursen tillfälligt kan lösa problemet är det 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 återställning av nätverksavkoppling, vilket kan orsaka att problemet uppstår igen. Det här beteendet kvarstår även utanför migrering av lagringskonton.

Du kan lösa det här problemet på ett bättre sätt genom att rensa dns-matchningscachen för kerneln:

  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 kernelns DNS-matchningscache 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.

Obs!

För vissa äldre Linux-distributioner kanske de föregående åtgärdsstegen inte fungerar. I sådana fall är omstart av klientoperativsystemet den enda kända lösningen.

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. Kernel version 5.15+ och Keyutils-1.6.2+ har korrigeringarna. Vissa distributioner har bakåtporterat dessa korrigeringar och 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 går det inte att montera SMB-filresursen. Linux-dmesg loggar på klientens visningsfel, till exempel:

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-autentisering, vilket kräver MD5-hashalgoritmen. Men i FIPS-läge är MD5-algoritmen begränsad eftersom den inte är FIPS-kompatibel. MD5 är en ofta använd hashfunktion som producerar ett 128-bitars hashvä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 alternativ2 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 kan du kontakta 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.