Freigeben über

Fehler beim Einbinden einer Azure-Dateifreigabe

  • Artikel

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

Symptome

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

Der Pod bleibt jedoch im Status ContainerCreating. Wenn Sie den kubectl describe pods Befehl ausführen, wird möglicherweise eine der folgenden Fehler in der Befehlsausgabe angezeigt, wodurch der Montagevorgang fehlschlägt:

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)

Notiz

  • 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 Verknüpfung, einem Endpunkt oder einer DNS-Zone konfiguriert ist, lautet <der Hostname "storage-account-name.privatelink.file.core.windows.net>".

Vor der Problembehandlung

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

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

In den folgenden Abschnitten finden Sie Informationen zu möglichen Ursachen und Lösungen.

Bereitstellungsfehler (2): Datei oder Verzeichnis nicht vorhanden

Dieser Fehler weist darauf hin, dass keine Verbindung zwischen AKS-Cluster und Speicherkonto besteht.

Erste Schritte bei der Problembehandlung

Azure Files benötigt das Protokoll SMB (Port 445). Stellen Sie sicher, dass Port 445 und/oder die IP-Adresse des Speicherkontos nicht blockiert werden.

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

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

Um zu überprüfen, ob Konnektivität zwischen AKS-Cluster und Speicherkonto besteht, wechseln Sie in den Knoten oder Pod, und führen Sie den folgenden Befehl nc oder telnet 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 Einbindungsfehler(2)

Notiz

  • 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 nicht vorhanden

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

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

    Screenshot der Liste der Speicherkonten in Azure-Portal.

  2. Wählen Sie "Dateifreigaben" unter "Datenspeicher" im Speicherkonto aus, und überprüfen Sie, ob der zugehörige PersistentVolumeClaim in der Yaml-Datei des Pods, der Bereitstellung oder des Zustandssets in Dateifreigaben vorhanden ist.

    Screenshot der Auswahl von Dateifreigaben im Speicherkonto.

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 im Abschnitt "Erste Problembehandlung" erwähnten Befehlstelnet. Wenn ein Timeout angezeigt wird, überprüfen Sie die Netzwerksicherheitsgruppe (NSG), und stellen Sie sicher, dass die IP-Adresse des Speicherkontos nicht blockiert wird.

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 zur Netzwerküberwachung, und wählen Sie die 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 Instanz, die dem AKS-Knoten zugeordnet ist
    • Ziel-IP-Adresse: Die IP-Adresse des Speicherkontos
    • Zielport: 445

  3. Aktivieren Sie die Schaltfläche "Überprüfen ", und überprüfen Sie den Datenverkehrsstatus .

Der Datenverkehrsstatus kann zulässig oder verweigert werden. Der Status "Verweigert" bedeutet, dass der NSG den Datenverkehr zwischen dem AKS-Cluster und dem Speicherkonto blockiert. Wenn der Status verweigert wird, wird der NSG-Name angezeigt.

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

Um dieses Problem zu beheben, nehmen Sie entsprechende Änderungen auf NSG-Ebene vor, um Konnektivität zwischen AKS-Cluster und Speicherkonto an Port 445 zuzulassen.

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

Wenn Sie ein virtuelles Gerät (in der Regel eine Firewall) verwenden, um aus dem AKS-Cluster ausgehenden Datenverkehr zu steuern (z. B. verfügt das virtuelle Gerät über eine Routingtabelle, die für das Subnetz des AKS-Clusters gilt, und die Routingtabelle enthält Routen, die Datenverkehr in Richtung des virtuellen Geräts senden), kann das virtuelle Gerät den Datenverkehr zwischen AKS-Cluster und 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 in Richtung 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 die Ressourcengruppe "Eigenschafteninfrastruktur>" aus.
  2. Greifen Sie auf die VM-Skalierungsgruppe oder eine VM in einer Verfügbarkeitsgruppe zu, wenn Sie einen solchen VM-Gruppentyp verwenden.
  3. Wählen Sie virtuelle Netzwerke/Subnetze> aus, und identifizieren Sie das Subnetz des AKS-Clusters. Auf der rechten Seite sehen Sie die Routingtabelle.

Führen Sie zum Hinzufügen der Route zur Routingtabelle die Schritte unter Erstellen einer Route aus, und füllen Sie die folgenden Felder aus:

  • Adresspräfix: <storage-account's-public-IP>/32
  • Nächster Hoptyp:Internet

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

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

Lösung: Sicherstellen, dass das virtuelle Gerät Datenverkehr zwischen AKS und Speicherkonto zulässt

Wenn der Einbindungsvorgang erfolgreich war, empfehlen wir Ihnen, sich an Ihr Netzwerkteam zu wenden, um sicherzustellen, dass das virtuelle Gerät Datenverkehr zwischen AKS-Cluster und Speicherkonto an Port 445 zulassen kann.

Ursache 4: Für FIPS aktivierter Knotenpool wird verwendet

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

Beheben Sie dieses Problem mithilfe einer der folgenden Lösungen:

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

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

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

Lösung 2: Erstellen eines Pods, der auf einem für FIPS aktivierten Knoten geplant werden kann

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

  1. Erstellen Sie mit dem CSI-Treiber für Azure Files eine benutzerdefinierte StorageClass, die das Protokoll NFS 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 für NFS die Premium-SKU 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 ein PVC, das auf die benutzerdefinierten 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 azurefile-pvc-fips montiert.

    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

Bereitstellungsfehler (13): Zugriff verweigert

Mögliche Ursachen für diesen Fehler:

Notiz

  • 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 6 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 geheime Kubernetes-Ressource mit dem Namen "azure-storage-account-storage-account-name-secret<>" erstellt.

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

Unabhängig von der Erstellungsmethode schlägt der Einbindungsvorgang mit der Fehlermeldung „Berechtigung verweigert“ fehl, wenn der Name des Speicherkontos oder der Schlüssel, auf den im Kubernetes-Geheimnis verwiesen wird, nicht mit dem tatsächlichen Wert übereinstimmt.

Mögliche Ursachen für Nichtübereinstimmung

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

  • Wenn der Vorgang „Schlüssel rotieren“ auf Speicherkontoebene ausgeführt wird, werden die Änderungen nicht auf Kubernetes-Geheimnisebene widergespiegelt. Dies führt zu einer Nichtübereinstimmung zwischen dem Schlüsselwert auf Speicherkontoebene und dem Wert auf Kubernetes-Geheimnisebene.

    Wenn der Vorgang „Schlüssel rotieren“ erfolgt, wird im Aktivitätsprotokoll des Speicherkontos der Vorgang „Speicherkontoschlüssel neu generieren“ angezeigt. Beachten Sie den Aufbewahrungszeitraum von 90 Tagen für das Aktivitätsprotokoll.

Überprüfen der Nichtübereinstimmung

Führen Sie die folgenden Schritte aus, um die Nichtübereinstimmung zu überprüfen:

  1. Wechseln Sie im Azure-Portal zum Speicherkonto, und greifen Sie darauf zu. Wählen Sie "Zugriffstasten> anzeigen" im Speicherkonto aus. Der Name des Speicherkontos und die zugeordneten Schlüssel werden angezeigt.

    Screenshot des Speicherkontonamens und der Schlüssel.

  2. Wechseln Sie zum AKS-Cluster, wählen Sie "Konfigurationsgeheimnisse>" aus, suchen und greifen Sie dann auf den zugeordneten geheimen Schlüssel zu.

    Screenshot der Suche und Auswahl des Speicherkontos.

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

    Screenshot: Speicherkontoname und Schlüssel in einem geheimen Schlüssel.

    Bevor Sie "Anzeigen" auswählen, werden die Werte des Speicherkontonamens und des zugehörigen Schlüssels in base64-Zeichenfolgen codiert. Nachdem Sie "Anzeigen" ausgewählt haben, werden die Werte decodiert.

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

  1. Rufen Sie die YAML-Datei des Geheimen Kubernetes 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. Decodieren Sie mit dem Befehl echo die Werte des Speicherkontonamens und Schlüssels, und vergleichen Sie sie mit den Werten auf Speicherkontoebene.

    Hier ist ein Beispiel zum Decodieren des Speicherkontonamens:

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

    Screenshot des Befehls zum Decodieren des Speicherkontonamens.

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

Wenn der Wert des Speicherkontonamens oder des Schlüssels im Kubernetes-Schlüssel nicht mit dem Wert in Access-Schlüsseln im Speicherkonto übereinstimmt, passen Sie den Geheimen Kubernetes-Schlüssel auf kubernetes-Ebene an, indem Sie den folgenden Befehl ausführen:

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

Der Wert des Speicherkontonamens oder -Schlüssels, der der Kubernetes-Geheimniskonfiguration hinzugefügt wurde, muss ein base64-codierter Wert sein. Rufen Sie den codierten Wert mit dem Befehl echo ab.

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.

Sobald das Kubernetes-Geheimnis azure-storage-account-<storage-account-name>-secret über die richtigen Werte verfügt, erstellen Sie die Pods neu. Andernfalls werden von diesen Pods weiterhin die alten, nicht mehr gültigen Werte verwendet.

Ursache 2: Das 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 Subnetz des AKS-Clusters aber nicht den ausgewählten Netzwerken hinzugefügt wurden, 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:

    Screenshot des Befehls, der identitätsknoten und ausgabe kann.

  2. Wechseln Sie im Azure-Portal zum AKS-Cluster, wählen Sie die Ressourcengruppe "Eigenschafteninfrastruktur>" aus, greifen Sie auf den dem Knoten zugeordneten VMSS zu, und überprüfen Sie dann das virtuelle Netzwerk/Subnetz, um das VNET und das Subnetz zu identifizieren.

    Screenshot des Virtuellen Netzwerks/Subnetzwerts.

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

    Screenshot der Liste leerer ausgewählter Netzwerke.

    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 dann "Speichern hinzufügen">aus.

    Screenshot des Hinzufügens von Netzwerken zum Speicherkonto.

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

    Screenshot der Befehlsausgabe, die den aktuellen Podstatus anzeigt.

Ursache 3: Konnektivität erfolgt über eine private Verbindung, aber die Knoten und der private 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.

Screenshot der privaten Endpunktverbindung.

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 Einbindungsvorgang mit dem Fehler „Berechtigung verweigert“ fehl.

Wechseln Sie in den Knoten, und überprüfen Sie, ob der vollqualifizierte Domänenname (FQDN) über eine öffentliche oder private IP-Adresse aufgelöst wird. Führen Sie zu diesem Zweck 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 den 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.

Screenshot, der zeigt, dass der FQDN durch eine öffentliche IP-Adresse aufgelöst wird.

Führen Sie die folgenden Schritte aus, um eine virtuelle Netzwerkverbindung zu erstellen:

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

    Der Screenshot zeigt eine virtuelle Netzwerkverbindung, die dem Speicherkonto hinzugefügt wird.

  2. Füllen Sie die Felder aus, und wählen Sie das VNET des AKS-Clusters für virtuelle Netzwerke aus. Informationen zum Bestimmen des VNet des AKS-Clusters finden Sie im Abschnitt Lösung: Zulassen des VNet und Subnetzes von AKS für das Speicherkonto.

    Screenshot zeigt, wie Sie eine virtuelle Netzwerkverbindung hinzufügen.

  3. Wählen Sie OK aus.

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

Screenshot zeigt, dass die private IP-Adresse aufgelöst ist.

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

Die 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 verhindern, dass Clients eine Verbindung herstellen.

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 Profil Maximale Sicherheit oder ein benutzerdefiniertes Profil, das AES-128-GCM deaktiviert, verursachen Freigabezuordnungsfehler.

AKS-Versionen ab 1.25 basieren auf Ubuntu 22.04, das den Linux 5.15-Kernel verwendet und AES-256-GCM unterstützt.

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

Aktivieren Sie den Algorithmus AES-128-GCM, indem Sie das Profil Maximale Kompatibilität oder ein benutzerdefiniertes Profil verwenden, 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

Zum erfolgreichen Bereitstellen oder Zugreifen auf eine Dateifreigabe sollte der AES-128-GCM-Verschlüsselungsalgorithmus für alle Speicherkonten aktiviert werden.

Wenn Sie nur die AES-256-GCM-Verschlüsselung verwenden möchten, 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}

# Check if 'require_gcm_256' is already present in the configuration file
if ! grep -q "require_gcm_256" "${cifsConfPath}"; then

    # Load the CIFS module
    modprobe cifs

    # Set the parameter at runtime
    echo 1 > /sys/module/cifs/parameters/require_gcm_256

    # Persist the configuration
    echo "options cifs require_gcm_256=1" >> "${cifsConfPath}"

    echo "$(date) after changing ${cifsConfPath}:"
    cat "${cifsConfPath}"
else
    echo "require_gcm_256 is already set in ${cifsConfPath}"
fi

Sie können auch ein Kubernetes DaemonSet verwenden, um AES-256 auf jedem Knoten zu erzwingen. Siehe folgendes Beispiel:

support-cifs-aes-256-gcm.yaml

Windows

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

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

Notiz

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

Ursache 6: Sicherheitsprofil wird verwendet, ohne dass die NTLM v2-Authentifizierung aktiviert ist

Wenn Sie das maximale Sicherheitsprofil oder ein benutzerdefiniertes Sicherheitsprofil ohne aktivierten NTLM v2-Authentifizierungsmechanismus verwenden, schlägt der Montagevorgang mit dem Fehler "Mount error(13): Permission denied" fehl.

Lösung: Aktivieren der NTLM v2-Authentifizierung oder Verwenden des Profils "Maximale Kompatibilität"

Um es in AKS ordnungsgemäß bereitzustellen, müssen Sie den NTLM v2-Authentifizierungsmechanismus für das benutzerdefinierte Sicherheitsprofil aktivieren oder das Sicherheitsprofil für maximale Kompatibilität verwenden.

Weitere Informationen

Wenn andere Bereitstellungsfehler auftreten, lesen Sie die Problembehandlung von Azure Files in 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.