Problembehandlung für NFS-Azure-Dateifreigaben

Dieser Artikel listet häufige Probleme im Zusammenhang mit NFS-Azure-Dateifreigaben auf und enthält mögliche Ursachen und Problemumgehungen.

Wichtig

Der Inhalt dieses Artikels gilt nur für NFS-Freigaben. Informationen zur Behandlung von SMB-Problemen unter Linux finden Sie unter Behandeln Azure Files Probleme unter Linux (SMB). NFS-Azure-Dateifreigaben werden für Windows nicht unterstützt.

Gilt für

Dateifreigabetyp SMB NFS
Standarddateifreigaben (GPv2), LRS/ZRS
Standarddateifreigaben (GPv2), GRS/GZRS
Premium-Dateifreigaben (FileStorage), LRS/ZRS

chgrp "filename" failed: Invalid argument (22)

Ursache 1: idmapping ist nicht deaktiviert

Da Azure Files alphanumerische UID/GID nicht zuzulassen, müssen Sie idmapping deaktivieren.

Ursache 2: idmapping wurde deaktiviert, wurde aber erneut aktiviert, nachdem ein ungültiger Datei-/Dir-Name aufgetreten ist.

Auch wenn Sie idmapping ordnungsgemäß deaktivieren, kann es in einigen Fällen automatisch erneut aktiviert werden. Wenn Azure Files beispielsweise auf einen ungültigen Dateinamen stößt, wird ein Fehler zurück gesendet. Wenn dieser Fehlercode angezeigt wird, beschließt ein NFS 4.1 Linux-Client, idmapping erneut zu aktivieren, und sendet zukünftige Anforderungen mit alphanumerischer UID/GID. Eine Liste der nicht unterstützten Zeichen für Azure Files finden Sie in diesem Artikel. Doppelpunkt ist eines der nicht unterstützten Zeichen.

Problemumgehung

Stellen Sie sicher, dass Sie idmapping deaktiviert haben und dass es nicht erneut aktiviert wird. Führen Sie dann die folgenden Schritte aus:

  1. Heben Sie die Bereitstellung der Freigabe auf.

  2. Deaktivieren Sie idmapping mit:

    sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
    
  3. Binden Sie die Freigabe wieder ein.

  4. Wenn Sie rsync ausführen, führen Sie rsync mit dem —numeric-ids Argument aus einem Verzeichnis aus, das keinen ungültigen Verzeichnis- oder Dateinamen aufweist.

Erstellen einer NFS-Freigabe nicht möglich

Ursache: Einstellungen für nicht unterstützte Speicherkonten

NFS ist nur für Speicherkonten mit der folgenden Konfiguration verfügbar:

Lösung

Befolgen Sie die Anweisungen unter Erstellen einer NFS-Freigabe.

Es kann keine Verbindung mit einer NFS-Azure-Dateifreigabe hergestellt oder eingebunden werden.

Ursache 1: Die Anforderung stammt von einem Client in einem nicht vertrauenswürdigen Netzwerk oder einer nicht vertrauenswürdigen IP-Adresse.

Im Gegensatz zu SMB verfügt NFS nicht über eine benutzerbasierte Authentifizierung. Die Authentifizierung für eine Freigabe basiert auf der Konfiguration Ihrer Netzwerksicherheitsregel. Um sicherzustellen, dass Clients nur sichere Verbindungen mit Ihrer NFS-Freigabe herstellen, müssen Sie entweder den Dienstendpunkt oder private Endpunkte verwenden. Sie müssen eine VPN- oder ExpressRoute-Verbindung einrichten, um nicht nur über private Endpunkte auf lokale Freigaben zugreifen zu können. IP-Adressen, die der Positivliste des Speicherkontos für die Firewall hinzugefügt wurden, werden ignoriert. Sie müssen eine der folgenden Methoden verwenden, um den Zugriff auf eine NFS-Freigabe einzurichten:

  • Dienstendpunkt

    • Auf den öffentlichen Endpunkt kann zugegriffen werden.

    • Nur in derselben Region verfügbar.

    • Sie können kein VNET-Peering für den Freigabezugriff verwenden.

    • Sie müssen jedes virtuelle Netzwerk oder Subnetz einzeln zur Positivliste hinzufügen.

    • Für den lokalen Zugriff können Sie Dienstendpunkte mit ExpressRoute-, Point-to-Site- und Site-to-Site-VPNs verwenden. Es wird empfohlen, einen privaten Endpunkt zu verwenden, da er sicherer ist.

      Das folgende Diagramm zeigt die Konnektivität mit öffentlichen Endpunkten:

      Diagramm der Konnektivität öffentlicher Endpunkte.

  • Privater Endpunkt

    • Der Zugriff ist sicherer als der Dienstendpunkt.

    • Der Zugriff auf die NFS-Freigabe über Private Link ist innerhalb und außerhalb der Azure-Region des Speicherkontos (regionsübergreifend, lokal) verfügbar.

    • Das Peering virtueller Netzwerke mit virtuellen Netzwerken, die im privaten Endpunkt gehostet werden, gibt der NFS-Freigabe Zugriff auf die Clients in virtuellen Netzwerken mit Peering.

    • Sie können private Endpunkte mit ExpressRoute, Point-to-Site-VPNs und Site-to-Site-VPNs verwenden.

      Diagramm der Konnektivität privater Endpunkte.

Ursache 2: Sichere Übertragung erforderlich ist aktiviert

NFS-Azure-Dateifreigaben unterstützen derzeit keine doppelte Verschlüsselung. Azure bietet eine Verschlüsselungsebene für alle Daten, die zwischen Azure-Rechenzentren mit MACSec übertragen werden. Sie können nur über vertrauenswürdige virtuelle Netzwerke und über VPN-Tunnel auf NFS-Freigaben zugreifen. Für NFS-Freigaben ist keine zusätzliche Transportschichtverschlüsselung verfügbar.

Lösung

Deaktivieren Sie auf dem Konfigurationsblatt Ihres Speicherkontos die Option Sichere Übertragung erforderlich .

Screenshot: Blatt

Ursache 3: das Paket nfs-utils, nfs-client oder nfs-common ist nicht installiert.

Installieren Sie vor dem Ausführen des mount Befehls das Paket nfs-utils, nfs-client oder nfs-common.

Führen Sie Folgendes aus, um zu überprüfen, ob das NFS-Paket installiert ist:

Die gleichen Befehle in diesem Abschnitt gelten für CentOS und Oracle Linux.

sudo rpm -qa | grep nfs-utils

Lösung

Wenn das Paket nicht installiert ist, installieren Sie das Paket mit Ihrem distributionsspezifischen Befehl.

Die gleichen Befehle in diesem Abschnitt gelten für CentOS und Oracle Linux.

Betriebssystemversion 7.X

sudo yum install nfs-utils

Betriebssystemversion 8.X oder 9.X

sudo dnf install nfs-utils

Ursache 4: Firewall blockiert Port 2049

Das NFS-Protokoll kommuniziert mit seinem Server über Port 2049. Stellen Sie sicher, dass dieser Port für das Speicherkonto (den NFS-Server) geöffnet ist.

Lösung

Vergewissern Sie sich, dass Port 2049 auf Ihrem Client geöffnet ist, indem Sie den folgenden Befehl ausführen. Wenn der Port nicht geöffnet ist, öffnen Sie ihn.

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

ls hängt für große Verzeichnisenumeration auf einigen Kernels

Ursache: In Linux-Kernel v5.11 wurde ein Fehler eingeführt und in v5.12.5 behoben.

Einige Kernelversionen weisen einen Fehler auf, der dazu führt, dass Verzeichnisauflistungen zu einer endlosen READDIR-Sequenz führen. Kleine Verzeichnisse, in denen alle Einträge in einem Anruf versendet werden können, haben dieses Problem nicht. Der Fehler wurde im Linux-Kernel v5.11 eingeführt und in v5.12.5 behoben. Alles dazwischen hat also den Fehler. RHEL 8.4 verfügt über diese Kernelversion.

Problemumgehung: Herabstufen oder Aktualisieren des Kernels

Das Problem sollte durch Herabstufen oder Upgraden des Kernels auf etwas außerhalb des betroffenen Kernels behoben werden.

Der Befehl schlägt mit dem Fehler "Datei nicht gefunden" fehl

Ursache

Systemaufrufe wie stat() und readdir() schlagen möglicherweise bei älteren 32-Bit-Versionen der Oracle E-Business-Suite fehl, die 32-Bit-Datei-E/A-Schnittstellen anstelle von 64-Bit-Inode-Nummern verwenden.

Lösung

Sie können diesen Fehler beheben, indem Sie die nfs.enable_ino64=0 kernel Startoption verwenden, um die 64-Bit-Inode-Nummern auf 32 Bit zu komprimieren. Informationen zum Aktivieren von Kernelstartoptionen finden Sie in der Dokumentation Ihrer Distribution.

Benötigen Sie Hilfe?

Wenn Sie weiterhin Hilfe benötigen, wenden Sie sich an den Support , um Ihr Problem schnell zu beheben.

Siehe auch

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.