Dela via

Felsöka NFS Azure-filresurser

  • Artikel

Kommentar

CentOS som refereras i den här artikeln är en Linux-distribution och kommer att nå End Of Life (EOL). Överväg att använda och planera i enlighet med detta. 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 ger 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). NFS Azure-filresurser stöds inte för Windows.

Gäller för

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

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: idmappning har inaktiverats, men återaktiverades efter att ett felaktigt fil-/dir-namn påträffades

Även om du inaktiverar idmappning korrekt kan den aktiveras automatiskt igen 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/GID. En lista över tecken som inte stöds i Azure Files finns i den här artikeln. Colon är ett av de tecken som inte stöds.

Lösning

Kontrollera att du har inaktiverat idmappning och att inget aktiverar det igen. Utför sedan följande steg:

  1. Demontera resursen.

  2. Inaktivera idmappning med:

    sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping

  3. Montera tillbaka resursen.

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

Det går inte att skapa en NFS-resurs

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

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

Lösning

Följ anvisningarna i Skapa en NFS-resurs.

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/ej betrodd IP

Till skillnad från SMB har NFS inte användarbaserad autentisering. Autentiseringen för en resurs baseras på konfigurationen av nätverkssäkerhetsregeln. 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- eller ExpressRoute-anslutning. IP-adresser som lagts till i lagringskontots tillåtna lista för brandväggen ignoreras. Du måste använda någon av följande metoder för att konfigurera åtkomst till en NFS-resurs:

  • Tjänstslutpunkt

    • Kan kommas åt av 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. Vi rekommenderar att du använder 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 för virtuella nätverk med virtuella nätverk som finns i den privata slutpunkten ger NFS-resursen åtkomst till klienterna i virtuella peer-kopplade 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: Säker överföring krävs är aktiverad

NFS Azure-filresurser stöder för närvarande inte dubbel kryptering. Azure tillhandahåller ett krypteringslager för alla data som överförs mellan Azure-datacenter med hjälp av MACSec. Du kan bara komma åt NFS-resurser från betrodda virtuella nätverk och via VPN-tunnlar. Det finns ingen extra kryptering för transportskiktet på NFS-resurser.

Lösning

Inaktivera Säker överföring som krävs på lagringskontots konfigurationsblad.

Skärmbild som visar konfigurationsbladet för lagringskontot, vilket inaktiverar säker överföring som krävs.

Orsak 3: 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 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 4: 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 5: 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.

ls låser sig för uppräkning av stora kataloger på vissa kernels

Orsak: En bugg introducerades i Linux-kerneln v5.11 och har åtgärdats 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 levereras i ett anrop har inte det här problemet. Felet introducerades i Linux kernel v5.11 och har åtgärdats i v5.12.5. Så allt däremellan har buggen. RHEL 8.4 har den här kernelversionen.

Lösning: Nedgradera eller uppgradera kerneln

Du bör lösa problemet genom att nedgradera eller uppgradera kerneln till något utanför den berörda kerneln.

Systemkommandon misslyckas med felet "Filen hittades inte"

Orsak

Linux 32-bitarsprogram som förlitar sig på inode-nummer kanske inte fungerar som förväntat med Azure Files på grund av formateringen av de 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-talen till 32 bitar med hjälp nfs.enable_ino64=0 av alternativet kernelstart.

  • 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

Behörigheter för NFS-filresurser framtvingas av klientoperativsystemet i stället för Azure Files-tjänsten. Om root Squash-inställningen är aktiverad på en NFS-filresurs behandlas rotanvändaren i klientsystemet som en anonym (icke-privilegierad) användare i åtkomstkontrollsyfte. Det innebär att även om du är inloggad som rot i klientsystemet kan du inte använda chown kommandot för att ändra ägarskapet för filer och kataloger som du inte äger.

Lösning

I Azure Portal navigerar du till filresursen och väljer Egenskaper. Ändra inställningen Rot squash till Ingen rot squash. Mer information finns i Konfigurera rot squash för Azure Files.

Utan Root Squash aktiverat 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

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.