Felsöka Azure NFS fildelningar

Gäller för: ✔️ Azure-filresurser för NFS

Kommentar

CentOS som refereras i den här artikeln är en Linux-distribution och kommer att nå End Of Life (EOL). Överväg hur du använder och planera därefter. Mer information finns i CentOS End Of Life-vägledning.

Den här artikeln innehåller vanliga problem som rör NFS-Azure filresurser och innehåller potentiella orsaker och lösningar.

Viktigt!

Innehållet i den här artikeln gäller endast för NFS-resurser. Information om hur du felsöker SMB-problem i Linux finns i Felsöka Azure Files problem i Linux (SMB). Azure NFS-fildelningar stöds inte på Windows.

Använda verktyget Always-On Diagnostics

Du kan använda verktyget Always-On Diagnostics (AOD) för att samla in loggar på NFSv4- och SMB 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, mountstsat och andra källor, tillsammans med systemets cpu- och minnesanvändning. Verktyget är användbart för att samla in felsökningsinformation om fältproblem som är svåra att återskapa.

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:

Viktigt!

Always-On Diagnostik stöder inte NFS-volymer med kryptering under överföring aktiverat. Om du vill aktivera logginsamling på den berörda NFS-resursen måste du montera resursen utan EiT.

I RHEL 8 följer du de här anvisningarna för att installera verktyget Always-On Diagnostics:

  1. Ladda ned lagringsplatsens konfigurationspaket.

    curl -ssl -O https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm
    
  2. Installera lagringsplatsens konfigurationspaket.

    sudo rpm -i packages-microsoft-prod.rpm
    
  3. Ta bort lagringsplatsens konfigurationspaket när du har installerat och uppdaterat paketindexfilerna.

    rm packages-microsoft-prod.rpm
    sudo dnf update
    
  4. Installera paketet .

    sudo dnf install aod
    

chgrp "filename" misslyckades: Ogiltigt argument (22)

Orsak 1: idmappning är inte inaktiverat

Eftersom Azure Files inte tillåter alfanumeriskt UID/GID måste du inaktivera idmappning.

Orsak 2: Inaktiverad idmappning aktiveras igen efter att det har uppstått ett felaktigt fil- eller katalognamn

Även om du inaktiverar idmappning kan systemet automatiskt återaktivera det i vissa fall. När Azure Files till exempel stöter på ett felaktigt filnamn skickar det tillbaka ett fel. När den här felkoden visas bestämmer sig en NFS 4.1 Linux-klient för att återaktivera idmappning och skickar framtida begäranden med alfanumeriskt UID eller GID. En lista över tecken som inte stöds på Azure Files finns i Namnge och referera till resurser, kataloger, filer och metadata. Colon är ett av de tecken som inte stöds.

Lösning

Se till att du inaktiverar idmappning och att inget återaktiverar det. Utför sedan följande steg:

  1. Avmontera delningen.

  2. Inaktivera idmappning genom att köra följande kommando:

    sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
    
  3. Montera tillbaka delningen.

  4. Om du kör rsync, kör rsync med argumentet -numeric-ids från en katalog som inte har ett ogiltigt katalog- eller filnamn.

Det går inte att skapa en NFS-delning

Orsak: Inställningar för lagringskonton som inte stöds

NFS är endast tillgängligt på lagringskonton med följande konfiguration:

  • Nivå: Premium
  • Kontotyp: FileStorage

Lösning

Följ anvisningarna i Skapa en NFS-filresurs.

Det går inte att ansluta till eller montera en NFS-Azure filresurs

Orsak 1: Begäran kommer från en klient i ett ej betrott nätverk eller en ip-adress som inte är betrodd

Till skillnad från SMB stöder NFS inte användarbaserad autentisering. Autentisering för en resursdelning beror på hur dina nätverkssäkerhetsregler är konfigurerade. För att säkerställa att klienter endast upprättar säkra anslutningar till din NFS-resurs måste du använda antingen tjänstslutpunkten eller privata slutpunkter. Om du vill komma åt resurser från en lokal plats utöver privata slutpunkter måste du konfigurera en VPN-anslutning eller Azure ExpressRoute anslutning. Brandväggen för lagringskontot ignorerar IP-adresser som lagts till i listan över tillåtna. Om du vill konfigurera åtkomst till en NFS-resurs använder du någon av följande metoder:

  • Tjänstslutpunkt

    • Åtkomst sker via den offentliga slutpunkten.

    • Endast tillgänglig i samma region.

    • Du kan inte använda VNet-peering för resursåtkomst.

    • Du måste lägga till varje virtuellt nätverk eller undernät individuellt i listan över tillåtna.

    • För lokal åtkomst kan du använda tjänstslutpunkter med ExpressRoute, punkt-till-plats- och plats-till-plats-VPN. Använd en privat slutpunkt eftersom den är säkrare.

      Följande diagram visar anslutningen med offentliga slutpunkter:

      Diagram över offentlig slutpunktsanslutning.

  • Privat slutpunkt

    • Åtkomst är säkrare än tjänstens slutpunkt.

    • Åtkomst till NFS-resurs via privat länk är tillgänglig från och utanför lagringskontots Azure region (mellan regioner, lokalt).

    • Peering mellan virtuella nätverk och de som är kopplade till en privat slutpunkt ger NFS-delningen åtkomst till klienterna i peerkopplade virtuella nätverk.

    • Du kan använda privata slutpunkter med ExpressRoute, punkt-till-plats-VPN och plats-till-plats-VPN.

      Diagram över privat slutpunktsanslutning.

Orsak 2: nfs-utils, nfs-client eller nfs-common-paketet är inte installerat

Innan du mount kör kommandot installerar du paketet nfs-utils, nfs-client eller nfs-common.

Kontrollera om NFS-paketet är installerat genom att köra:

Samma kommandon i det här avsnittet gäller för CentOS och Oracle Linux.

sudo rpm -qa | grep nfs-utils

Lösning

Om paketet inte är installerat installerar du paketet med hjälp av ditt distributionsspecifika kommando.

Samma kommandon i det här avsnittet gäller för CentOS och Oracle Linux.

OS-version 7.X

sudo yum install nfs-utils

OS Version 8.X eller 9.X

sudo dnf install nfs-utils

Orsak 3: Brandväggen blockerar port 2049

NFS-protokollet kommunicerar med servern via port 2049. Kontrollera att porten är öppen för lagringskontot (NFS-servern).

Lösning

Kontrollera att port 2049 är öppen på klienten genom att köra följande kommando. Öppna porten om den inte är öppen.

sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049

Orsak 4: Lagringskontot har tagits bort

Om det inte går att montera filresursen på grund av ett fel: tidsgränsen för anslutningen har överskrids kan lagringskontot som innehåller filresursen tas bort av misstag.

Lösning

Återställ lagringskontot. Ta sedan bort och återskapa den privata slutpunkten så att den associeras med det nya resurs-ID:t för lagringskontot.

Orsak 5: Du försöker montera resursen med NFS-klientmonteringen i stället för AZNFS-monteringshjälpen, och inställningen Säker överföring som krävs och/eller Kräv kryptering under överföring för NFS är aktiverad på lagringskontot.

Inställningen Säker överföring krävs framtvingar kryptering under överföring för alla filresurser i lagringskontot såvida inte inställningen Kräv kryptering under överföring för NFS är aktiverad, i vilket fall Säker överföring som krävs endast gäller för REST/HTTPS-trafik. För NFS-filresurser kräver kryptering under överföring montering av resursen med hjälp av AZNFS Mount Helper, ett klientverktygspaket som sammanfattar komplexiteten i att upprätta säkra tunnlar för NFSv4.1-trafik.

Lösning

Inaktivera antingen både inställningen Säker överföring krävs och inställningen Kräv kryptering under överföring för NFS på lagringskontot eller använd AZNFS-monteringshjälpen för att montera resursen. Mer information finns i Kryptering under överföring för NFS Azure filresurser.

ls hänger sig vid uppräkning av stora kataloger på vissa kernlar

Orsak: Ett fel introducerades i Linux-kerneln v5.11 och åtgärdades i v5.12.5

Vissa kernelversioner har en bugg som gör att kataloglistor resulterar i en oändlig READDIR-sekvens. Små kataloger där alla poster kan skickas i ett enda anrop har inte det här problemet. Felet introducerades i Linux kernel v5.11 och åtgärdades i v5.12.5. Så alla versioner däremellan har buggen. RHEL 8.4 använder den här kernelversionen.

Lösning: Nedgradera eller uppgradera kerneln

Nedgradera eller uppgradera kerneln till en version utanför det berörda intervallet för att lösa problemet.

Systemkommandon misslyckas med felet "Filen hittades inte"

Orsak

Linux 32-bitarsprogram som förlitar sig på innodnummer kanske inte fungerar som förväntat med Azure Files på grund av formateringen av 64-bitars inode-tal som genereras av NFS-tjänsten.

Lösning

Använd någon av följande metoder för att lösa problemet:

  • Komprimera 64-bitars inode-nummer till 32 bitar med hjälp av kernel boot-alternativet nfs.enable_ino64=0.

  • Ange modulparametern genom att lägga options nfs enable_ino64=0 till i filen /etc/modprobe.d/nfs.conf och starta om den virtuella datorn.

Du kan också spara det här alternativet för kernelstart i grub.conf-filen . Mer information finns i dokumentationen för din Linux-distribution.

Det går inte att ändra ägarskapet för filer och kataloger

Orsak

Klientoperativsystemet tillämpar behörigheter på NFS-filresurser, inte Azure Files-tjänsten. Om du aktiverar root squash-inställningen på en NFS-filresurs blir rotanvändaren i klientsystemet en anonym (icke-privilegierad) användare i åtkomstkontrollsyfte. Den här begränsningen chown innebär att även om du är inloggad som rot i klientsystemet kan du inte använda kommandot för att ändra ägarskapet för filer och kataloger som du inte äger.

Lösning

I Azure-portalen går du till filresursen och väljer Egenskaper. Ändra inställningen Root Squash till No Root Squash. Mer information finns i Konfigurera rot squash för Azure Files.

När du aktiverar No Root Squash har rotanvändaren i klientsystemet samma behörigheter som rotanvändaren i serversystemet. Du kan nu använda chown för att ändra ägarskapet för en fil eller katalog i resursen, oavsett aktuell ägare. När du har genomfört ändringarna kan du återaktivera Root Squash om det behövs.

Behöver du hjälp?

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

Se även

Ansvarsfriskrivning för information från tredje part

De produkter från tredje part som beskrivs i den här artikeln tillverkas av företag som är oberoende av Microsoft. Microsoft ger ingen garanti, underförstådd eller på annat sätt, om dessa produkters prestanda eller tillförlitlighet.