Impossible de monter le partage de fichiers Azure - Azure

Article
11/20/2024

Cet article fournit des causes et des solutions possibles pour les erreurs qui entraînent l’échec du montage d’un partage de fichiers Azure.

Symptômes

Vous déployez une ressource Kubernetes, comme un déploiement ou un StatefulSet, dans un environnement Azure Kubernetes Service (AKS). Le déploiement crée un pod qui monte un PVC (PersistentVolumeClaim) faisant référence à un partage de fichiers Azure.

Toutefois, le pod reste dans l’état ContainerCreating. Lorsque vous exécutez la kubectl describe pods commande, vous pouvez voir l’une des erreurs suivantes dans la sortie de commande, ce qui entraîne l’échec de l’opération de montage :

Erreur de montage (2) : No such file or directory
Erreur de montage (13) : Autorisation refusée

Consultez l’exemple de sortie suivant :

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)

Note

Si le compte de stockage est accessible publiquement, le nom d’hôte affiché dans la sortie est storage-account-name.file.core.windows.net>.<
Si le compte de stockage est configuré en privé avec une liaison privée, un point de terminaison ou une zone DNS, le nom d’hôte est storage-account-name.privatelink.file.core.windows.net>.<

Avant la résolution des problèmes

En fonction du message dans la sortie, comme indiqué dans l’exemple suivant, identifiez le compte de stockage et le partage de fichiers : ces valeurs seront utilisées dans les étapes de résolution des problèmes ultérieures.

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

Pour connaître les causes possibles de cette erreur et leurs solutions, consultez les sections suivantes.

Erreur de montage (2) : No such file or directory

Cette erreur indique qu’il n’existe aucune connectivité entre le cluster AKS et le compte de stockage.

Résolution initiale des problèmes

Azure File s’appuie sur le protocole SMB (port 445). Assurez-vous que le port 445 et/ou l’adresse IP du compte de stockage ne sont pas bloqués.

Pour vérifier l’adresse IP du compte de stockage, exécutez une commande DNS (Domain Name System) telle que nslookup, digou host. Par exemple :

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

Pour vérifier s’il existe une connectivité entre le cluster AKS et le compte de stockage, accédez au nœud ou au pod et exécutez la commande suivante nc ou telnet :

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

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

Causes possibles de l’erreur de montage(2)

Cause 1 : Le partage de fichiers n’existe pas
Cause 2 : NSG bloque le trafic entre AKS et le compte de stockage
Cause 3 : L’appliance virtuelle bloque le trafic entre AKS et le compte de stockage
Cause 4 : le pool de nœuds compatible FIPS est utilisé

Note

Les causes 1, 2 et 4 s’appliquent aux scénarios de compte de stockage public et privé.
La cause 3 s’applique uniquement au scénario public.

Cause 1 : Le partage de fichiers n’existe pas

Pour vérifier si le partage de fichiers existe, procédez comme suit :

Recherchez des comptes de stockage dans le Portail Azure et accédez à votre compte de stockage.
Sélectionnez Partages de fichiers sous Stockage de données dans le compte de stockage et vérifiez si l’élément PersistentVolumeClaim associé dans le fichier yaml du pod, du déploiement ou de l’ensemble avec état existe dans les partages de fichiers.

Pour résoudre ce problème, assurez-vous que le partage de fichiers associé au PV/PVC existe.

Cause 2 : Le groupe de sécurité réseau bloque le trafic entre AKS et le compte de stockage

Vérifiez la sortie de la ou de la nc commande mentionnée dans la section Résolution des problèmes initiales.telnet Si un délai d’expiration s’affiche, vérifiez le groupe de sécurité réseau (NSG) et assurez-vous que l’adresse IP du compte de stockage n’est pas bloquée.

Pour vérifier si le groupe de sécurité réseau bloque l’adresse IP du compte de stockage, procédez comme suit :

Dans le Portail Azure, accédez à Network Watcher et sélectionnez diagnostic NSG.
Renseignez les champs en utilisant les valeurs suivantes :
- Protocole : N’importe laquelle
- Direction : sortant
- Type de source : adresse IPv4/CIDR
- Adresse IPv4/CIDR : adresse IP d’une instance associée au nœud AKS
- Adresse IP de destination : adresse IP du compte de stockage
- Port de destination : 445
Sélectionnez le bouton Vérifier et vérifiez l’état du trafic .

L’état du trafic peut être autorisé ou refusé. L’état Refusé signifie que le groupe de sécurité réseau bloque le trafic entre le cluster AKS et le compte de stockage. Si l’état est refusé, le nom du groupe de sécurité réseau s’affiche.

Solution : Autoriser la connectivité entre AKS et le compte de stockage

Pour résoudre ce problème, effectuez les modifications en conséquence au niveau du groupe de sécurité réseau pour permettre la connectivité entre le cluster AKS et le compte de stockage sur le port 445.

Cause 3 : L’appliance virtuelle bloque le trafic entre AKS et le compte de stockage

Si vous utilisez une appliance virtuelle (généralement un pare-feu) pour contrôler le trafic sortant du cluster AKS (par exemple, une table de routage est appliquée à l’appliance virtuelle au niveau du sous-réseau du cluster AKS et que la table de routage contient des itinéraires qui envoient le trafic vers l’appliance virtuelle), l’appliance virtuelle peut bloquer le trafic entre le cluster AKS et le compte de stockage.

Pour isoler le problème, ajoutez un itinéraire dans la table de routage pour l’adresse IP du compte de stockage afin d’envoyer le trafic vers Internet.

Pour vérifier quelle table de routage contrôle le trafic du cluster AKS, procédez comme suit :

Accédez au cluster AKS dans le Portail Azure, puis sélectionnez Groupe de ressources d’infrastructure des propriétés>.
Accédez au groupe de machines virtuelles identiques (VMSS) ou à une machine virtuelle dans un groupe à haute disponibilité si vous utilisez ce type de jeu de machines virtuelles.
Sélectionnez Sous-réseaux de réseau virtuel/sous-réseau> et identifiez le sous-réseau du cluster AKS. Sur le côté droit, vous verrez la table de routage.

Pour ajouter l’itinéraire dans la table de routage, suivez les étapes décrites dans Créer un itinéraire et renseignez les champs suivants :

Préfixe d’adresse : <storage-account’s-public-IP>/32
Type de tronçon suivant :Internet

Cet itinéraire envoie tout le trafic entre le cluster AKS et le compte de stockage via l’Internet public.

Après avoir ajouté l’itinéraire, testez la connectivité à l’aide de la commandenc ou telnet et effectuez à nouveau l’opération de montage.

Solution : Vérifiez que l’appliance virtuelle autorise le trafic entre AKS et le compte de stockage

Si l’opération de montage réussit, nous vous recommandons de consulter votre équipe de mise en réseau pour vous assurer que l’appliance virtuelle peut autoriser le trafic entre le cluster AKS et le compte de stockage sur le port 445.

Cause 4 : le pool de nœuds compatible FIPS est utilisé

Si vous utilisez un pool de nœuds compatible FIPS (Federal Information Processing Standard), l’opération de montage échoue, car FIPS désactive certains modules d’authentification, ce qui empêche le montage d’un partage CIFS. Ce comportement est attendu et non spécifique à AKS.

Pour résoudre le problème, utilisez l’une des solutions suivantes :

Solution 1 : Planifier des pods sur des nœuds dans un pool de nœuds non FIPS

FIPS est désactivé par défaut sur les pools de nœuds AKS et peut être activé uniquement lors de la création du pool de nœuds à l’aide du paramètre --enable-fips-image.

Pour résoudre l’erreur, vous pouvez planifier les pods sur les nœuds d’un pool de nœuds non-FIPS.

Solution 2 : Créer un pod qui peut être planifié sur un nœud compatible FIPS

Pour créer un pod qui peut être planifié sur un nœud compatible FIPS, procédez comme suit :

Utilisez le pilote CSI Azure File pour créer un StorageClass personnalisé qui utilise le protocole NFS.

Reportez-vous au fichier YAML suivant comme exemple :
```
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 
```
La référence SKU est définie sur Premium_LRS dans le fichier YAML, car la référence SKU Premium est requise pour NFS. Pour plus d’informations, consultez Provision dynamique.

En raison de la référence SKU Premium, la taille minimale du partage de fichiers est de 100 Go. Pour plus d’informations, consultez Créer une classe de stockage.

Créez un PVC qui fait référence à storageClass azurefile-sc-fips personnalisé.

Reportez-vous au fichier YAML suivant comme exemple :

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

Créez un pod qui monte le pvc azurefile-pvc-fips.

Reportez-vous au fichier YAML suivant comme exemple :

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

Erreur de montage (13) : Autorisation refusée

Voici les causes possibles de cette erreur :

Cause 1 : le secret Kubernetes ne référence pas le nom ou la clé du compte de stockage corrects
Cause 2 : le réseau virtuel et le sous-réseau AKS ne sont pas autorisés pour le compte de stockage
Cause 3 : La connectivité est via une liaison privée, mais les nœuds et le point de terminaison privé se trouvent dans différents réseaux virtuels
Cause 4 : le compte de stockage est défini pour exiger un chiffrement que le client ne prend pas en charge
Cause 5 : La condition minimale de chiffrement d’un compte de stockage n’est pas remplie
Cause 6 : Le profil de sécurité est utilisé sans l’authentification NTLM v2 activée

Note

La cause 1 s’applique aux scénarios publics et privés.
La cause 2 s’applique uniquement au scénario public.
La cause 3 s’applique uniquement au scénario privé.
La cause 4 s’applique aux scénarios publics et privés.
La cause 5 s’applique aux scénarios publics et privés.
La cause 6 s’applique aux scénarios publics et privés.

Cause 1 : le secret Kubernetes ne référence pas le nom ou la clé de compte de stockage corrects

Si le partage de fichiers est créé dynamiquement, une ressource secrète Kubernetes est automatiquement créée avec le nom « azure-storage-account-storage-account-name-secret<> ».

Si le partage de fichiers est créé manuellement, la ressource secrète Kubernetes doit être créée manuellement.

Quelle que soit la méthode de création, si le nom du compte de stockage ou la clé référencée dans le secret Kubernetes ne correspond pas à la valeur réelle, l’opération de montage échoue avec l’erreur « Autorisation refusée ».

Causes possibles de l’incompatibilité

Si le secret Kubernetes est créé manuellement, une faute de frappe peut se produire pendant la création.
Si une opération de rotation de clé est effectuée au niveau du compte de stockage, les modifications ne se reflètent pas au niveau du secret Kubernetes. Cela entraîne une incompatibilité entre la valeur de clé au niveau du compte de stockage et la valeur au niveau du secret Kubernetes.

Si une opération « Rotation de clé » se produit, une opération portant le nom « Régénérer les clés de compte de stockage » s’affiche dans le journal d’activité du compte de stockage. Tenez compte de la période de rétention de 90 jours pour le journal d’activité.

Vérifier l’incompatibilité

Pour vérifier l’incompatibilité, procédez comme suit :

Recherchez et accédez au compte de stockage dans le Portail Azure. Sélectionnez Clés d’accès Afficher les clés> dans le compte de stockage. Le nom du compte de stockage et les clés associées s’affichent.
Accédez au cluster AKS, sélectionnez Secrets de configuration>, puis recherchez et accédez au secret associé.
Sélectionnez Afficher (l’icône d’œil) et comparez les valeurs du nom du compte de stockage et de la clé associée aux valeurs de l’étape 1.

Avant de sélectionner Afficher, les valeurs du nom du compte de stockage et de la clé associée sont encodées en chaînes base64. Après avoir sélectionné Afficher, les valeurs sont décodées.

Si vous n’avez pas accès au cluster AKS dans le Portail Azure, effectuez l’étape 2 au niveau kubectl :

Obtenez le fichier YAML du secret Kubernetes, puis exécutez la commande suivante pour obtenir les valeurs du nom du compte de stockage et de la clé à partir de la sortie :
```
kubectl get secret <secret-name> -n <secret-namespace> -o <yaml-file-name>
```
Utilisez la commande echopour décoder les valeurs du nom du compte de stockage et de la clé, puis comparez-les avec les valeurs au niveau du compte de stockage.

Voici un exemple pour décoder le nom du compte de stockage :
```
echo -n '<storage account name>' | base64 --decode ;echo
```

Solution : ajustez le secret Kubernetes et recréez les pods

Si la valeur du nom ou de la clé du compte de stockage dans le secret Kubernetes ne correspond pas à la valeur des clés d’accès dans le compte de stockage, ajustez le secret Kubernetes au niveau du secret Kubernetes en exécutant la commande suivante :

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

La valeur du nom du compte de stockage ou de la clé ajoutée dans la configuration du secret Kubernetes doit être une valeur encodée en base64. Pour obtenir la valeur encodée, utilisez la commande echo.

Voici un exemple d’encodage du nom du compte de stockage :

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

Pour plus d’informations, consultez Gestion des secrets à l’aide de kubectl.

Une fois que le secret Kubernetesazure-storage-account-<storage-account-name>-secret a les bonnes valeurs, recréez les pods. Sinon, ces pods continueront d’utiliser les anciennes valeurs qui ne sont plus valides.

Cause 2 : le réseau virtuel et le sous-réseau d’AKS ne sont pas autorisés pour le compte de stockage

Si le réseau du compte de stockage est limité aux réseaux sélectionnés, mais que le réseau virtuel et le sous-réseau du cluster AKS ne sont pas ajoutés aux réseaux sélectionnés, l’opération de montage échoue avec l’erreur « Autorisation refusée ».

Solution : Autoriser le réseau virtuel et le sous-réseau d’AKS pour le compte de stockage

Identifiez le nœud qui héberge le pod défectueux en exécutant la commande suivante :
```
kubectl get pod <pod-name> -n <namespace> -o wide
```
Vérifiez le nœud à partir de la sortie de commande :
Accédez au cluster AKS dans le Portail Azure, sélectionnez Groupe de ressources d’infrastructure des propriétés>, accédez à VMSS associé au nœud, puis vérifiez le réseau virtuel/sous-réseau pour identifier le réseau virtuel et le sous-réseau.
Accédez au compte de stockage dans le Portail Azure. Sélectionnez Mise en réseau. Si Autoriser l’accès à partir de est défini sur réseaux sélectionnés, vérifiez si le réseau virtuel et le sous-réseau du cluster AKS sont ajoutés.

Si le réseau virtuel et le sous-réseau du cluster AKS ne sont pas ajoutés, sélectionnez Ajouter un réseau virtuel existant. Dans la page Ajouter des réseaux, tapez le réseau virtuel et le sous-réseau du cluster AKS, puis sélectionnez Ajouter un>enregistrement.

Il peut s’écouler quelques instants avant que les modifications prennent effet. Une fois le réseau virtuel et le sous-réseau ajoutés, vérifiez si l’état du pod passe de ContainerCreating à l’exécution.

Cause 3 : La connectivité se fait via une liaison privée, mais les nœuds et le point de terminaison privé se trouvent dans des réseaux virtuels différents

Lorsque le cluster AKS et le compte de stockage sont connectés via une liaison privée, une connexion de point de terminaison privée approuvée est utilisée.

Dans ce scénario, si le point de terminaison privé et le nœud AKS se trouvent dans le même réseau virtuel, vous pouvez monter un partage de fichiers Azure.

Si le point de terminaison privé et votre cluster AKS se trouvent dans des réseaux virtuels différents, l’opération de montage échoue avec l’erreur « Autorisation refusée ».

Solution : Créer une liaison de réseau virtuel pour le réseau virtuel du cluster AKS dans la zone DNS privée

Entrez à l’intérieur du nœud et vérifiez si le nom de domaine complet (FQDN) est résolu via une adresse IP publique ou privée. Pour ce faire, exécutez la commande suivante :

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

Si le nom de domaine complet est résolu via une adresse IP publique (voir la capture d’écran suivante), créez un lien réseau virtuel pour le réseau virtuel du cluster AKS au niveau de la zone DNS privée (« privatelink.file.core.windows.net »). Notez qu’une liaison de réseau virtuel est déjà créée automatiquement pour le réseau virtuel du point de terminaison privé du compte de stockage.

Pour créer un lien de réseau virtuel, procédez comme suit :

Accédez à la zone DNS privé et sélectionnez Liens>de réseau virtuel Ajouter.
Renseignez les champs et sélectionnez le réseau virtuel du cluster AKS pour les réseaux virtuels. Pour savoir comment identifier le réseau virtuel du cluster AKS, consultez la section Solution : Autoriser le réseau virtuel et le sous-réseau d’AKS pour le compte de stockage .
Cliquez sur OK.

Une fois la liaison de réseau virtuel ajoutée, le nom de domaine complet doit être résolu via une adresse IP privée et l’opération de montage doit réussir. Consultez la capture d’écran suivante pour obtenir un exemple :

Cause 4 : le compte de stockage est défini pour exiger un chiffrement que le client ne prend pas en charge

Paramètres de sécurité Azure Files contiennent un certain nombre d’options pour contrôler les paramètres de sécurité et de chiffrement sur les comptes de stockage. La restriction des méthodes et algorithmes autorisés peut empêcher les clients de se connecter.

Les versions d’AKS antérieures à 1.25 sont basées sur Ubuntu 18.04 LTS, qui utilise le noyau Linux 5.4 et prend uniquement en charge les algorithmes de chiffrement AES-128-CCM et AES-128-GCM. Le profil de sécurité maximal, ou un profil personnalisé qui désactive AES-128-GCM, entraîne des échecs de mappage de partage.

AKS versions 1.25 et ultérieures sont basées sur Ubuntu 22.04, qui utilise le noyau Linux 5.15 et prend en charge AES-256-GCM.

Solution : Autoriser l’utilisation de l’algorithme de chiffrement AES-128-GCM

Activez l’algorithme AES-128-GCM à l’aide du profil de compatibilité maximale ou d’un profil personnalisé qui active AES-128-GCM. Pour plus d’informations, consultez paramètres de sécurité Azure Files.

Cause 5 : La condition minimale de chiffrement d’un compte de stockage n’est pas remplie

Solution : activer l’algorithme de chiffrement AES-128-GCM pour tous les comptes de stockage

Pour monter ou accéder à un partage de fichiers, l’algorithme de chiffrement AES-128-GCM doit être activé pour tous les comptes de stockage.

Si vous souhaitez utiliser le chiffrement AES-256-GCM uniquement, procédez comme suit :

Linux

Utilisez le script suivant pour vérifier si le client prend en charge AES-256-GCM et appliquez-le uniquement s’il le fait :

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

Vous pouvez également utiliser un DaemonSet Kubernetes pour appliquer AES-256 à chaque nœud. Voir l’exemple suivant :

support-cifs-aes-256-gcm.yaml

Windows

Utilisez la commande PowerShell Set-SmbClientConfiguration pour spécifier les chiffrements utilisés par le client SMB et le type de chiffrement préféré sans confirmation de l’utilisateur :

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

Note

Le EncryptionCiphers paramètre est disponible à compter de la mise à jour cumulative 2022-06 pour Windows Server version 21H2 pour les systèmes x64 (KB5014665) et de la mise à jour cumulative pour Windows 11, version 22H2 (KB5014668).

Cause 6 : Le profil de sécurité est utilisé sans l’authentification NTLM v2 activée

Lorsque vous utilisez le profil de sécurité maximal ou un profil de sécurité personnalisé sans le mécanisme d’authentification NTLM v2 activé, l’opération de montage échoue avec l’erreur « Erreur de montage (13) : Autorisation refusée ».

Solution : activez l’authentification NTLM v2 ou utilisez le profil « Compatibilité maximale »

Pour le monter correctement dans AKS, vous devez activer le mécanisme d’authentification NTLM v2 pour le profil de sécurité personnalisé ou utiliser le profil de sécurité de compatibilité maximale.

Plus d’informations

Si vous rencontrez d’autres erreurs de montage, consultez Résoudre les problèmes liés à Azure Files dans Linux.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.

Partager via

Symptômes

Avant la résolution des problèmes

Erreur de montage (2) : No such file or directory

Résolution initiale des problèmes

Causes possibles de l’erreur de montage(2)

Cause 1 : Le partage de fichiers n’existe pas

Cause 2 : Le groupe de sécurité réseau bloque le trafic entre AKS et le compte de stockage

Solution : Autoriser la connectivité entre AKS et le compte de stockage

Cause 3 : L’appliance virtuelle bloque le trafic entre AKS et le compte de stockage

Solution : Vérifiez que l’appliance virtuelle autorise le trafic entre AKS et le compte de stockage

Cause 4 : le pool de nœuds compatible FIPS est utilisé

Solution 1 : Planifier des pods sur des nœuds dans un pool de nœuds non FIPS

Solution 2 : Créer un pod qui peut être planifié sur un nœud compatible FIPS

Erreur de montage (13) : Autorisation refusée

Cause 1 : le secret Kubernetes ne référence pas le nom ou la clé de compte de stockage corrects

Causes possibles de l’incompatibilité

Vérifier l’incompatibilité

Solution : ajustez le secret Kubernetes et recréez les pods

Cause 2 : le réseau virtuel et le sous-réseau d’AKS ne sont pas autorisés pour le compte de stockage

Solution : Autoriser le réseau virtuel et le sous-réseau d’AKS pour le compte de stockage

Cause 3 : La connectivité se fait via une liaison privée, mais les nœuds et le point de terminaison privé se trouvent dans des réseaux virtuels différents

Solution : Créer une liaison de réseau virtuel pour le réseau virtuel du cluster AKS dans la zone DNS privée

Cause 4 : le compte de stockage est défini pour exiger un chiffrement que le client ne prend pas en charge

Solution : Autoriser l’utilisation de l’algorithme de chiffrement AES-128-GCM

Cause 5 : La condition minimale de chiffrement d’un compte de stockage n’est pas remplie

Solution : activer l’algorithme de chiffrement AES-128-GCM pour tous les comptes de stockage

Linux

Windows

Cause 6 : Le profil de sécurité est utilisé sans l’authentification NTLM v2 activée

Solution : activez l’authentification NTLM v2 ou utilisez le profil « Compatibilité maximale »

Plus d’informations

Contactez-nous pour obtenir de l’aide

Commentaires

Ressources supplémentaires

Partager via

Erreurs lors du montage d’un partage de fichiers Azure

Symptômes

Avant la résolution des problèmes

Erreur de montage (2) : No such file or directory

Résolution initiale des problèmes

Causes possibles de l’erreur de montage(2)

Cause 1 : Le partage de fichiers n’existe pas

Solution : S’assurer de l’existence du partage de fichiers

Cause 2 : Le groupe de sécurité réseau bloque le trafic entre AKS et le compte de stockage

Solution : Autoriser la connectivité entre AKS et le compte de stockage

Cause 3 : L’appliance virtuelle bloque le trafic entre AKS et le compte de stockage

Solution : Vérifiez que l’appliance virtuelle autorise le trafic entre AKS et le compte de stockage

Cause 4 : le pool de nœuds compatible FIPS est utilisé

Solution 1 : Planifier des pods sur des nœuds dans un pool de nœuds non FIPS

Solution 2 : Créer un pod qui peut être planifié sur un nœud compatible FIPS

Erreur de montage (13) : Autorisation refusée

Cause 1 : le secret Kubernetes ne référence pas le nom ou la clé de compte de stockage corrects

Causes possibles de l’incompatibilité

Vérifier l’incompatibilité

Solution : ajustez le secret Kubernetes et recréez les pods

Cause 2 : le réseau virtuel et le sous-réseau d’AKS ne sont pas autorisés pour le compte de stockage

Solution : Autoriser le réseau virtuel et le sous-réseau d’AKS pour le compte de stockage

Cause 3 : La connectivité se fait via une liaison privée, mais les nœuds et le point de terminaison privé se trouvent dans des réseaux virtuels différents

Solution : Créer une liaison de réseau virtuel pour le réseau virtuel du cluster AKS dans la zone DNS privée

Cause 4 : le compte de stockage est défini pour exiger un chiffrement que le client ne prend pas en charge

Solution : Autoriser l’utilisation de l’algorithme de chiffrement AES-128-GCM

Cause 5 : La condition minimale de chiffrement d’un compte de stockage n’est pas remplie

Solution : activer l’algorithme de chiffrement AES-128-GCM pour tous les comptes de stockage

Linux

Windows

Cause 6 : Le profil de sécurité est utilisé sans l’authentification NTLM v2 activée

Solution : activez l’authentification NTLM v2 ou utilisez le profil « Compatibilité maximale »

Plus d’informations

Contactez-nous pour obtenir de l’aide

Commentaires

Ressources supplémentaires