Delen via

Problemen met Azure Files in Linux (SMB) oplossen

  • Artikel

Dit artikel bevat veelvoorkomende problemen die kunnen optreden bij het gebruik van SMB Azure-bestandsshares met Linux-clients. Het biedt ook mogelijke oorzaken en oplossingen voor deze problemen.

U kunt AzFileDiagnostics gebruiken om symptoomdetectie te automatiseren en ervoor te zorgen dat de Linux-client de juiste vereisten heeft. Het helpt bij het instellen van uw omgeving om optimale prestaties te krijgen. U kunt deze informatie ook vinden in de probleemoplosser voor Azure-bestandsshares.

Belangrijk

Dit artikel is alleen van toepassing op SMB-shares. Zie Problemen met NFS Azure-bestandsshares oplossen voor meer informatie over NFS-shares.

Van toepassing op

Bestands sharetype SMB NFS
Standaardbestandsshares (GPv2), LRS/ZRS
Standaardbestandsshares (GPv2), GRS/GZRS
Premium bestandsshares (FileStorage), LRS/ZRS

Tijdstempels zijn verloren gegaan bij het kopiëren van bestanden

Op Linux-/Unix-platforms mislukt de cp -p opdracht als verschillende gebruikers eigenaar zijn van bestand 1 en bestand 2.

Oorzaak

De forcevlag f in COPYFILE resulteert in uitvoering cp -p -f op Unix. Met deze opdracht kan ook de tijdstempel van het bestand waarvan u geen eigenaar bent, behouden blijven.

Tijdelijke oplossing

Gebruik de gebruiker van het opslagaccount om de bestanden te kopiëren:

  • 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: heeft geen toegang tot '<pad>': Invoer-/uitvoerfout

Wanneer u bestanden in een Azure-bestandsshare probeert weer te geven met behulp van de ls opdracht, loopt de opdracht vast bij het weergeven van bestanden. U krijgt de volgende fout:

ls: kan geen toegang krijgen tot'pad>'<: Invoer-/uitvoerfout

Oplossing

Voer een upgrade uit van de Linux-kernel naar de volgende versies met een oplossing voor dit probleem:

  • 4.4.87+
  • 4.9.48+
  • 4.12.11+
  • Alle versies die groter zijn dan of gelijk zijn aan 4.13

Kan geen symbolische koppelingen maken - ln: kan geen symbolische koppeling maken 't': Bewerking wordt niet ondersteund

Oorzaak

Standaard schakelt het koppelen van Azure-bestandsshares in Linux met behulp van SMB geen ondersteuning in voor symbolische koppelingen (symlinks). Mogelijk ziet u een fout zoals deze:

sudo ln -s linked -n t

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

Oplossing

De Linux SMB-client biedt geen ondersteuning voor het maken van symbolische koppelingen in Windows-stijl via het SMB 2- of 3-protocol. Momenteel ondersteunt de Linux-client een andere stijl van symbolische koppelingen met de naam Minshall+French symlinks voor het maken en volgen van bewerkingen . Klanten die symbolische koppelingen nodig hebben, kunnen de koppelingsoptie 'mfsymlinks' gebruiken. We raden 'mfsymlinks' aan, omdat het ook de indeling is die Door Macs wordt gebruikt.

Als u symlinks wilt gebruiken, voegt u het volgende toe aan het einde van de SMB-koppelingsopdracht:

,mfsymlinks

De opdracht ziet er dus als volgt uit:

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

Vervolgens kunt u symlinks maken zoals voorgesteld op de wiki.

Kan geen toegang krijgen tot mappen of bestanden met een spatie of een punt aan het einde

U hebt geen toegang tot mappen of bestanden vanuit de Azure-bestandsshare terwijl deze is gekoppeld in Linux. Opdrachten zoals du en ls en/of toepassingen van derden kunnen mislukken met de fout 'Dergelijke bestanden of mappen niet' tijdens het openen van de share; U kunt echter bestanden uploaden naar deze mappen via Azure Portal.

Oorzaak

De mappen of bestanden zijn geüpload vanuit een systeem dat de tekens aan het einde van de naam codeert naar een ander teken. Bestanden die vanaf een Macintosh-computer zijn geüpload, hebben mogelijk een teken '0xF028' of '0xF029' in plaats van 0x20 (spatie) of 0X2E (punt).

Oplossing

Gebruik de mapchars-optie op de share bij het koppelen van de share in Linux:

In plaats van:

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

Gebruik:

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

DNS-problemen met livemigratie van Azure-opslagaccounts

Bestands-I/Os op het gekoppelde bestandssysteem beginnen met het geven van fouten 'Host is offline' of 'Machtiging geweigerd'. In Linux-dmesg-logboeken op de client worden herhaalde fouten weergegeven, zoals:

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

U ziet ook dat de FQDN van de server nu wordt omgezet in een ander IP-adres dan het ip-adres waarmee deze momenteel is verbonden. Dit probleem kan zich voordoen in elk scenario waarin het IP-adres van de server kan worden gewijzigd, zoals accountmigratie. Een ander bekend scenario is failover van het opslagaccount, omdat de DNS-toewijzing kan worden gewijzigd.

Oorzaak

Voor taakverdelingsdoeleinden voor capaciteit worden opslagaccounts soms live gemigreerd van het ene opslagcluster naar het andere. Met accountmigratie wordt Azure Files-verkeer omgeleid van het broncluster naar het doelcluster door de DNS-toewijzingen bij te werken om naar het doelcluster te verwijzen. Hiermee blokkeert u al het verkeer naar het broncluster vanuit dat account. Er wordt verwacht dat de SMB-client de DNS-updates ophaalt en verder verkeer omleidt naar het doelcluster. Vanwege een fout in de Linux SMB-kernelclient wordt deze omleiding echter niet van kracht. Als gevolg hiervan blijft het gegevensverkeer naar het broncluster gaan, dat na de migratie van dit account is gestopt.

Tijdelijke oplossing

U kunt dit probleem oplossen door het besturingssysteem van de client opnieuw op te starten, maar u kunt het probleem mogelijk opnieuw tegenkomen als u het client-besturingssysteem niet bijwerkt naar een Linux-distributieversie met ondersteuning voor accountmigratie.

Tijdens het ontkoppelen en opnieuw koppelen van de share lijkt het probleem tijdelijk op te lossen, is het geen permanente oplossing. Wanneer de client opnieuw verbinding maakt met de server, kan het probleem zich opnieuw voordoen. De tijdelijke oplossing treedt op omdat een nieuwe koppelingsactie de SMB-kernelcache omzeilt en het DNS-adres in de gebruikersruimte oplost. De kernel-DNS-cache wordt echter gebruikt tijdens een herstel van de netwerkverbinding, waardoor het probleem opnieuw kan optreden. Dit gedrag blijft behouden, zelfs buiten migraties van opslagaccounts.

Als u dit probleem beter wilt omzeilen, wist u de cache van de kernel-DNS-resolver:

  1. Geef de status van de kernelmodule dns_resolver weer door de volgende opdracht uit te voeren:

    grep '.dns_resolver' /proc/keys

    Als het goed is, ziet u de uitvoer van de opdracht, zoals in het volgende voorbeeld:

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

  2. Wis de cache van de kernel-DNS-resolver door de volgende opdracht uit te voeren:

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

  3. De status van de kernelmodule dns_resolver opnieuw weergeven:

    grep '.dns_resolver' /proc/keys

    Als het goed is, ziet u uitvoer van de opdracht zoals in het volgende voorbeeld, waarmee wordt aangegeven dat de cache nu leeg is:

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

  4. Ontkoppel de share en koppel deze opnieuw om het probleem te verhelpen.

Notitie

Bij sommige oudere Linux-distributies werken de risicobeperkingsstappen mogelijk niet. In dergelijke gevallen wordt het probleem tijdelijk opgelost door het besturingssysteem van de client opnieuw op te starten. Voor een permanente oplossing kunt u een privé-eindpunt toevoegen aan uw opslagaccount en verbinding maken met de bestandsshare via een privékoppeling.

Oplossing

Voor een permanente oplossing voert u een upgrade uit van het client-besturingssysteem naar een Linux-distributieversie met ondersteuning voor accountmigratie. Er zijn verschillende oplossingen voor de Linux SMB-kernelclient verzonden naar de mainline Linux-kernel. De volgende distributies hebben de oplossingen:

  • Ubuntu: 20.04, 22.04, 24.04 en AKS 22.04 (de fixes worden geïmplementeerd in kernelversie 5.15.0-1068)
  • RHEL: 8.6+
  • SLES: 15SP2, 15SP3, 15SP4 en 15SP5
  • Azure Linux: 2.0 (de oplossingen worden geïmplementeerd in kernelversie 5.15.159.1) en 3.0

Sommige distributies hebben deze oplossingen gebackporteerd. U kunt controleren of de volgende oplossingen bestaan in de distributieversie die u gebruikt:

Kan de SMB-bestandsshare niet koppelen wanneer FIPS is ingeschakeld

Wanneer Federal Information Processing Standard (FIPS) is ingeschakeld in een Linux-VM, kan de SMB-bestandsshare niet worden gekoppeld. In de Linux-dmesg-logboeken op de client worden fouten weergegeven, zoals:

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

Belangrijk

FIPS is een set standaarden die de Amerikaanse overheid gebruikt om de beveiliging en integriteit van computersystemen te waarborgen. Wanneer een systeem zich in de FIPS-modus bevindt, voldoet het aan specifieke cryptografische vereisten die door deze standaarden worden beschreven.

Oorzaak

De client van de SMB-bestandsshare maakt gebruik van de NTLMSSP-verificatie, waarvoor het MD5-hashingalgoritme is vereist. In de FIPS-modus is het MD5-algoritme echter beperkt omdat het niet fips-compatibel is. MD5 is een veelgebruikte hash-functie die een 128-bits hashwaarde produceert. MD5 wordt echter als onveilig beschouwd voor cryptografische doeleinden.

Controleren of de FIPS-modus is ingeschakeld

Voer de volgende opdracht uit om te controleren of de FIPS-modus is ingeschakeld op de client. Als de waarde is ingesteld op 1, is FIPS ingeschakeld.

sudo cat /proc/sys/crypto/fips_enabled

Oplossing

U kunt dit probleem oplossen door Kerberos-verificatie in te schakelen voor SMB-bestandsshares. Als FIPS onbedoeld is ingeschakeld, raadpleegt u optie2 om deze uit te schakelen.

Optie 1: Kerberos-verificatie inschakelen voor SMB-bestandsshare

Als u een SMB-bestandsshare wilt koppelen op de Linux-VM waarop FIPS is ingeschakeld, gebruikt u Kerberos-/Azure AD-verificatie. Zie Active Directory-verificatie inschakelen via SMB voor Linux-clients die toegang hebben tot Azure Files voor meer informatie.

Optie 2: FIPS uitschakelen om de Samba-share te koppelen

  1. Wijzig de sysctl-waarde van crypto.fips_enabled 0 in /etc/sysctl.conf.

  2. Wijzig het GRUB_CMDLINE_LINUX_DEFAULT bestand /etc/default/grub en verwijder de parameter fips=1.

  3. Herbouw het grub2-configuratiebestand met de volgende opdracht:

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

  4. Bouw de initramfs-installatiekopieën opnieuw met de volgende opdracht:

    sudo dracut -fv

  5. Start de VM opnieuw op.

Zie de volgende documenten van Linux-distributeurs voor meer informatie:

Hulp nodig?

Als u nog steeds hulp nodig hebt, neemt u contact op met de ondersteuning om het probleem snel op te lossen.

Zie ook

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.