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

Gäller för: ✔️ SMB Azure-fildelningar

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.

Viktigt!

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

Kör diagnostik

Diagnostikverktyg kan hjälpa till att säkerställa att klienterna har rätt förutsättningar och samla in felsökningsinformation om fältproblem som kan vara svåra att återskapa.

Använda AzFileDiagnostics

Använd AzFileDiagnostics för att automatisera symptomidentifiering 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.

Använda verktyget Always-On Diagnostics

Du kan också använda verktyget Always-On Diagnostics (AOD) för att samla in loggar på SMB- och NFSv4 Linux-klienter. Daemonen körs i bakgrunden som en systemtjänst och kan konfigureras för att identifiera avvikelser i olika källor, till exempel dmesg-loggar, felsökningsdata, felmått och svarstidsmått. Den kan samla in data från tcpdump, nfsstat, mountstats och andra källor, tillsammans med systemets cpu- och minnesanvändning.

Always-On Diagnostics-verktyget är för närvarande kompatibelt med system som kör SUSE Linux Enterprise Server 15 (SLES 15) och Red Hat Enterprise Linux 8 (RHEL 8). Följ installationsstegen som motsvarar operativsystemet:

I SLES 15 följer du dessa instruktioner för att installera verktyget Always-On Diagnostics:

  1. Lägg till Microsoft-lagringsplatsen. Du kan behöva lägga till Microsoft-lagringsplatsens nyckel i listan över betrodda nycklar.

    sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
sudo zypper addrepo --check --refresh --name 'Microsoft' https://packages.microsoft.com/sles/15/prod microsoft

  2. Uppdatera lagringsplatserna.

    sudo zypper refresh

  3. Kontrollera om repot har lagts till och om aodpaketet är tillgängligt för installation.

    zypper search aod

  4. Installera paketet .

    sudo zypper install aod

Tidsstämplar går förlorade när filer kopieras

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

Orsak

Tvångsflaggan f i COPYFILE resulterar i att cp -p -f 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äg>': in-/utmatningsfel

Lösning

Uppgradera Linux-kerneln till en version som innehåller en korrigering för det här problemet. Använd någon av följande versioner:

  • 4.4.87+
  • 4.9.48+
  • 4.12.11+
  • Alla versioner som är 4.13 eller senare

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 standardinställning innebär montering av Azure-filresurser i Linux med SMB inte att stöd för symboliska länkar (symlinks) aktiveras. 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 . Använd mfsymlinks eftersom det också är det format som Mac-datorer använder.

Om du vill använda symlinks lägger du till följande alternativ 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

Du kan inte komma åt mappar eller filer från Azure-fildelningen när den är monterad i Linux. Kommandon som du och ls, och program från tredje part kan misslyckas med felet "Ingen sådan fil eller katalog" vid åtkomst till resursen.

Orsak 1

Mapparna eller filerna har namn som innehåller tecken som kodas på olika sätt av systemet som laddar upp dem. Filer som laddas upp från en macOS-klient kan till exempel ha tecknet 0xF028 eller 0xF029 i stället för 0x20 (blanksteg) eller 0x2E (punkt).

Lösning 1

Använd alternativet mapchars 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

Orsak 2

När du tar bort en fil men håller handtaget öppet behåller SMB-servern en zombiefil tills den stänger det sista handtaget till filen. Alla försök att utföra åtgärder på den här zombiefilen kan resultera i "Inga sådana fil- eller katalogfel" i Linux.

Lösning 2

Återställ den borttagna filen från den senaste säkerhetskopian om det behövs.

DNS-problem med direktmigrering av Azure Storage-konton

Fil-I/O-operationer på det monterade filsystemet börjar ge felen "Host is down" eller "Åtkomst 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. 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 för ett lagringskonto eftersom DNS-mappningen kan ändras.

Orsak

För kapacitetsbelastningsutjämning migrerar systemet ibland lagringskonton från ett lagringskluster till ett annat. Kontomigrering uppdaterar DNS-mappningarna så att de pekar på målklustret, som omdirigerar Azure Files trafik från källklustret till målklustret. Den här uppdateringen blockerar all trafik till källklustret från det kontot. SMB-klienten förväntas hämta DNS-uppdateringarna och omdirigera 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 slutar hantera 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 det tillfälligt löser problemet att demontera och montera resursdelningen igen, är det ingen 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 kärnans DNS-resolvercache 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 tillfälligt problemet. För en permanent korrigering lägger du till en privat slutpunkt i ditt lagringskonto och ansluter 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 skickas till Huvudlinjens Linux-kernel. Följande distributioner omfattar dessa korrigeringar:

  • 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 backporterar dessa korrigeringar. 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 du aktiverar FIPS (Federal Information Processing Standard) i en virtuell Linux-dator kan du inte montera SMB-filresursen. 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 Linux-virtuella datorn där FIPS är aktiverat använder du identitetsbaserad autentisering. Mer information finns i Aktivera služba 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. Ändra GRUB_CMDLINE_LINUX_DEFAULT i filen /etc/default/grub och ta bort parametern fips=1.

  3. Återskapa 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

  • Last updated on