Felsöka NFS Azure-filresurser
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:
Demontera resursen.
Inaktivera idmappning med:
sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
Montera tillbaka resursen.
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:
- Nivå – Premium
- Typ av konto – FileStorage
- Regioner – Lista över regioner som stöds
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:
-
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:
-
Å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.
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.
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
- Felsöka Azure Files
- Felsöka Azure Files prestanda
- Felsöka Azure Files-anslutning (SMB)
- Felsöka Azure Files autentisering och auktorisering (SMB)
- Felsöka Azure Files allmänna SMB-problem i Linux
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.
Feedback
https://aka.ms/ContentUserFeedback.
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i:Skicka och visa feedback för