Partager via

Résolution des problèmes Azure Files avec Linux (SMB)

  • Article

Cet article répertorie les problèmes courants qui peuvent se produire lors de l’utilisation de partages de fichiers Azure SMB avec des clients Linux. Il fournit également les causes possibles et les solutions de ces problèmes.

Vous pouvez utiliser AzFileDiagnostics pour automatiser la détection des symptômes et vous assurer que le client Linux dispose des prérequis appropriés. Il vous aide à configurer votre environnement pour obtenir des performances optimales. Vous pouvez également trouver ces informations dans l’utilitaire de résolution des problèmes de partages de fichiers Azure.

Important

Cet article s’applique uniquement aux partages SMB. Pour plus d’informations sur les partages NFS, consultez Résoudre les problèmes des partages de fichiers NFS Azure.

S’applique à

Type de partage de fichiers SMB NFS
Partages de fichiers Standard (GPv2), LRS/ZRS
Partages de fichiers Standard (GPv2), GRS/GZRS
Partages de fichiers Premium (FileStorage), LRS/ZRS

Les horodatages ont été perdus lors de la copie de fichiers

Sur les plateformes Linux/Unix, la cp -p commande échoue si différents utilisateurs possèdent un fichier 1 et un fichier 2.

Cause

L’indicateur f de force dans COPYFILE entraîne l’exécution cp -p -f sur Unix. Cette commande échoue également dans la conservation de l’horodatage du fichier que vous ne possédez pas.

Solution de contournement

Utilisez l’utilisateur du compte de stockage pour copier les fichiers :

  • str_acc_name=[storage account name]
  • sudo useradd $str_acc_name
  • sudo passwd $str_acc_name
  • su $str_acc_name
  • cp -p filename.txt /share

ls : impossible d’accéder à « <chemin> » : Erreur d’entrée/sortie

Lorsque vous essayez de répertorier des fichiers dans un partage de fichiers Azure à l’aide de la ls commande, la commande se bloque lors de la liste des fichiers. Vous obtenez l’erreur suivante :

ls : impossible d’accéder à « <chemin> » : Erreur d’entrée/sortie

Solution

Mettez à niveau le noyau Linux vers les versions suivantes qui incluent un correctif pour ce problème :

  • 4.4.87+
  • 4.9.48+
  • 4.12.11+
  • Toutes les versions à partir de 4.13

Impossible de créer des liens symboliques - Dans : impossible de créer le lien symbolique « t » : Opération non prise en charge

Cause

Par défaut, le montage des partages de fichiers Azure sur Linux à l’aide de SMB n’active pas la prise en charge des liens symboliques (symlinks). Une erreur comme celle-ci peut s’afficher :

sudo ln -s linked -n t

ln: failed to create symbolic link 't': Operation not supported

Solution

Le client Linux SMB ne prend pas en charge la création de liens symboliques de type Windows via le protocole SMB 2 ou 3. Le client Linux prend actuellement en charge un autre style de liens symboliques appelés liens symboliques Mishall+French pour créer et suivre les opérations. Les clients ayant besoin de liens symboliques peuvent utiliser l’option de montage « mfsymlinks ». Nous recommandons « mfsymlinks », car il s’agit également du format utilisé par les ordinateurs Mac.

Pour utiliser les liens symboliques, ajoutez le code suivant à la fin de votre commande de montage SMB :

,mfsymlinks

Par conséquent, la commande ressemble à ce qui suit :

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-name> <mount-point> -o vers=<smb-version>,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks

Vous pouvez ensuite créer des liens symboliques comme suggéré sur le wiki.

Impossible d’accéder aux dossiers ou aux fichiers dont le nom contient un espace ou un point à la fin

Vous ne pouvez pas accéder aux dossiers ou aux fichiers à partir du partage de fichiers Azure lors du montage sur Linux. Les commandes telles que du et ls et/ou les applications tierces peuvent échouer avec une erreur « Aucun fichier ou répertoire de ce type » lors de l’accès au partage ; toutefois, vous pouvez charger ces fichiers vers ces dossiers via le portail Azure.

Cause

Les dossiers ou fichiers ont été téléchargés depuis un système qui chiffre les caractères à la fin du nom sur un caractère différent. Les fichiers chargés à partir d’un ordinateur Macintosh peuvent avoir un caractère « 0xF028 » ou « 0xF029 » au lieu de 0x20 (espace) ou 0X2E (point).

Solution

Utilisez l’option mapchars sur le partage lors du montage du partage sur Linux :

À la place de :

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino

Utilisez :

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,mapchars

Problèmes DNS liés à la migration dynamique de comptes de stockage Azure

Les E/S de fichiers sur le système de fichiers monté commencent à retourner des erreurs « Hôte hors service » ou « Autorisation refusée ». Les journaux dmesg Linux sur le client présentent des erreurs répétées telles que :

Status code returned 0xc000006d STATUS_LOGON_FAILURE
cifs_setup_session: 2 callbacks suppressed
CIFS VFS: \\contoso.file.core.windows.net Send error in SessSetup = -13

Vous verrez également que le nom de domaine complet du serveur est désormais résolu en une adresse IP différente de celle à laquelle il est actuellement connecté. Ce problème peut se produire dans n’importe quel scénario où l’adresse IP du serveur peut changer, comme la migration de compte. Un autre scénario connu est le basculement du compte de stockage, car le mappage DNS peut changer.

Cause

À des fins d’équilibrage de charge de capacité, les comptes de stockage sont parfois migrés en direct d’un cluster de stockage vers un autre. La migration de compte déclenche une redirection du trafic Azure Files du cluster source vers le cluster de destination en mettant à jour les mappages DNS pour qu’ils pointent vers le cluster de destination. Tout le trafic vers le cluster source à partir de ce compte est alors bloqué. Il est prévu que le client SMB récupère les mises à jour DNS et redirige le trafic vers le cluster de destination. Toutefois, en raison d’un bogue dans le client de noyau SMB Linux, cette redirection n’a pas lieu. Par conséquent, le trafic de données est passé au cluster source, qui a cessé de servir ce compte après la migration.

Solution de contournement

Vous pouvez atténuer ce problème en redémarrant simplement le système d’exploitation client, mais vous risquez de reproduire le problème si vous ne mettez pas à niveau votre système d’exploitation client vers une version de distribution Linux avec prise en charge de la migration de compte.

Lors du démontage et de la remontage du partage peut sembler résoudre temporairement le problème, il ne s’agit pas d’une solution permanente. Lorsque le client se reconnecte au serveur, le problème peut se produire à nouveau. L’atténuation temporaire se produit parce qu’une nouvelle action de montage contourne le cache du noyau SMB et résout l’adresse DNS dans l’espace utilisateur. Toutefois, le cache DNS du noyau est utilisé pendant toute récupération de déconnexion réseau, ce qui peut entraîner la réoccupée du problème. Ce comportement persiste même en dehors des migrations de compte de stockage.

Pour mieux contourner ce problème, effacez le cache du programme de résolution DNS du noyau :

  1. Affichez l’état du module de noyau dns_resolver en exécutant la commande suivante :

    grep '.dns_resolver' /proc/keys

    Vous devez voir la sortie de commande comme dans l’exemple suivant :

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: 1

  2. Effacez le cache du programme de résolution DNS du noyau en exécutant la commande suivante :

    sudo keyctl clear $((16#$(grep '.dns_resolver' /proc/keys | cut -f1 -d\ ) ))

  3. Affichez à nouveau l’état du module du noyau dns_resolver :

    grep '.dns_resolver' /proc/keys

    Vous devez voir la sortie de commande comme dans l’exemple suivant, indiquant que le cache est maintenant vide :

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty

  4. Démonter et remonter le partage pour atténuer le problème.

Note

Sur certaines distributions Linux plus anciennes, les étapes d’atténuation précédentes peuvent ne pas fonctionner. Dans ce cas, le redémarrage du système d’exploitation client est la seule atténuation connue.

Solution

Pour obtenir un correctif permanent, mettez à niveau votre système d’exploitation client vers une version de distribution Linux avec la prise en charge de la migration de compte. Plusieurs correctifs pour le client de noyau SMB Linux ont récemment été envoyés au noyau Linux principal. Les distributions suivantes ont les correctifs :

  • Ubuntu : 20.04, 22.04, 24.04 et AKS 22.04 (les correctifs sont déployés dans le noyau version 5.15.0-1068)
  • RHEL : 8.6+
  • SLES : 15SP2, 15SP3, 15SP4 et 15SP5
  • Azure Linux : 2.0 (les correctifs sont déployés dans le noyau version 5.15.159.1) et 3.0

Certaines distributions ont rétroporté ces correctifs. Vous pouvez vérifier si les correctifs suivants existent dans la version de distribution que vous utilisez :

Impossible de monter le partage de fichiers SMB lorsque FIPS est activé

Lorsque Federal Information Processing Standard (FIPS) est activé sur une machine virtuelle Linux, le partage de fichiers SMB ne peut pas être monté. Les journaux dmesg Linux sur le client affichent des erreurs telles que :

kernel: CIFS: VFS: Could not allocate crypto hmac(md5)
kernel: CIFS: VFS: Error -2 during NTLMSSP authentication
kernel: CIFS: VFS: \\contoso.file.core.windows.net Send error in SessSetup = -2
kernel: CIFS: VFS: cifs_mount failed w/return code = -2

Important

FIPS est un ensemble de normes que le gouvernement américain utilise pour garantir la sécurité et l’intégrité des systèmes informatiques. Lorsqu’un système est en mode FIPS, il respecte les exigences de chiffrement spécifiques décrites par ces normes.

Cause

Le client du partage de fichiers SMB utilise l’authentification NTLMSSP, ce qui nécessite l’algorithme de hachage MD5. Toutefois, en mode FIPS, l’algorithme MD5 est limité, car il n’est pas conforme à FIPS. MD5 est une fonction de hachage largement utilisée qui produit une valeur de hachage 128 bits. Toutefois, MD5 est considéré comme non sécurisé à des fins de chiffrement.

Comment vérifier si le mode FIPS est activé

Pour vérifier si le mode FIPS est activé sur le client, exécutez la commande suivante. Si la valeur est définie sur 1, FIPS est activée.

sudo cat /proc/sys/crypto/fips_enabled

Solution

Pour résoudre ce problème, activez l’authentification Kerberos pour le partage de fichiers SMB. Si FIPS est activé involontairement, reportez-vous à l’option2 pour la désactiver.

Option 1 : Activer l’authentification Kerberos pour le partage de fichiers SMB

Pour monter un partage de fichiers SMB sur la machine virtuelle Linux où FIPS est activé, utilisez l’authentification Kerberos/Azure AD. Pour plus d’informations, consultez Activer l’authentification Active Directory sur SMB pour les clients Linux accédant à Azure Files.

Option 2 : Désactiver FIPS pour monter le partage Samba

  1. Remplacez la valeur sysctl par crypto.fips_enabled 0 in /etc/sysctl.conf.

  2. Modifiez le GRUB_CMDLINE_LINUX_DEFAULT fichier et /etc/default/grub supprimez le paramètre fips=1.

  3. Régénéré le fichier de configuration grub2 avec la commande suivante :

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

  4. Régénérez l’image initramfs avec la commande suivante :

    sudo dracut -fv

  5. Redémarrez la machine virtuelle.

Pour plus d’informations, consultez les documents suivants des distributeurs Linux :

Vous avez besoin d’aide ?

Si vous avez encore besoin d’aide, contactez le support technique pour résoudre rapidement votre problème.

Voir aussi

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.