Behandeln von Problemen mit Azure-NFS-Dateifreigaben

In diesem Artikel werden häufige Probleme im Zusammenhang mit NFS Azure-Dateifreigaben aufgeführt und mögliche Ursachen und Problemumgehungen bereitgestellt.

Gilt für:

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

Fehler bei chgrp "Dateiname": Ungültiges Argument (22)

Ursache 1: idmapping ist nicht deaktiviert.

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

Ursache 2: idmapping wurde deaktiviert, wurde jedoch wieder aktiviert, nachdem ein ungültiger Datei-/Verzeichnisname gefunden wurde.

Auch wenn Sie idmapping ordnungsgemäß deaktivieren, kann es vorkommen, dass es automatisch wieder aktiviert wird. Wenn Azure Files beispielsweise auf einen ungültigen Dateinamen stößt, wird ein Fehler zurückgegeben. Wenn dieser Fehlercode erkannt wird, wird idmapping erneut durch einen NFS v4.1-Linux-Client aktiviert, und zukünftige Anforderungen werden mit alphanumerischer UID/GID gesendet. Eine Liste der bei Azure Files nicht unterstützten Zeichen finden Sie in diesem Artikel. Der Doppelpunkt ist eines der nicht unterstützten Zeichen.

Problemumgehung

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

1. Heben Sie die Bereitstellung der Freigabe auf.

2. Idmapping deaktivieren mit:

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

3. Stellen Sie die Freigabe wieder her.

4. Wenn Rsync ausgeführt wird, führen Sie rsync mit dem —numeric-ids Argument aus einem Verzeichnis aus, das nicht über einen ungültigen Verzeichnis- oder Dateinamen verfügt.

Es kann keine NFS-Freigabe erstellt werden.

Ursache: Einstellungen für nicht unterstützte Speicherkonten

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

• Ebene – Premium
• Kontoart – FileStorage
• Regionen – Liste der unterstützten Regionen

Lösung

Folgen Sie den Anweisungen unter So erstellen Sie eine NFS-Freigabe.

Verbindungsherstellung mit oder Einbindung von NFS Azure-Dateifreigabe nicht möglich

Ursache 1: Eine Anforderung stammt von einem Client in einem nicht vertrauenswürdigen Netzwerk/mit einer nicht vertrauenswürdigen IP-Adresse.

NFS unterstützt im Gegensatz zu SMB keine benutzerbasierte Authentifizierung. Die Authentifizierung für eine Freigabe basiert auf der Konfiguration Ihrer Netzwerksicherheitsregeln. Sie müssen entweder den Dienstendpunkt oder private Endpunkte verwenden, um sicherzustellen, dass Clients nur sichere Verbindungen mit der NFS-Freigabe herstellen. Wenn Sie lokal auf Freigaben zugreifen möchten, müssen Sie zusätzlich zu privaten Endpunkten eine VPN- oder ExpressRoute-Verbindung einrichten. IP-Adressen, die der Firewall-Positivliste des Speicherkontos hinzugefügt wurden, werden ignoriert. Sie müssen eine der folgenden Methoden verwenden, um den Zugriff auf eine NFS-Freigabe einzurichten:

• Dienstendpunkt

  • Zugriff erfolgte über den öffentlichen Endpunkt.

  • Nur in derselben Region erhältlich.

  • Sie können VNet Peering nicht für den gemeinsamen Zugriff verwenden.

  • Sie müssen jedes virtuelle Netzwerk oder Subnetz einzeln zur Zulassen-Liste hinzufügen.

  • Für den Zugang vor Ort können Sie Service-Endpunkte mit ExpressRoute, Point-to-Site- und Site-to-Site-VPNs verwenden. Wir empfehlen die Verwendung eines privaten Endpunkts, da dies sicherer ist.

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

    

• Privater Endpunkt

  • Der Zugriff ist sicherer als der über den Dienstendpunkt.

  • Der Zugriff auf die NFS-Freigabe über einen privaten Link ist innerhalb und außerhalb der Azure-Region des Speicherkontos möglich (regionsübergreifend, vor Ort).

  • Virtuelles Netzwerk-Peering mit virtuellen Netzwerken, die im privaten Endpunkt gehostet werden, gibt den NFS-Freigabezugang zu den Klienten in den gepeerten virtuellen Netzwerken.

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

    

Ursache 2: „Sichere Übertragung erforderlich“ ist aktiviert.

NFS Azure-Dateifreigaben unterstützen derzeit keine doppelte Verschlüsselung. Azure bietet mit MACSec eine Verschlüsselungsschicht für alle Daten, die zwischen Azure-Rechenzentren übertragen werden. Sie können nur von vertrauenswürdigen virtuellen Netzwerken und über VPN-Tunnel auf NFS-Freigaben zugreifen. Auf NFS-Freigaben ist keine zusätzliche Verschlüsselung der Transportschicht verfügbar.

Lösung

Deaktivieren Sie die sichere Übertragung, die im Konfigurationsblatt Ihres Speicherkontos erforderlich ist .

Ursache 3: Das Paket „nfs-utils“, „nfs-client“ oder „nfs-common“ ist nicht installiert.

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

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

sudo rpm -qa | grep nfs-utils

sudo rpm -qa | grep nfs-client

sudo dpkg -l | grep nfs-common

Lösung

Wenn das Paket nicht installiert ist, installieren Sie es mit dem verteilungsspezifischen Befehl.

sudo yum install nfs-utils

sudo dnf install nfs-utils

sudo zypper install nfs-client

sudo apt update
sudo apt install nfs-common

Ursache 4: Die Firewall blockiert Port 2049.

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

Lösung

Überprüfen Sie, ob 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

Ursache 5: Speicherkonto gelöscht

Wenn Sie die Dateifreigabe aufgrund eines Fehlers nicht bereitstellen können: Timeout der Verbindung, wird das Speicherkonto, das die Dateifreigabe enthält, versehentlich gelöscht.

Lösung

Wiederherstellen des Speicherkontos. Löschen Sie dann den privaten Endpunkt, und erstellen Sie ihn erneut, damit er der neuen Ressourcen-ID des Speicherkontos zugeordnet ist.

ls hängt bei umfangreichen Verzeichnisenumerationen in einigen Kernels

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

Einige Kernelversionen weisen einen Fehler auf, der dazu führt, dass Verzeichnisauflistungen zu endlosen READDIR-Sequenzen führen. Bei kleinen Verzeichnissen, in denen alle Einträge in einem Aufruf übermittelt werden können, tritt das Problem nicht auf. Der Fehler wurde im Linux-Kernel v5.11 eingeführt und in v5.12.5 behoben. Alle Versionen dazwischen weisen also den Fehler auf. RHEL 8.4 hat diese Kernelversion.

Problemumgehung: Kernel herabstufen oder upgraden

Durch das Herabstufen oder Upgraden des Kernels auf eine beliebige Version außerhalb der betroffenen Kernelversionen sollte das Problem behoben werden.

Systembefehle schlagen mit dem Fehler "Datei nicht gefunden" fehl.

Ursache

Linux 32-Bit-Anwendungen, die auf Inodenummern basieren, funktionieren möglicherweise aufgrund der Formatierung der vom NFS-Dienst generierten 64-Bit-Inodenummern möglicherweise nicht wie erwartet mit Azure Files.

Lösung

Sie können dieses Problem mit einer der folgenden Methoden beheben:

• Komprimieren Sie die 64-Bit-Inodenummern mithilfe der nfs.enable_ino64=0 Kernelstartoption auf 32 Bit.

• Legen Sie den Modulparameter fest, indem options nfs enable_ino64=0 Sie der Datei "/etc/modprobe.d/nfs.conf " hinzufügen und den virtuellen Computer neu starten.

Sie können diese Kernelstartoption auch in der Datei grub.conf beibehalten. Weitere Informationen finden Sie in der Dokumentation für Ihre Linux-Verteilung.

Der Besitz von Dateien und Verzeichnissen kann nicht geändert werden.

Ursache

Berechtigungen für NFS-Dateifreigaben werden vom Clientbetriebssystem und nicht vom Azure Files-Dienst erzwungen. Wenn die Einstellung 'Root Root' für eine NFS-Dateifreigabe aktiviert ist, wird der Stammbenutzer im Clientsystem als anonymer (nicht privilegierter) Benutzer für Zugriffssteuerungszwecke behandelt. Dies bedeutet, dass Sie selbst dann, wenn Sie im Clientsystem als Stamm angemeldet sind, nicht den chown Befehl verwenden können, um den Besitz von Dateien und Verzeichnissen zu ändern, die Sie nicht besitzen.

Lösung

Navigieren Sie im Azure-Portal zur Dateifreigabe, und wählen Sie "Eigenschaften" aus. Ändern Sie die Root Root Setting in No Root Root. Weitere Informationen finden Sie unter Konfigurieren der Stamm-Konfiguration für Azure Files.

Wenn kein Root Root Root Aktiviert ist, verfügt der Stammbenutzer im Clientsystem über die gleichen Berechtigungen wie der Stammbenutzer im Serversystem. Sie können jetzt verwenden chown , um den Besitz einer beliebigen Datei oder eines Verzeichnisses in der Freigabe zu ändern, unabhängig vom aktuellen Besitzer. Nachdem Sie die Änderungen vorgenommen haben, können Sie root RootRücken bei Bedarf erneut aktivieren.

Sie brauchen Hilfe?

Wenden Sie sich an den Support, falls Sie weitere Hilfe benötigen, um das Problem schnell beheben zu lassen.

Siehe auch

• Problembehandlung für Azure Files
• Problembehandlung für die Azure Files-Leistung
• Behandeln von Azure Files-Konnektivitätsproblemen (SMB)
• Problembehandlung bei Azure Files-Authentifizierung und -Autorisierung (SMB)
• Behandeln von allgemeinen SMB-Problemen bei Azure Files unter Linux

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.