Delen via

Problemen met NFS Azure-bestandsshares oplossen

  • Artikel

Notitie

CentOS waarnaar in dit artikel wordt verwezen, is een Linux-distributie en bereikt het einde van de levensduur (EOL). Houd rekening met uw gebruik en plan dienovereenkomstig. Zie De richtlijnen voor het einde van de levensduur van CentOS voor meer informatie.

Dit artikel bevat veelvoorkomende problemen met betrekking tot NFS Azure-bestandsshares en biedt mogelijke oorzaken en tijdelijke oplossingen.

Belangrijk

De inhoud van dit artikel is alleen van toepassing op NFS-shares. Als u SMB-problemen in Linux wilt oplossen, raadpleegt u Problemen met Azure Files in Linux (SMB) oplossen. NFS Azure-bestandsshares worden niet ondersteund voor Windows.

Van toepassing op

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

chgrp 'bestandsnaam' is mislukt: ongeldig argument (22)

Oorzaak 1: idmapping is niet uitgeschakeld

Omdat Azure Files alfanumerieke UID/GID niet toekent, moet u idmapping uitschakelen.

Oorzaak 2: idmapping is uitgeschakeld, maar opnieuw ingeschakeld na het tegenkomen van een ongeldig bestand/dir-naam

Zelfs als u idmapping correct uitschakelt, kan het in sommige gevallen automatisch opnieuw worden ingeschakeld. Wanneer Azure Files bijvoorbeeld een ongeldige bestandsnaam tegenkomt, wordt er een fout teruggestuurd. Wanneer u deze foutcode ziet, besluit een NFS 4.1 Linux-client om idmapping opnieuw in te schakelen en toekomstige aanvragen te verzenden met alfanumerieke UID/GID. Zie dit artikel voor een lijst met niet-ondersteunde tekens in Azure Files. Dubbele punt is een van de niet-ondersteunde tekens.

Tijdelijke oplossing

Zorg ervoor dat u idmapping hebt uitgeschakeld en dat er niets opnieuw wordt ingeschakeld. Voer vervolgens de volgende stappen uit:

  1. Ontkoppel de share.

  2. Idmapping uitschakelen met:

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

  3. Koppel de share terug.

  4. Als u rsync uitvoert, voert u rsync uit met het —numeric-ids argument uit een map die geen onjuiste map of bestandsnaam heeft.

Kan geen NFS-share maken

Oorzaak: Niet-ondersteunde opslagaccountinstellingen

NFS is alleen beschikbaar voor opslagaccounts met de volgende configuratie:

Oplossing

Volg de instructies in Een NFS-share maken.

Kan geen verbinding maken met of koppelen aan een NFS Azure-bestandsshare

Oorzaak 1: Aanvraag is afkomstig van een client in een niet-vertrouwd netwerk/niet-vertrouwd IP-adres

In tegenstelling tot SMB heeft NFS geen verificatie op basis van gebruikers. De verificatie voor een share is gebaseerd op de configuratie van uw netwerkbeveiligingsregel. Om ervoor te zorgen dat clients alleen beveiligde verbindingen met uw NFS-share tot stand brengen, moet u het service-eindpunt of de privé-eindpunten gebruiken. Als u naast privé-eindpunten toegang wilt krijgen tot shares vanaf on-premises, moet u een VPN- of ExpressRoute-verbinding instellen. IP-adressen die zijn toegevoegd aan de acceptatielijst van het opslagaccount voor de firewall, worden genegeerd. U moet een van de volgende methoden gebruiken om toegang tot een NFS-share in te stellen:

  • Service-eindpunt

    • Toegankelijk voor het openbare eindpunt.

    • Alleen beschikbaar in dezelfde regio.

    • U kunt geen sharetoegang verkrijgen met VNet-peering.

    • U moet elk virtueel netwerk of subnet afzonderlijk toevoegen aan de acceptatielijst.

    • Voor on-premises toegang kunt u service-eindpunten gebruiken met ExpressRoute, point-naar-site- en site-naar-site-VPN's. We raden aan een privé-eindpunt te gebruiken omdat dit veiliger is.

      In het volgende diagram ziet u connectiviteit met behulp van openbare eindpunten:

      Diagram van connectiviteit met openbare eindpunten.

  • Privé-eindpunt

    • Toegang is veiliger dan het service-eindpunt.

    • Toegang tot NFS-share via privékoppeling is beschikbaar van binnen en buiten de Azure-regio van het opslagaccount (cross-regio, on-premises).

    • Peering van virtuele netwerken met virtuele netwerken die worden gehost in het privé-eindpunt geeft de NFS-share toegang tot de clients in virtuele netwerken met peering.

    • U kunt privé-eindpunten gebruiken met ExpressRoute, point-naar-site-VPN's en site-naar-site-VPN's.

      Diagram van connectiviteit met privé-eindpunten.

Oorzaak 2: Veilige overdracht is ingeschakeld

NFS Azure-bestandsshares bieden momenteel geen ondersteuning voor dubbele versleuteling. Azure biedt een laag versleuteling voor alle gegevens die worden verzonden tussen Azure-datacenters met behulp van MACSec. U hebt alleen toegang tot NFS-shares van vertrouwde virtuele netwerken en via VPN-tunnels. Er is geen extra transportlaagversleuteling beschikbaar op NFS-shares.

Oplossing

Schakel Beveiligde overdracht uit die is vereist op de configuratieblade van uw opslagaccount.

Schermopname van de blade configuratie van het opslagaccount, waarbij beveiligde overdracht is uitgeschakeld.

Oorzaak 3: nfs-utils, nfs-client of nfs-common pakket is niet geïnstalleerd

Voordat u de mount opdracht uitvoert, installeert u het pakket nfs-utils, nfs-client of nfs-common.

U kunt controleren of het NFS-pakket is geïnstalleerd met de volgende opdracht:

Dezelfde opdrachten in deze sectie zijn van toepassing op CentOS en Oracle Linux.

sudo rpm -qa | grep nfs-utils

Oplossing

Als het pakket niet is geïnstalleerd, installeert u het pakket met behulp van uw distributiespecifieke opdracht.

Dezelfde opdrachten in deze sectie zijn van toepassing op CentOS en Oracle Linux.

Versie 7.X van het besturingssysteem

sudo yum install nfs-utils

Besturingssysteemversie 8.X of 9.X

sudo dnf install nfs-utils

Oorzaak 4: Firewall blokkeert poort 2049

Het NFS-protocol communiceert met de server via poort 2049. Zorg ervoor dat deze poort is geopend voor het opslagaccount (de NFS-server).

Oplossing

Controleer of poort 2049 is geopend op uw client door de volgende opdracht uit te voeren. Als de poort niet is geopend, opent u deze.

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

Oorzaak 5: Opslagaccount verwijderd

Als u de bestandsshare niet kunt koppelen vanwege een fout: er is een time-out opgetreden voor de verbinding, kan het opslagaccount met de bestandsshare per ongeluk worden verwijderd.

Oplossing

Herstel het opslagaccount. Verwijder vervolgens het privé-eindpunt en maak het opnieuw, zodat het is gekoppeld aan de resource-id van het nieuwe opslagaccount.

ls loopt vast voor grote directory-inventarisatie op sommige kernels

Oorzaak: Er is een fout geïntroduceerd in Linux-kernel v5.11 en is opgelost in v5.12.5

Sommige kernelversies hebben een fout waardoor directoryvermeldingen resulteren in een eindeloze READDIR-reeks. Kleine mappen waarin alle vermeldingen in één gesprek kunnen worden verzonden, hebben dit probleem niet. De fout is geïntroduceerd in Linux-kernel v5.11 en is opgelost in v5.12.5. Dus alles tussendoor heeft de bug. RHEL 8.4 heeft deze kernelversie.

Tijdelijke oplossing: de kernel downgraden of upgraden

Het probleem kan worden opgelost door de kernel te downgraden of te upgraden naar iets buiten de betreffende kernel.

Systeemopdrachten mislukken met de fout 'Bestand niet gevonden'

Oorzaak

Linux 32-bits toepassingen die afhankelijk zijn van inode-getallen werken mogelijk niet zoals verwacht met Azure Files vanwege de opmaak van de 64-bits inode-getallen die door de NFS-service worden gegenereerd.

Oplossing

Gebruik een van de volgende methoden om dit op te lossen:

  • Comprimeer de 64-bits inode-getallen naar 32 bits met behulp van de nfs.enable_ino64=0 kernel-opstartoptie.

  • Stel de moduleparameter in door het bestand /etc/modprobe.d/nfs.conf toe te voegen options nfs enable_ino64=0 en de virtuele machine opnieuw op te starten.

U kunt deze kernel-opstartoptie ook behouden in het bestand grub.conf . Zie de documentatie voor uw Linux-distributie voor meer informatie.

Kan het eigendom van bestanden en mappen niet wijzigen

Oorzaak

Machtigingen voor NFS-bestandsshares worden afgedwongen door het client-besturingssysteem in plaats van de Azure Files-service. Als de instelling Root Squash is ingeschakeld op een NFS-bestandsshare, wordt de hoofdgebruiker op het clientsysteem behandeld als een anonieme (niet-bevoegde) gebruiker voor toegangsbeheerdoeleinden. Dit betekent dat zelfs als u bent aangemeld als root op het clientsysteem, u de chown opdracht niet kunt gebruiken om het eigendom te wijzigen van bestanden en mappen die u niet bezit.

Oplossing

Navigeer in Azure Portal naar de bestandsshare en selecteer Eigenschappen. Wijzig de instelling Root Squash in No Root Squash. Zie Root squash configureren voor Azure Files voor meer informatie.

Als Geen root squash is ingeschakeld, heeft de hoofdgebruiker op het clientsysteem dezelfde bevoegdheden als de hoofdgebruiker op het serversysteem. U kunt nu het chown eigendom van een bestand of map in de share wijzigen, ongeacht de huidige eigenaar. Nadat u de wijzigingen hebt aangebracht, kunt u root squash indien nodig opnieuw inschakelen.

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.