Fehler beim Einbinden einer Azure-Dateifreigabe

Dieser Artikel enthält mögliche Ursachen und Lösungen für Fehler, die dazu führen, dass die Einbindung einer Azure-Dateifreigabe fehlschlägt.

Problembeschreibung

Sie stellen eine Kubernetes-Ressource wie eine Bereitstellung oder ein StatefulSet in einer AKS-Umgebung (Azure Kubernetes Service) bereit. Die Bereitstellung erstellt einen Pod, der einen PersistentVolumeClaim (PVC) einbindet, der auf eine Azure-Dateifreigabe verweist.

Der Pod verbleibt jedoch im status ContainerCreating. Wenn Sie den kubectl describe pods Befehl ausführen, wird in der Befehlsausgabe möglicherweise einer der folgenden Fehler angezeigt, der dazu führt, dass der Einbindungsvorgang fehlschlägt:

• Bereitstellungsfehler(2): Datei oder Verzeichnis dieser Art nicht vorhanden
• Einbindungsfehler(13): Berechtigung verweigert

In der folgenden Ausgabe finden Sie ein Beispiel.

MountVolume.MountDevice failed for volume "\<pv-fileshare-name>"
rpc error: code = Internal desc =
volume(\<storage-account's-resource-group>#\<storage-account-name>#\<pv/fileshare-name>#) > mount "//\<storage-account-name>.file.core.windows.net/\<pv-fileshare-name>" on "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/\<pv-fileshare-name>/globalmount" failed with
mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t cifs -o dir_mode=0777,file_mode=0777,uid=0,gid=0,mfsymlinks,cache=strict,actimeo=30,\<masked> //\<storage-account-name>.file.core.windows.net/\<pv-name> /var/lib/kubelet/plugins/kubernetes.io/csi/pv/\<pv-name>/globalmount
Output: mount error(\<error-id>): \<error-description>
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Hinweis

• Wenn das Speicherkonto öffentlich zugänglich ist, lautet der in der Ausgabe angezeigte Hostname storage-account-name.file.core.windows.net>.<
• Wenn das Speicherkonto privat mit einer privaten Verbindung, einem Endpunkt oder einer DNS-Zone konfiguriert ist, lautet <der Hostname storage-account-name.privatelink.file.core.windows.net>.

Vor der Problembehandlung

Identifizieren Sie gemäß der Meldung in der Ausgabe, wie im folgenden Beispiel gezeigt, das Speicherkonto und die Dateifreigabe. Die Werte werden in späteren Schritten zur Problembehandlung verwendet.

mount "//<storage-account-name.file.core.windows.net/>< pv-fileshare-name>"

Mögliche Ursachen und Lösungen finden Sie in den folgenden Abschnitten.

Bereitstellungsfehler(2): Datei oder Verzeichnis dieser Art nicht vorhanden

Dieser Fehler gibt an, dass keine Verbindung zwischen dem AKS-Cluster und dem Speicherkonto besteht.

Erste Problembehandlung

Azure File basiert auf dem SMB-Protokoll (Port 445). Stellen Sie sicher, dass Port 445 und/oder die IP-Adresse des Speicherkontos nicht blockiert sind.

Um die IP-Adresse des Speicherkontos zu überprüfen, führen Sie einen DNS-Befehl (Domain Name System) wie nslookup, digoder hostaus. Zum Beispiel:

nslookup <storage-account-name>.file.core.windows.net

Um zu überprüfen, ob eine Verbindung zwischen dem AKS-Cluster und dem Speicherkonto besteht, rufen Sie den Knoten oder Pod auf, und führen Sie den folgenden Befehl oder telnet den folgenden nc Befehl aus:

nc -v -w 2 <storage-account-name>.file.core.windows.net 445

telnet <storage-account-name>.file.core.windows.net 445

Mögliche Ursachen für Bereitstellungsfehler(2)

• Ursache 1: Dateifreigabe ist nicht vorhanden
• Ursache 2: NSG blockiert Datenverkehr zwischen AKS und Speicherkonto.
• Ursache 3: Virtuelles Gerät blockiert Datenverkehr zwischen AKS und Speicherkonto.
• Ursache 4: Es wird ein FIPS-fähiger Knotenpool verwendet.

Hinweis

• Ursache 1, 2 und 4 gelten für Szenarien mit öffentlichen und privaten Speicherkonten.
• Ursache 3 gilt nur für das öffentliche Szenario.

Ursache 1: Dateifreigabe ist nicht vorhanden

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob die Dateifreigabe vorhanden ist:

1. Search Speicherkonten im Azure-Portal, und greifen Sie auf Ihr Speicherkonto zu.

   

2. Wählen Sie im Speicherkonto unter Datenspeicher die Option Dateifreigaben aus, und überprüfen Sie, ob das zugeordnete PersistentVolumeClaim in der YAML-Datei des Pods, der Bereitstellung oder des Zustandsfulsets in Dateifreigaben vorhanden ist.

   

Lösung: Sicherstellen, dass die Dateifreigabe vorhanden ist

Um dieses Problem zu beheben, stellen Sie sicher, dass die Dateifreigabe vorhanden ist, die dem PV/PVC zugeordnet ist.

Ursache 2: Netzwerksicherheitsgruppe blockiert Datenverkehr zwischen AKS und Speicherkonto.

Überprüfen Sie die Ausgabe des nc - oder telnet -Befehls, der im Abschnitt Erste Problembehandlung erwähnt wird. Wenn ein Timeout angezeigt wird, überprüfen Sie die Netzwerksicherheitsgruppe (NSG), und stellen Sie sicher, dass die IP-Adresse des Speicherkontos nicht blockiert ist.

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob die NSG die IP-Adresse des Speicherkontos blockiert:

1. Wechseln Sie im Azure-Portal zu Network Watcher, und wählen Sie NSG-Diagnose aus.

2. Füllen Sie die Felder mit den folgenden Werten aus:

   • Protokoll: Beliebig
   • Richtung: Ausgehend
   • Quelltyp: IPv4-Adresse/CIDR
   • IPv4-Adresse/CIDR: Die IP-Adresse einer instance, die dem AKS-Knoten zugeordnet ist
   • Ziel-IP-Adresse: Die IP-Adresse des Speicherkontos
   • Zielport: 445

3. Wählen Sie die Schaltfläche Überprüfen aus, und überprüfen Sie die status Datenverkehr.

Der datenverkehrs status kann zulässig oder verweigert werden. Die status verweigert bedeutet, dass die NSG den Datenverkehr zwischen dem AKS-Cluster und dem Speicherkonto blockiert. Wenn die status verweigert wird, wird der NSG-Name angezeigt.

Lösung: Zulassen der Konnektivität zwischen AKS und Speicherkonto

Um dieses Problem zu beheben, führen Sie entsprechende Änderungen auf NSG-Ebene durch, um die Konnektivität zwischen dem AKS-Cluster und dem Speicherkonto an Port 445 zu ermöglichen.

Ursache 3: Virtuelles Gerät blockiert Datenverkehr zwischen AKS und Speicherkonto.

Wenn Sie ein virtuelles Gerät (in der Regel eine Firewall) verwenden, um den ausgehenden Datenverkehr des AKS-Clusters zu steuern (z. B. verfügt das virtuelle Gerät über eine Routingtabelle im Subnetz des AKS-Clusters und die Routingtabelle über Routen, die Datenverkehr an das virtuelle Gerät senden), kann das virtuelle Gerät den Datenverkehr zwischen dem AKS-Cluster und dem Speicherkonto blockieren.

Um das Problem zu isolieren, fügen Sie in der Routingtabelle eine Route für die IP-Adresse des Speicherkontos hinzu, um den Datenverkehr an das Internet zu senden.

Führen Sie die folgenden Schritte aus, um zu überprüfen, welche Routingtabelle den Datenverkehr des AKS-Clusters steuert:

1. Wechseln Sie im Azure-Portal zum AKS-Cluster, und wählen Sie Eigenschaften>Infrastrukturressourcengruppe aus.
2. Greifen Sie auf die VM-Skalierungsgruppe (VMSS) oder einen virtuellen Computer in einer Verfügbarkeitsgruppe zu, wenn Sie einen solchen VM-Satztyp verwenden.
3. Wählen Sie Virtuelles Netzwerk/Subnetz>Subnetze aus, und identifizieren Sie das Subnetz des AKS-Clusters. Auf der rechten Seite sehen Sie die Routingtabelle.

Um die Route in der Routingtabelle hinzuzufügen, führen Sie die Schritte unter Erstellen einer Route aus , und füllen Sie die folgenden Felder aus:

• Adresspräfix: <storage-account's-public-IP>/32
• Typ des nächsten Hops:Internet

Diese Route sendet den gesamten Datenverkehr zwischen dem AKS-Cluster und dem Speicherkonto über das öffentliche Internet.

Nachdem Sie die Route hinzugefügt haben, testen Sie die Konnektivität mithilfe des nc Befehls oder telnet , und führen Sie den Einbindungsvorgang erneut aus.

Lösung: Stellen Sie sicher, dass das virtuelle Gerät Datenverkehr zwischen AKS und dem Speicherkonto zulässt.

Wenn der Einbindungsvorgang erfolgreich ist, sollten Sie sich an Ihr Netzwerkteam wenden, um sicherzustellen, dass das virtuelle Gerät Datenverkehr zwischen dem AKS-Cluster und dem Speicherkonto an Port 445 zulassen kann.

Ursache 4: Es wird ein FIPS-fähiger Knotenpool verwendet.

Wenn Sie einen FiPS-fähigen Knotenpool (Federal Information Processing Standard) verwenden, schlägt der Einbindungsvorgang fehl, da die FIPS einige Authentifizierungsmodule deaktiviert, wodurch die Einbindung einer CIFS-Freigabe verhindert wird. Dieses Verhalten wird erwartet und nicht spezifisch für AKS.

Verwenden Sie eine der folgenden Lösungen, um das Problem zu beheben:

Lösung 1: Planen von Pods auf Knoten in einem Nicht-FIPS-Knotenpool

FIPS ist in AKS-Knotenpools standardmäßig deaktiviert und kann nur während der Erstellung des Knotenpools mithilfe des --enable-fips-image Parameters aktiviert werden.

Um den Fehler zu beheben, können Sie die Pods auf Knoten in einem Nicht-FIPS-Knotenpool planen.

Lösung 2: Erstellen eines Pods, der auf einem FIPS-fähigen Knoten geplant werden kann

Führen Sie die folgenden Schritte aus, um einen Pod zu erstellen, der auf einem FIPS-fähigen Knoten geplant werden kann:

1. Verwenden Sie den Azure File CSI-Treiber, um eine benutzerdefinierte StorageClass zu erstellen, die das NFS-Protokoll verwendet.

   Sehen Sie sich die folgende YAML-Datei als Beispiel an:

   kind: StorageClass 
   apiVersion: storage.k8s.io/v1 
   metadata: 
     name: azurefile-sc-fips 
   provisioner: file.csi.azure.com 
   reclaimPolicy: Delete 
   volumeBindingMode: Immediate 
   allowVolumeExpansion: true 
   parameters: 
     skuName: Premium_LRS 
     protocol: nfs 
   

   Die SKU ist in der YAML-Datei auf Premium_LRS festgelegt, da die Premium-SKU für NFS erforderlich ist. Weitere Informationen finden Sie unter Dynamische Bereitstellung.

   Aufgrund der Premium-SKU beträgt die Mindestgröße der Dateifreigabe 100 GB. Weitere Informationen finden Sie unter Erstellen einer Speicherklasse.

2. Erstellen Sie einen PVC, der auf die benutzerdefinierte StorageClass azurefile-sc-fips verweist.

   Sehen Sie sich die folgende YAML-Datei als Beispiel an:

   apiVersion: v1 
   kind: PersistentVolumeClaim 
   metadata: 
     name: azurefile-pvc-fips 
   spec: 
     accessModes: 
       - ReadWriteMany 
     storageClassName: azurefile-sc-fips 
     resources: 
       requests: 
         storage: 100Gi 
   

3. Erstellen Sie einen Pod, der die PVC-Datei azurefile-pvc-fips einlagert.

   Sehen Sie sich die folgende YAML-Datei als Beispiel an:

   kind: Pod 
   apiVersion: v1 
   metadata: 
     name: azurefile-pod-fips 
   spec: 
     containers: 
     - name: azurefile-pod-fips 
       image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine 
       resources: 
         requests: 
           cpu: 100m 
           memory: 128Mi 
         limits: 
           cpu: 250m 
           memory: 256Mi 
       volumeMounts: 
       - mountPath: "/mnt/azure" 
         name: volume 
     volumes: 
       - name: volume 
         persistentVolumeClaim: 
           claimName: azurefile-pvc-fips 
   

Einbindungsfehler(13): Berechtigung verweigert

Die folgenden Ursachen für diesen Fehler sind möglich:

• Ursache 1: Kubernetes-Geheimnis verweist nicht auf den richtigen Speicherkontonamen oder -schlüssel
• Ursache 2: VNET und Subnetz von AKS sind für das Speicherkonto nicht zulässig.
• Ursache 3: Die Konnektivität erfolgt über eine private Verbindung, aber Knoten und der private Endpunkt befinden sich in unterschiedlichen VNETs.
• Ursache 4: Das Speicherkonto ist so festgelegt, dass eine Verschlüsselung erforderlich ist, die vom Client nicht unterstützt wird.
• Ursache 5: Die Mindestverschlüsselungsanforderung für ein Speicherkonto ist nicht erfüllt

Hinweis

• Ursache 1 gilt für öffentliche und private Szenarien.
• Ursache 2 gilt nur für das öffentliche Szenario.
• Ursache 3 gilt nur für das private Szenario.
• Ursache 4 gilt für öffentliche und private Szenarien.
• Ursache 5 gilt für öffentliche und private Szenarien.

Ursache 1: Kubernetes-Geheimnis verweist nicht auf den richtigen Speicherkontonamen oder -schlüssel

Wenn die Dateifreigabe dynamisch erstellt wird, wird automatisch eine Kubernetes-Geheimnisressource mit dem Namen "azure-storage-account-storage-account-name-secret<>" erstellt.

Wenn die Dateifreigabe manuell erstellt wird, sollte die Kubernetes-Geheimnisressource manuell erstellt werden.

Unabhängig von der Erstellungsmethode schlägt der Bereitstellungsvorgang mit dem Fehler "Berechtigung verweigert" fehl, wenn der Speicherkontoname oder der Schlüssel, auf den im Kubernetes-Geheimnis verwiesen wird, nicht mit dem tatsächlichen Wert übereinstimmt.

Mögliche Ursachen für Konflikt

• Wenn das Kubernetes-Geheimnis manuell erstellt wird, kann während der Erstellung ein Tippfehler auftreten.

• Wenn ein Vorgang "Schlüssel rotieren" auf Speicherkontoebene ausgeführt wird, werden die Änderungen nicht auf der Kubernetes-Geheimnisebene widergespiegelt. Dies führt zu einem Konflikt zwischen dem Schlüsselwert auf Speicherkontoebene und dem Wert auf Kubernetes-Geheimnisebene.

  Wenn ein Vorgang "Schlüssel rotieren" erfolgt, wird im Aktivitätsprotokoll des Speicherkontos ein Vorgang mit dem Namen "Speicherkontoschlüssel neu generieren" angezeigt. Beachten Sie den Aufbewahrungszeitraum von 90 Tagen für das Aktivitätsprotokoll.

Überprüfen eines Konflikts

Führen Sie die folgenden Schritte aus, um den Konflikt zu überprüfen:

1. Search auf das Speicherkonto im Azure-Portal und zugreifen. Wählen Sie Zugriffsschlüssel> Schlüssel im Speicherkontoanzeigen aus. Der Name des Speicherkontos und die zugehörigen Schlüssel werden angezeigt.

   

2. Wechseln Sie zum AKS-Cluster, wählen SieKonfigurationsgeheimnisse> aus, und suchen Sie dann nach dem zugeordneten Geheimnis, und greifen Sie darauf zu.

   

3. Wählen Sie Anzeigen (das Augensymbol) aus, und vergleichen Sie die Werte des Speicherkontonamens und des zugeordneten Schlüssels mit den Werten in Schritt 1.

   

   Bevor Sie Anzeigen auswählen, werden die Werte des Speicherkontonamens und des zugeordneten Schlüssels in Base64-Zeichenfolgen codiert. Nachdem Sie Anzeigen ausgewählt haben, werden die Werte decodiert.

Wenn Sie keinen Zugriff auf den AKS-Cluster im Azure-Portal haben, führen Sie Schritt 2 auf kubectl-Ebene aus:

1. Rufen Sie die YAML-Datei des Kubernetes-Geheimnisses ab, und führen Sie dann den folgenden Befehl aus, um die Werte des Speicherkontonamens und des Schlüssels aus der Ausgabe abzurufen:

   kubectl get secret <secret-name> -n <secret-namespace> -o <yaml-file-name>
   

2. Verwenden Sie den echo Befehl, um die Werte des Speicherkontonamens und des Schlüssels zu decodieren und sie mit den Werten auf Speicherkontoebene zu vergleichen.

   Hier sehen Sie ein Beispiel zum Decodieren des Speicherkontonamens:

   echo -n '<storage account name>' | base64 --decode ;echo
   

   

Lösung: Anpassen des Kubernetes-Geheimnisses und erneutes Erstellen der Pods

Wenn der Wert des Speicherkontonamens oder -schlüssels im Kubernetes-Geheimnis nicht mit dem Wert unter Zugriffsschlüssel im Speicherkonto übereinstimmt, passen Sie das Kubernetes-Geheimnis auf kubernetes-Geheimnisebene an, indem Sie den folgenden Befehl ausführen:

kubectl edit secret <secret-name> -n <secret-namespace>

Der Wert des Speicherkontonamens oder des Schlüssels, der in der Kubernetes-Geheimniskonfiguration hinzugefügt wird, sollte ein Base64-codierter Wert sein. Verwenden Sie den Befehl, um den echo codierten Wert abzurufen.

Hier sehen Sie ein Beispiel zum Codieren des Speicherkontonamens:

echo -n '<storage account name>'| base64 | tr -d '\n' ; echo

Weitere Informationen finden Sie unter Verwalten von Geheimnissen mit kubectl.

Nachdem das Kubernetes-Geheimnis azure-storage-account-<storage-account-name>-secret über die richtigen Werte verfügt, erstellen Sie die Pods neu. Andernfalls verwenden diese Pods weiterhin die alten Werte, die nicht mehr gültig sind.

Ursache 2: VNET und Subnetz von AKS sind für das Speicherkonto nicht zulässig.

Wenn das Netzwerk des Speicherkontos auf ausgewählte Netzwerke beschränkt ist, das VNET und das Subnetz des AKS-Clusters jedoch nicht zu ausgewählten Netzwerken hinzugefügt werden, schlägt der Einbindungsvorgang mit dem Fehler "Berechtigung verweigert" fehl.

Lösung: Zulassen des VNET und Subnetzes von AKS für das Speicherkonto

1. Identifizieren Sie den Knoten, der den fehlerhaften Pod hostet, indem Sie den folgenden Befehl ausführen:

   kubectl get pod <pod-name> -n <namespace> -o wide
   

   Überprüfen Sie den Knoten in der Befehlsausgabe:

   

2. Wechseln Sie zum AKS-Cluster im Azure-Portal, wählen Sie Eigenschaften>Infrastrukturressourcengruppe aus, greifen Sie auf die VMSS zu, die dem Knoten zugeordnet ist, und aktivieren Sie dann Virtuelles Netzwerk/Subnetz, um das VNET und subnetz zu identifizieren.

   

3. Greifen Sie auf das Speicherkonto im Azure-Portal zu. Wählen Sie Netzwerk aus. Wenn Zugriff zulassen von auf Ausgewählte Netzwerke festgelegt ist, überprüfen Sie, ob das VNET und das Subnetz des AKS-Clusters hinzugefügt werden.

   

   Wenn das VNET und das Subnetz des AKS-Clusters nicht hinzugefügt werden, wählen Sie Vorhandenes virtuelles Netzwerk hinzufügen aus. Geben Sie auf der Seite Netzwerke hinzufügen das VNET und das Subnetz des AKS-Clusters ein, und wählen Sie dannSpeichernhinzufügen> aus.

   

   Es kann einige Augenblicke dauern, bis die Änderungen wirksam werden. Nachdem das VNET und das Subnetz hinzugefügt wurden, überprüfen Sie, ob sich der Pod status von ContainerCreating in Running ändert.

   

Ursache 3: Die Konnektivität erfolgt über private Verbindungen, aber Knoten und privater Endpunkt befinden sich in unterschiedlichen VNETs.

Wenn der AKS-Cluster und das Speicherkonto über eine private Verbindung verbunden sind, wird eine genehmigte private Endpunktverbindung verwendet.

Wenn sich der private Endpunkt und der AKS-Knoten in diesem Szenario im selben VNET befinden, können Sie eine Azure-Dateifreigabe einbinden.

Wenn sich der private Endpunkt und Ihr AKS-Cluster in unterschiedlichen VNETs befinden, schlägt der Bereitstellungsvorgang mit dem Fehler "Berechtigung verweigert" fehl.

Lösung: Erstellen einer virtuellen Netzwerkverbindung für das VNET des AKS-Clusters in einer privaten DNS-Zone

Rufen Sie den Knoten auf , und überprüfen Sie, ob der vollqualifizierte Domänenname (FQDN) über eine öffentliche oder private IP-Adresse aufgelöst wird. Führen Sie dazu den folgenden Befehl aus:

nslookup <storage-account-name>.privatelink.file.core.windows.net

Wenn der FQDN über eine öffentliche IP-Adresse aufgelöst wird (siehe folgenden Screenshot), erstellen Sie eine virtuelle Netzwerkverbindung für das VNET des AKS-Clusters auf der Ebene der privaten DNS-Zone ("privatelink.file.core.windows.net"). Beachten Sie, dass bereits automatisch eine virtuelle Netzwerkverbindung für das VNET des privaten Endpunkts des Speicherkontos erstellt wurde.

Führen Sie die folgenden Schritte aus, um den Link für das virtuelle Netzwerk zu erstellen:

1. Greifen Sie auf die Privates DNS Zone zu, und wählen Sie Virtuelle Netzwerkverbindungen>Hinzufügen aus.

   

2. Füllen Sie die Felder aus, und wählen Sie das VNET des AKS-Clusters für virtuelle Netzwerke aus. Informationen zum Identifizieren des VNET des AKS-Clusters finden Sie im Abschnitt Lösung: VNET und Subnetz von AKS für speicherkonto zulassen .

   

3. Wählen Sie OK aus.

Nachdem die VNET-Verbindung hinzugefügt wurde, sollte der FQDN über eine private IP-Adresse aufgelöst werden, und der Einbindungsvorgang sollte erfolgreich sein. Ein Beispiel finden Sie im folgenden Screenshot:

Ursache 4: Das Speicherkonto ist so festgelegt, dass eine Verschlüsselung erforderlich ist, die vom Client nicht unterstützt wird.

Azure Files Sicherheitseinstellungen enthalten eine Reihe von Optionen zum Steuern der Sicherheits- und Verschlüsselungseinstellungen für Speicherkonten. Das Einschränken zulässiger Methoden und Algorithmen kann clients daran hindern, eine Verbindung herzustellen.

AKS-Versionen vor 1.25 basieren auf Ubuntu 18.04 LTS, das den Linux 5.4-Kernel verwendet und nur die Verschlüsselungsalgorithmen AES-128-CCM und AES-128-GCM unterstützt. Das Maximale Sicherheitsprofil oder ein benutzerdefiniertes Profil, das AES-128-GCM deaktiviert, verursacht Freigabezuordnungsfehler.

AKS-Versionen 1.25 und höhere Versionen basieren auf Ubuntu 22.04, das den Linux 5.15-Kernel verwendet und Unterstützung für AES-256-GCM hat.

Lösung: Verwendung des AES-128-GCM-Verschlüsselungsalgorithmus zulassen

Aktivieren Sie den AES-128-GCM-Algorithmus mithilfe des Maximalen Kompatibilitätsprofils oder eines benutzerdefinierten Profils, das AES-128-GCM aktiviert. Weitere Informationen finden Sie unter Azure Files Sicherheitseinstellungen.

Ursache 5: Die Mindestverschlüsselungsanforderung für ein Speicherkonto ist nicht erfüllt

Lösung: Aktivieren des AES-128-GCM-Verschlüsselungsalgorithmus für alle Speicherkonten

Um eine Dateifreigabe erfolgreich einzubinden oder darauf zuzugreifen, sollte der AES-128-GCM-Verschlüsselungsalgorithmus für alle Speicherkonten aktiviert sein.

Wenn Sie nur die AES-256-GCM-Verschlüsselung verwenden möchten, die die maximale Sicherheit (SMB 3.1.1) darstellt, gehen Sie wie folgt vor:

Linux

Verwenden Sie das folgende Skript, um zu überprüfen, ob der Client AES-256-GCM unterstützt, und erzwingen Sie es nur, wenn dies der Fall ist:

cifsConfPath="/etc/modprobe.d/cifs.conf" 
echo "`date` before change ${cifsConfPath}:"
cat ${cifsConfPath}
if !(( grep require_gcm_256 ${cifsConfPath} ))
then
modprobe cifs
echo 1 > /sys/module/cifs/parameters/require_gcm_256
echo "options cifs require_gcm_256=1" > ${cifsConfPath}
echo "`date` after changing ${cifsConfPath}:"
cat ${cifsConfPath}
fi

Windows

Verwenden Sie den PowerShell-Befehl Set-SmbClientConfiguration , um die vom SMB-Client verwendeten Verschlüsselungsverfahren und den bevorzugten Verschlüsselungstyp ohne Benutzerbestätigung anzugeben:

Set-SmbClientConfiguration -EncryptionCiphers "AES_256_GCM" -Confirm:$false

Hinweis

Der EncryptionCiphers Parameter ist ab dem kumulativen Update 2022-06 für Windows Server Version 21H2 für x64-basierte Systeme (KB5014665) und dem kumulativen Update für Windows 11 Version 22H2 (KB5014668) verfügbar.

Weitere Informationen

Wenn andere Bereitstellungsfehler auftreten, finden Sie weitere Informationen unter Problembehandlung 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.