Partager via

Résoudre les problèmes de Azure Files dans 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 à ces problèmes.

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

Importante

Cet article s’applique uniquement aux partages SMB. Pour plus d’informations sur les partages NFS, consultez Résoudre les problèmes liés aux 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 le fichier 1 et le fichier 2.

Cause

L’indicateur f de force dans COPYFILE entraîne l’exécution cp -p -f sur Unix. Cette commande ne parvient pas non plus à conserver l’horodatage du fichier dont vous n’êtes pas propriétaire.

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 ont un correctif pour ce problème :

  • 4.4.87+
  • 4.9.48+
  • 4.12.11+
  • Toutes les versions supérieures ou égales à 4.13

Impossible de créer des liens symboliques - ln : échec de la création du lien symbolique 't' : Opération non prise en charge

Cause

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

sudo ln -s linked -n t

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

Solution

Le client SMB Linux ne prend pas en charge la création de liens symboliques de style Windows via le protocole SMB 2 ou 3. Actuellement, le client Linux prend en charge un autre style de liens symboliques appelé Minshall+Français symlinks pour les opérations de création et de suivi. Les clients qui ont besoin de liens symboliques peuvent utiliser l’option de montage « mfsymlinks ». Nous recommandons « mfsymlinks », car il s’agit également du format utilisé par les Mac.

Pour utiliser des liens symboliques, ajoutez ce qui suit à la fin de votre commande de montage SMB :

,mfsymlinks

Par conséquent, la commande se présente comme 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 fichiers dont le nom comporte un espace ou un point à la fin

Vous ne pouvez pas accéder aux dossiers ou aux fichiers à partir du partage de fichiers Azure lorsqu’il est monté 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 des fichiers dans ces dossiers via le Portail Azure.

Cause

Les dossiers ou fichiers ont été chargés à partir d’un système qui encode les caractères à la fin du nom en 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 :

Au lieu 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 des comptes de stockage Azure

Les E/S de fichier sur le système de fichiers monté commencent à donner des erreurs « L’hôte est arrêté » ou « Autorisation refusée ». Les journaux dmesg Linux sur le client affichent 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é.

Cause

À des fins d’équilibrage de charge de capacité, les comptes de stockage sont parfois migrés en direct d’un cluster de stockage à un autre. La migration de compte déclenche Azure Files trafic à rediriger du cluster source vers le cluster de destination en mettant à jour les mappages DNS pour qu’ils pointent vers le cluster de destination. Cela bloque tout le trafic vers le cluster source à partir de ce compte. 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 du noyau SMB Linux, cette redirection ne prend pas effet. Par conséquent, le trafic de données continue d’atteindre le 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 le système d’exploitation client, mais vous risquez de le rencontrer à nouveau 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. Notez que l’umount et le remontage du partage peuvent sembler résoudre le problème temporairement.

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

  1. Affichez la status du module noyau dns_resolver en exécutant la commande suivante :

    grep '.dns_resolver' /proc/keys

    Vous devez voir une sortie de commande semblable à 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 le status du module du noyau dns_resolver :

    grep '.dns_resolver' /proc/keys

    Vous devez voir une sortie de commande semblable à l’exemple suivant, indiquant que le cache est maintenant vide :

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

Solution

Pour obtenir un correctif permanent, mettez à niveau votre système d’exploitation client vers une version de distribution Linux avec prise en charge de la migration de compte. Plusieurs correctifs pour le client du noyau SMB Linux ont été envoyés au noyau Linux principal. Le noyau version 5.15+ et Keyutils-1.6.2+ ont les correctifs. Certaines distributions ont rétroporté ces correctifs, et vous pouvez case activée 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 la norme FIPS (Federal Information Processing Standard) est activée 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

Importante

FIPS est un ensemble de normes que le gouvernement des États-Unis 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, 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.

Guide pratique pour case activée 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é.

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 dans /etc/sysctl.conf.

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

  3. Reconstruit 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 :

Besoin d’aide ?

Si vous avez toujours 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.