Dela via

Felsöka NFS Azure-filresurser

  • Artikel

Obs!

CentOS som refereras i den här artikeln är en Linux-distribution och kommer att nå End Of Life (EOL). Överväg din användning 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

Filresurstyp SMB NFS
Standardfilresurser (GPv2), LRS/ZRS
Standardfilresurser (GPv2), GRS/GZRS
Premium-filresurser (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 automatiskt återaktiveras i vissa fall. När Azure Files till exempel påträffar 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 på Azure Files finns i den här artikeln. Kolon är ett av de tecken som inte stöds.

Lösning

Kontrollera att du har inaktiverat idmappning och att ingenting återaktiverar den. 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 Så här skapar du 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 klienterna bara 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

    • Nås av den offentliga slutpunkten.

    • Endast tillgängligt 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 nätverk.

    • 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 hjälp av offentliga slutpunkter:

      Diagram över anslutningen till den offentliga slutpunkten.

  • Privat slutpunkt

    • Åtkomst är säkrare än tjänstslutpunkten.

    • Å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 peerkopplade virtuella nätverk.

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

      Diagram över anslutning till privat slutpunkt.

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 transportlager på NFS-resurser.

Lösning

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

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

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

Innan du kör mount 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. Om porten inte är öppen öppnar du den.

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

Orsak 5: Lagringskontot har tagits bort

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

Lösning

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

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

Orsak: Ett fel introducerades i Linux-kernel 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 levereras i ett anrop har inte det här problemet. Buggen introducerades i Linux kernel v5.11 och åtgärdades 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å inodnummer 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 en 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 kernel-startalternativet i grub.conf-filen . Mer information finns i dokumentationen för din Linux-distribution.

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.