Partager via

Résoudre des problèmes de partage de fichiers Azure NFS

  • Article

Note

CentOS référencé dans cet article est une distribution Linux et atteint la fin de vie (EOL). Faites le point sur votre utilisation et organisez-vous en conséquence. Pour plus d’informations, consultez les conseils sur la fin de vie centOS.

Cet article répertorie les problèmes courants liés aux partages de fichiers Azure NFS, puis indique des causes et des solutions de contournement potentielles.

Important

Le contenu de cet article s’applique uniquement aux partages NFS. Si vous souhaitez résoudre des problèmes SMB dans Linux, veuillez consulter la rubrique Résoudre les problèmes liés à Azure Files dans Linux (SMB). Les partages de fichiers Azure NFS ne sont pas pris en charge pour Windows.

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

chgrp "filename" failed: Invalid argument (22)

Cause 1 : idmapping n’est pas désactivé

Azure Files interdit l’UID/le GID alphanumérique. Par conséquent, vous devez désactiver idmapping.

Cause 2 : idmapping a été désactivé, mais a été réactivé après avoir rencontré un nom de fichier/répertoire incorrect

Même si vous désactivez correctement idmapping, il peut être automatiquement réactivé dans certains cas. Par exemple, si le service Azure Files rencontre un nom de fichier incorrect, il renvoie une erreur. À l’affichage de ce code d’erreur, un client Linux NFS 4.1 décide de réactiver idmapping, puis envoie les demandes ultérieures avec un UID/GID alphanumérique. Pour obtenir la liste des caractères non pris en charge sur Azure Files, consultez cet article. Le signe deux-points est l’un des caractères non pris en charge.

Solution de contournement

Vérifiez que vous avez désactivé idmapping et que rien ne le réactive. Puis, procédez comme suit :

  1. Démontez le partage.

  2. Désactivez l’idmapping avec :

    sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping

  3. Montez le partage.

  4. Si vous exécutez rsync, exécutez rsync avec l’argument —numeric-ids à partir d’un répertoire qui n’a pas de répertoire ou de nom de fichier incorrect.

Incapacité à créer un partage NFS

Cause : Paramètres de compte de stockage non pris en charge

NFS est disponible uniquement sur les comptes de stockage avec la configuration suivante :

Solution

Veuillez suivre les instructions dans Comment créer un partage NFS.

Nous n’avons pas pu nous connecter à un partage de fichiers Azure NFS, ni monter ce partage de fichiers

Cause 1 : La demande provient d’un client avec une adresse IP non approuvée ou dans un réseau non approuvé

Contrairement à SMB, NFS ne comporte pas d’authentification basée sur l’utilisateur. L’authentification d’un partage est basée sur la configuration de vos règles de sécurité réseau. Pour veiller à ce que les clients établissent uniquement des connexions sécurisées sont établies avec votre partage NFS, vous devez utiliser le point de terminaison de service ou des points de terminaison privés. Pour accéder aux partages en local en plus des points de terminaison privés, vous devez configurer une connexion VPN ou ExpressRoute. Les adresses IP ajoutées à la liste verte du compte de stockage pour le pare-feu sont ignorées. Vous devez utiliser l’une des méthodes suivantes pour configurer l’accès à un partage NFS :

  • Point de terminaison de service

    • Accessible par le point de terminaison public.

    • Disponible uniquement dans la même région.

    • Vous ne pouvez pas utiliser le peering VNet pour l’accès aux partages.

    • Vous devez ajouter chaque réseau ou sous-réseau virtuel individuellement à la liste verte.

    • Pour l’accès local, vous pouvez utiliser des points de terminaison de service avec ExpressRoute, des VPN point à site et des VPN site à site. Nous vous recommandons d’utiliser un point de terminaison privé, car c’est plus sécurisé.

      Le diagramme suivant illustre la connectivité à l’aide de points de terminaison publics :

      Diagramme de connectivité des points de terminaison publics.

  • Point de terminaison privé

    • L’accès est plus sécurisé qu’avec le point de terminaison de service.

    • L’accès au partage NFS via un lien privé est disponible à l’intérieur et à l’extérieur de la région Azure du compte de stockage (inter-régions, sur site).

    • Le peering de réseaux virtuels avec des réseaux virtuels hébergés dans le point de terminaison privé permet aux clients d’accéder au partage NFS dans les réseaux virtuels appairés.

    • Vous pouvez utiliser des points de terminaison privés avec ExpressRoute, des VPN point à site et des VPN site à site.

      Diagramme de connectivité des points de terminaison privés.

Cause 2 : Le transfert sécurisé requis est activé

Les partages de fichiers Azure NFS ne prennent actuellement pas en charge le chiffrement double. Azure fournit une couche de chiffrement pour toutes les données en transit entre les centres de données Azure à l’aide de MACSec. Vous pouvez accéder aux partages NFS uniquement depuis des réseaux virtuels approuvés et via des tunnels VPN. Aucun chiffrement de la couche de transport supplémentaire n’est disponible sur les partages NFS.

Solution

Désactivez le transfert sécurisé requis dans le panneau de configuration de votre compte de stockage.

Capture d’écran montrant le panneau de configuration du compte de stockage, désactivant le transfert sécurisé requis.

Cause 3 : Le package nfs-utils, nfs-client ou nfs-common n’est pas installé

Avant d’exécuter la mount commande, installez le package nfs-utils, nfs-client ou nfs-common.

Pour vérifier si le package NFS est installé, exécutez :

Les mêmes commandes de cette section s’appliquent à CentOS et Oracle Linux.

sudo rpm -qa | grep nfs-utils

Solution

Si le package n’est pas installé, installez-le à l’aide de la commande spécifique à votre distribution.

Les mêmes commandes de cette section s’appliquent à CentOS et Oracle Linux.

Système d’exploitation version 7.X

sudo yum install nfs-utils

Version 8.X ou 9.X du système d’exploitation

sudo dnf install nfs-utils

Cause 4 : Pare-feu bloquant le port 2049

Le protocole NFS communique avec son serveur sur le port 2049. Vérifiez que ce port est ouvert au compte de stockage (serveur NFS).

Solution

Assurez-vous que le port 2049 est ouvert sur votre client en exécutant la commande suivante. Si le port n’est pas ouvert, ouvrez-le.

sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049

Cause 5 : Compte de stockage supprimé

Si vous ne parvenez pas à monter le partage de fichiers en raison d’une erreur : la connexion a expiré, le compte de stockage contenant le partage de fichiers peut être supprimé accidentellement.

Solution

Récupérez le compte de stockage. Ensuite, supprimez et recréez le point de terminaison privé afin qu’il soit associé au nouvel ID de ressource du compte de stockage.

ls suspend une énumération de répertoire de grande taille sur certains noyaux

Cause : un bogue a été introduit dans le noyau Linux v5.11 et a été corrigé dans la version 5.12.5

Certaines versions du noyau contiennent un bogue où les listes de répertoires entraînent une séquence de READDIR sans fin. Les petits répertoires dans lesquels toutes les entrées peuvent être expédiées en un seul appel ne présentent pas ce problème. Le bogue a été introduit dans le noyau Linux v 5.11 et a été corrigé dans v 5.12.5. Ainsi, toutes les versions intermédiaires contiennent le bogue. RHEL 8.4 comporte cette version du noyau.

Solution de contournement : passer à une version antérieure ou mettre à niveau le noyau

Le passage à une version antérieure ou la mise à niveau du noyau vers tout ce qui est en dehors du noyau affecté permet normalement de résoudre le problème.

Les commandes système échouent avec l’erreur « Fichier introuvable »

Cause

Les applications Linux 32 bits qui s’appuient sur des nombres inode peuvent ne pas fonctionner comme prévu avec Azure Files en raison de la mise en forme des nombres d’inodes 64 bits générés par le service NFS.

Solution

Pour résoudre ce problème, utilisez l’une des méthodes suivantes :

  • Compressez les nombres d’ode 64 bits en 32 bits à l’aide de l’option de démarrage du nfs.enable_ino64=0 noyau.

  • Définissez le paramètre de module en ajoutant options nfs enable_ino64=0 au fichier /etc/modprobe.d/nfs.conf et en redémarrant la machine virtuelle.

Vous pouvez également conserver cette option de démarrage du noyau dans le fichier grub.conf . Pour plus d’informations, consultez la documentation de votre distribution Linux.

Impossible de modifier la propriété des fichiers et des répertoires

Cause

Les autorisations sur les partages de fichiers NFS sont appliquées par le système d’exploitation client plutôt que par le service Azure Files. Si le paramètre Root Squash est activé sur un partage de fichiers NFS, l’utilisateur racine sur le système client est traité comme un utilisateur anonyme (non privilégié) à des fins de contrôle d’accès. Cela signifie que même si vous êtes connecté en tant que racine sur le système client, vous ne pouvez pas utiliser la chown commande pour modifier la propriété des fichiers et des répertoires que vous ne possédez pas.

Solution

Dans le Portail Azure, accédez au partage de fichiers et sélectionnez Propriétés. Remplacez le paramètre Root Squash par No Root Squash.

Sans squash racine activé, l’utilisateur racine sur le système client dispose des mêmes privilèges que l’utilisateur racine sur le système serveur. Vous pouvez maintenant utiliser chown pour modifier la propriété d’un fichier ou d’un répertoire dans le partage, quel que soit le propriétaire actuel. Après avoir apporté les modifications, vous pouvez réactiver Root Squash si nécessaire.

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.