File Storage NAS:Dépannage des problèmes d'accès en lecture et écriture aux fichiers

Absence de réponse du serveur lors d'un accès concurrentiel aux fichiers

Cause : Un bogue dans le pilote noyau SMB de Linux provoque ce problème. Lorsque vous montez un système de fichiers à l'aide de SMB 2.1 ou 3,0, les clients peuvent ne pas envoyer les paquets SMB BreakAck attendus dans certains scénarios d'accès concurrentiel, ce qui entraîne une absence de réponse du serveur pendant 35 secondes.

Solution 1 : Montez le système de fichiers en utilisant SMB 2.0.

Solution 2 : Suivez ces étapes.

1. Exécutez la commande suivante pour désactiver les verrous d'opportunité (oplocks) lors du chargement du module CIFS :

   # modprobe cifs enable_oplocks=0

2. Exécutez la commande suivante pour désactiver les verrous d'opportunité après le chargement du module CIFS :

   # echo 0 > /sys/module/cifs/parameters/enable_oplocks

3. Exécutez la commande suivante pour vérifier l'état des verrous d'opportunité :

   # cat /sys/module/cifs/parameters/enable_oplocks

   Dans la sortie, Y indique que l'option est activée et N qu'elle est désactivée.

   Remarque

   • Pour appliquer les modifications, démontez puis remontez le système de fichiers SMB.

   • Pour rendre les modifications permanentes, créez le fichier /etc/modprobe.d/cifs.conf et ajoutez la ligne options cifs enable_oplocks=0.

Impossible de créer des liens symboliques

Cause

Le système de fichiers SMB a été monté sur Linux sans l'option mfsymlinks ou en utilisant la version de protocole 2,0.

Solution

Lorsque vous montez un système de fichiers SMB sur Linux, utilisez la version de protocole 2,1 ou 3,0 et ajoutez l'option mfsymlinks. Voici un exemple de commande de montage. Pour obtenir des descriptions des paramètres de l'exemple, consultez Descriptions des paramètres de la commande de montage SMB (Linux).

sudo mount -t cifs //file-system-id.region.nas.aliyuncs.com/myshare /mnt -o vers=2.1,guest,uid=0,gid=0,dir_mode=0755,file_mode=0755,mfsymlinks,cache=strict,rsize=1048576,wsize=1048576

Point de montage SMB ne répondant plus

Cause

Sur les distributions Linux dotées d'un noyau antérieur à la version 3.10.0-514, le pilote noyau SMB peut planter dans des scénarios d'accès concurrentiel, rendant le point de montage inaccessible. Le journal du noyau contient des messages similaires aux suivants :

...
[<ffffffffc03c9bc1>] cifs_oplock_break+0x1f1/0x270 [cifs]
[<ffffffff810a881a>] process_one_work+0x17a/0x440
[<ffffffff810a8d74>] rescuer_thread+0x294/0x3c0
...

Solution

• Remontez le système de fichiers avec l'option cache=none. Cela peut affecter les performances.

• Mettez à niveau le système d'exploitation de l'instance ECS exécutant Linux.

Erreur « Bad file descriptor » lors de la copie de fichiers volumineux

Cause

Ce problème survient en raison d'une défaillance temporaire du réseau ou du backend. Les clients SMB sur certaines distributions Linux, telles que SUSE, offrent un support limité pour ce type de basculement.

Solution

Le tableau suivant répertorie les versions recommandées des systèmes d'exploitation Linux pour NAS SMB.

Caractères chinois illisibles sur les clients

Symptôme

Lorsque vous écrivez des caractères chinois (par exemple, dans les noms de fichiers ou le contenu des fichiers) depuis un client Linux vers un système de fichiers NAS, ils peuvent apparaître illisibles sur un client Windows, et vice versa.

Cause

Par défaut, les clients Windows utilisent le jeu de caractères GBK pour l'encodage et le décodage des caractères chinois, tandis que les clients Linux utilisent le jeu de caractères UTF-8. Chaque plateforme encode les données en utilisant son propre jeu de caractères. Lorsque les données écrites par une plateforme sont lues par l'autre, l'incompatibilité des jeux de caractères provoque un échec du décodage et le contenu apparaît illisible.

Solution

Pour éviter les problèmes d'incompatibilité entre plateformes, nous vous recommandons de monter les systèmes de fichiers NAS via SMB sur les clients Windows et via NFS sur les clients Linux.

Opérations sur les fichiers lentes sous Windows avec NFS

Cause

Sous Windows, NFS présente des problèmes de compatibilité entre les sémantiques sensibles et insensibles à la casse. Les performances de création de fichiers dans un répertoire se dégradent considérablement à mesure que la taille du répertoire augmente. Cela se produit car le répertoire doit être parcouru à chaque création de fichier. Lorsque le répertoire contient environ 100 000 entrées, un seul parcours du répertoire peut prendre plus de 10 secondes.

Solution

Modifiez les paramètres de montage en ajoutant l'option -o casesensitive=yes pour éviter le parcours du répertoire. La commande suivante fournit un exemple :

mount -o nolock -o mtype=hard -o timeout=60 -o casesensitive=yes \\file-system-id.region.nas.aliyuncs.com\! Z:

Remplacez la lettre de lecteur Z: et l'adresse du point de montage file-system-id.region.nas.aliyuncs.com en fonction de votre environnement.

Comment résoudre l'erreur invalid device lors du renommage d'un fichier sur un système de fichiers NFS depuis un client Windows ?

Le renommage d'un fichier renvoie l'erreur invalid device si vous avez monté un sous-répertoire du système de fichiers NFS. Pour résoudre ce problème, montez le répertoire racine du système de fichiers. Pour plus d'informations, consultez Étape 2 : Monter un système de fichiers NAS général utilisant NFS.

Latence de création de fichiers dans NFS

• Symptôme :

  ECS-1 a créé le fichier abc, mais il y a un délai avant qu'ECS-2 ne puisse voir le fichier abc. Le délai est parfois d'une seconde et peut atteindre jusqu'à une minute. Pourquoi cela se produit-il ?

• Cause :

  Cela est dû au cache de recherche (Lookup Cache) et constitue un comportement attendu pendant une période T. Par exemple, ECS-2 accède au chemin du fichier avant qu'ECS-1 ne crée le fichier abc. Cela amène ECS-2 à recevoir une réponse « fichier introuvable », et un enregistrement est alors mis en cache indiquant que le fichier abc n'existe pas. Pendant la période T, comme FileAttr n'a pas encore expiré, lorsque ECS-2 accède à nouveau au chemin du fichier, il récupère toujours l'enregistrement mis en cache indiquant que le fichier abc n'existe pas.

• Solution :

  Pour garantir qu'ECS-2 puisse voir le fichier immédiatement après sa création par ECS-1, utilisez l'une des solutions suivantes :

  • Solution 1 : Désactivez le cache de recherche négatif sur ECS-2 pour empêcher la mise en cache des fichiers inexistants. Cette solution présente la surcharge la plus faible.

    Lors du montage du système de fichiers, ajoutez l'option lookupcache=positive. La valeur par défaut est lookupcache=all. La commande suivante fournit un exemple :

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,lookupcache=positive file-system-id.region.nas.aliyuncs.com:/ /mnt

  • Solution 2 : Désactivez tous les caches sur ECS-2. Cette solution peut sévèrement dégrader les performances. Choisissez cette solution uniquement si votre charge de travail l'exige.

    Lors du montage du système de fichiers, ajoutez l'option actimeo=0. La commande suivante fournit un exemple :

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

Latence d'écriture des données dans NFS

• Symptôme :

  ECS-1 met à jour un fichier nommé abc. Cependant, lorsque ECS-2 lit immédiatement le fichier, il lit toujours l'ancien contenu. Pourquoi cela se produit-il ?

• Cause :

  Ce problème a les deux causes suivantes :

  • Après qu'ECS-1 a écrit des données dans le fichier abc, les données ne sont pas immédiatement vidées vers le serveur. Au lieu de cela, le client met d'abord les données en cache dans son cache de pages. Les données ne sont vidées que lorsque l'application appelle fsync ou close.

  • ECS-2 dispose d'un cache de fichiers et peut ne pas récupérer immédiatement le dernier contenu du serveur. Par exemple, si ECS-2 a mis en cache les données lorsque ECS-1 a mis à jour le fichier abc, ECS-2 utilise toujours le contenu mis en cache lorsqu'il relit le fichier.

• Solution :

  Pour garantir qu'ECS-2 puisse lire immédiatement les dernières données après qu'ECS-1 a mis à jour un fichier, utilisez l'une des solutions suivantes :

  • Solution 1 : Utilisez la cohérence close-to-open (CTO). Pour assurer la cohérence CTO, après qu'ECS-1 a mis à jour le fichier, il doit appeler close ou fsync. Avant qu'ECS-2 ne lise le fichier, il doit rouvrir le fichier puis le lire.

  • Solution 2 : Désactivez tous les caches sur ECS-1 et ECS-2. Cette solution peut sévèrement dégrader les performances. Choisissez cette solution uniquement si votre charge de travail l'exige.

    • Désactivez le cache sur ECS-1. Lors du montage du système de fichiers, ajoutez l'option noac pour garantir que toutes les données écrites sont immédiatement persistées. La commande suivante fournit un exemple :

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,noac file-system-id.region.nas.aliyuncs.com:/ /mnt

      Remarque

      • Si l'appel fsync est effectué après la fin de l'opération d'écriture sur ECS-1, ou si vous utilisez des écritures synchrones, vous pouvez remplacer noac par actimeo=0 pour de meilleures performances.

      • L'option noac équivaut à spécifier actimeo=0 et à forcer toutes les écritures à être synchrones.

    • Désactivez le cache sur ECS-2. Lors du montage du système de fichiers, ajoutez l'option actimeo=0 pour ignorer tous les caches. La commande suivante fournit un exemple :

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

Propriétaires de fichiers différents sur différentes instances ECS

Dans un système de fichiers, l'identité de l'utilisateur est identifiée par un UID ou un GID, et non par un nom d'utilisateur. Le nom d'utilisateur affiché comme propriétaire sur une instance ECS est dérivé de cet UID.

Par exemple, sur l'instance ECS 1, l'utilisateur admin crée un fichier nommé admin_on_machine1. Sur l'instance ECS 2, l'utilisateur admin crée un fichier nommé admin_on_machine2.

Lorsque vous exécutez la commande ll sur l'instance ECS 1 pour afficher les fichiers, la sortie est la suivante :

$ ll
total 0
-rw-rw-r-- 1 admin    admin 0 Apr  6 17:10 admin_on_machine1
-rw-rw-r-- 1 terminal 19062 0 Apr  6 17:12 admin_on_machine2

Lorsque vous exécutez la commande ll sur l'instance ECS 2, la sortie est la suivante :

$ ll
total 0
-rw-rw-r-- 1    505    505 0 Apr  6 17:10 admin_on_machine1
-rw-rw-r-- 1 admin  admin 0 Apr  6 17:12 admin_on_machine2

Les résultats de requête des deux instances ECS montrent que le même fichier possède des noms d'utilisateur propriétaires différents.

Ensuite, exécutez la commande id sur chaque instance pour interroger les informations de l'utilisateur admin.

Sur l'instance ECS 1, l'UID de l'utilisateur admin est 505, comme indiqué dans la sortie suivante :

$ id
uid=505(admin) gid=505(admin) groups=505(admin)

Sur l'instance ECS 2, l'UID de l'utilisateur admin est 2915, comme indiqué dans la sortie suivante :

$ id
uid=2915(admin) gid=19062(admin) groups=19062(admin)

Exécutez la commande stat admin_on_machine1 admin_on_machine2 pour vérifier les détails des deux fichiers. La sortie montre que admin_on_machine1 a un UID de 505/UNKNOWN et un GID de 505/UNKNOWN, tandis que admin_on_machine2 a un UID de 2915/admin et un GID de 19062/admin. Cela confirme que l'utilisateur admin possède des UID et GID différents sur les deux instances ECS.

$ stat admin_on_machine1 admin_on_machine2
  File: 'admin_on_machine1'
  Size: 0          Blocks: 0          IO Block: 1048576 regular empty file
Device: 25h/37d Inode: 6447105    links: 1
Access: (0664/-rw-rw-r--)  Uid: (  505/ UNKNOWN)   Gid: (  505/ UNKNOWN)
Access: 2021-04-06 17:10:56.423782205 +0800
Modify: 2021-04-06 17:10:56.423782290 +0800
Change: 2021-04-06 17:10:56.423874225 +0800
 Birth: -
  File: 'admin_on_machine2'
  Size: 0          Blocks: 0          IO Block: 1048576 regular empty file
Device: 25h/37d Inode: 6447106    links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 2915/   admin)   Gid: (19062/   admin)
Access: 2021-04-06 17:12:42.267027897 +0800
Modify: 2021-04-06 17:12:42.267027984 +0800
Change: 2021-04-06 17:12:42.267106855 +0800
 Birth: -

Exceptions dues aux écritures concurrentes dans les fichiers journaux

Symptôme

Apsara File Storage NAS fournit un accès partagé aux fichiers avec un namespace unifié pour plusieurs clients. Cependant, lorsque plusieurs processus ou clients écrivent simultanément dans le même fichier, par exemple un fichier journal, chaque processus maintient son propre descripteur de fichier et son contexte de décalage d'écriture. Le protocole NFS manque de sémantique d'ajout atomique, ce qui peut entraîner des problèmes de corruption des données tels que des écrasements et des entrelacements.

Solution

• (Recommandé) Faites en sorte que différents processus ou clients écrivent dans des fichiers distincts au sein du même système de fichiers, puis fusionnez les fichiers pour une analyse ultérieure. Cette approche évite les problèmes de concurrence et ne nécessite pas de verrous de fichiers, donc elle n'affecte pas les performances.

• Pour les scénarios impliquant des ajouts concurrents au même fichier, tel qu'un fichier journal, vous pouvez utiliser un verrou de fichier et le mécanisme seek pour garantir l'atomicité et la cohérence des écritures. Cependant, cette méthode peut dégrader considérablement les performances. La section suivante fournit un bref aperçu à titre de référence.

Utilisation de flock et seek

Étant donné que le protocole NFS ne fournit pas de sémantique d'ajout atomique, les écritures concurrentes à la fin du même fichier, tel qu'un fichier journal, peuvent facilement s'écraser mutuellement. Sous Linux, vous pouvez utiliser les mécanismes flock et seek pour simuler des ajouts atomiques sur un système de fichiers NFS et protéger les écritures d'ajout concurrentes.

Suivez ces étapes :

1. Appelez fd=open(filename, O_WRONLY | O_APPEND | O_DIRECT) pour ouvrir le fichier en mode ajout et spécifiez O_DIRECT pour contourner le cache de pages. Cela renvoie le descripteur de fichier fd.

2. Appelez flock(fd, LOCK_EX|LOCK_NB) pour essayer d'acquérir un verrou de fichier. Si l'appel échoue (par exemple, parce que le verrou est déjà détenu), il renvoie une erreur. Vous pouvez alors réessayer ou gérer l'erreur.

3. Après avoir acquis le verrou, appelez lseek(fd, 0, SEEK_END) pour déplacer le décalage d'écriture actuel de fd vers la fin du fichier.

4. Effectuez une opération d'écriture normale. Les données sont écrites à la fin du fichier et le verrou de fichier empêche les écritures concurrentes de s'écraser mutuellement.

5. Une fois l'opération d'écriture terminée, appelez flock(fd, LOCK_UN) pour libérer le verrou de fichier.

Pourquoi la commande ls renvoie-t-elle une erreur 523 lorsqu'elle est exécutée sur un système de fichiers NFS dans un système d'exploitation Linux ?

Symptôme

Lorsque vous exécutez la commande ls dans un système de fichiers NFS depuis un client Linux, le message d'erreur suivant est renvoyé.

ls: reading directory '.': Unknown error 523

Cause

Si vous exécutez la commande ls sur un répertoire de système de fichiers pendant que des opérations rename concurrentes sont effectuées dessus, une erreur 523 est renvoyée.

Solution

Attendez un instant et réessayez l'opération. Si l'erreur persiste, soumettez un ticket.

Échecs de montage du système de fichiers SMB

Symptôme

Si vous utilisez à la fois des systèmes de fichiers NFS et SMB et que vous ne parvenez pas à monter un système de fichiers NFS à l'aide de la commande net use, vous pouvez également rencontrer des problèmes lorsque vous essayez de monter le système de fichiers SMB correct.

Solution

Vérifiez que vous montez le bon système de fichiers, arrêtez temporairement l'opération de montage et réessayez après 5 minutes. Si l'opération échoue toujours, soumettez un ticket.

Répertoire monté visible uniquement par Administrator

Ce problème est dû au mécanisme d'isolation des utilisateurs dans Windows. Un répertoire monté par un utilisateur n'est pas visible dans la session d'un autre utilisateur.

Pour activer le partage entre plusieurs utilisateurs, créez un lien de répertoire. Par exemple, exécutez la commande suivante pour créer un répertoire nommé myshare sur le lecteur C :

mklink /D C:\myshare \\xxxxxxx-xxxx.cn-beijing.nas.aliyuncs.com\myshare\

Mauvaises performances de SMB sur les clients Linux

Si un système de fichiers SMB présente de mauvaises performances, vous pouvez résoudre le problème en vous basant sur les causes potentielles suivantes.

• Cause 1 : Le débit maximal d'un système de fichiers SMB évolue linéairement avec sa capacité de stockage.

  Solution : Utilisez l'outil fio pour tester les performances du système de fichiers SMB. Pour plus d'informations, consultez Tester les performances d'un système de fichiers NAS.

• Cause 2 : La bande passante réseau d'une seule instance ECS exécutant Linux est faible.

  Solution : Utilisez plusieurs instances ECS exécutant Linux pour atteindre les performances globales souhaitées du système de fichiers.

• Cause 3 : La mise en cache côté client pour le système de fichiers SMB est désactivée.

  Solution : Lors du montage d'un système de fichiers SMB, cache=none indique que la mise en cache est désactivée. L'option par défaut ou cache=strict indique que la mise en cache est activée. Vous pouvez exécuter la commande sudo mount | grep cifs pour vérifier si l'option correcte est utilisée.

• Cause 4 : La taille des E/S pour le client SMB n'est pas correctement définie.

  Solution : Ajustez les valeurs rsize et wsize en fonction de vos besoins métier. La valeur par défaut est 1048576.

• Cause 5 : Les spécifications CPU ou mémoire de l'instance ECS exécutant Linux sont trop faibles, ou trop de ressources sont occupées par d'autres services.

  Solution : Sélectionnez des spécifications appropriées pour l'instance ECS exécutant Linux et vérifiez les ressources utilisées par d'autres applications sur le système pour vous assurer que les exigences en matière de CPU et de mémoire sont satisfaites. Vous pouvez exécuter la commande top pour vérifier l'utilisation du CPU et de la mémoire.

• Cause 6 : L'option atime est utilisée pour le montage.

  Solution : Si votre activité n'est pas très sensible aux temps d'accès aux fichiers (atime), n'utilisez pas l'option atime lors du montage du système de fichiers.

• Cause 7 : Le scénario de serveur web implique des lectures fréquentes d'un grand nombre de petits fichiers, des écritures peu fréquentes et des notifications d'écriture.

  Solution : Vous pouvez configurer un mécanisme de mise en cache spécifique pour le serveur web, tel qu'Apache, sur le client, ou contacter l'équipe Alibaba Cloud NAS pour activer l'accélération pour les scénarios de serveur web.

Comment résoudre l'erreur Permission denied lors de l'accès à un système de fichiers SMB depuis Linux ?

Cause : Cette erreur peut se produire si des valeurs incorrectes pour UID, GID, file_mode ou dir_mode sont utilisées dans la commande de montage.

Solution : Vérifiez si les options de montage telles que UID, GID, file_mode et dir_mode sont correctement définies. Pour plus d'informations, consultez Monter un système de fichiers SMB.

Modification de la casse des noms de fichiers dans SMB

Les systèmes de fichiers SMB sont insensibles à la casse, ce qui est cohérent avec les systèmes Windows. Cependant, vous ne pouvez pas renommer un fichier en modifiant uniquement sa casse.

Comme solution de contournement, vous pouvez d'abord renommer le fichier avec un nom différent, puis le renommer avec le nom souhaité en respectant la casse correcte.

Impossible de modifier le propriétaire et le mode des fichiers

Vous ne pouvez pas modifier dynamiquement le propriétaire ou le mode des fichiers et des répertoires. Ces attributs ne peuvent être spécifiés que lors du montage du système de fichiers. Pour plus d'informations, consultez Monter un système de fichiers SMB.

Qu'est-ce qui génère les fichiers avec l'extension .nfs ? Comment peuvent-ils être supprimés ?

Lorsque vous supprimez un fichier ouvert dans une application, le système crée un fichier temporaire avec le suffixe .nfs. Le système supprime automatiquement ce fichier lorsque le processus de l'application se ferme.

Comment résoudre l'erreur bind conn to session failed on NFSv4 server lors de l'accès à des fichiers dans un répertoire de système de fichiers NAS ?

• Cause

  Cette erreur se produit car Apsara File Storage NAS ne prend pas en charge NFSv4.1. Le système signale cette erreur si vous essayez de monter un système de fichiers en utilisant NFSv4.1.

• Solution

  Remontez le système de fichiers en utilisant NFSv3 ou NFSv4.0 en fonction de votre scénario métier. Pour plus d'informations, consultez Notes d'utilisation pour le montage d'un système de fichiers.

Problèmes de synchronisation des données avec NFS

Symptôme

Lorsque plusieurs clients montent le même système de fichiers NAS, les modifications de données effectuées sur un client peuvent ne pas être immédiatement visibles sur les autres clients.

Cause

Par défaut, le noyau du système d'exploitation conserve les attributs des fichiers et des répertoires et crée un cache de métadonnées pour réduire le besoin d'appels de procédure distante NFSPROC_GETATTR.

Solution

Exécutez la commande de montage suivante pour désactiver la mise en cache des attributs de fichiers et de répertoires.

mount -t nfs4 -o noac file-system-id.region.nas.aliyuncs.com:/ /mnt

Remplacez file-system-id.region.nas.aliyuncs.com par l'adresse du point de montage du système de fichiers et /mnt par le chemin local sur votre serveur où vous souhaitez monter le système de fichiers.

Écriture du conteneur dans l'ancien NAS après remontage

Cause

Si vous montez un système de fichiers NAS sur une instance ECS, puis mappez le répertoire de montage à un conteneur en utilisant un volume local (HostPath), les informations de montage du conteneur deviennent indépendantes de l'instance ECS hôte. Par conséquent, si vous démontez le répertoire NAS d'origine sur l'hôte ou en montez un nouveau, le conteneur en cours d'exécution continue d'utiliser l'ancien système de fichiers NAS.

Solution

Après avoir monté le nouveau système de fichiers NAS sur l'instance ECS, redémarrez le Pod du conteneur.

Fichiers non visibles après le redémarrage du serveur

Si le système de fichiers existe toujours, ce problème se produit généralement parce que le serveur n'est pas configuré pour monter automatiquement le système de fichiers NAS au redémarrage.

Pour monter manuellement à nouveau le système de fichiers NAS, consultez Notes d'utilisation pour le montage d'un système de fichiers.

Pour configurer le montage automatique du système de fichiers NAS après un redémarrage, consultez les rubriques suivantes :

• Monter automatiquement un système de fichiers NFS sur un système Linux

• Monter automatiquement un système de fichiers SMB sur un système Windows

Migration et copie de fichiers lentes avec SMB sur Linux

Si vous avez exclu les problèmes de performances du système de fichiers, la lenteur peut être due à un manque de concurrence dans votre processus de migration ou de copie. Vous pouvez utiliser les outils open source suivants pour la migration ou la copie parallèle.

• GNU Parallel

  Sélectionnez un nombre approprié de threads en fonction des ressources système. Exemple : find * -type f | parallel --will-cite -j 10 cp {} /mnt/smb/ &

• Fpart

• Fpsync

• multi

Erreur « Disk quota exceeded »

• Cause

  L'utilisation ou le nombre de fichiers du répertoire cible a dépassé la limite de quota utilisateur configurée. Par conséquent, les opérations d'écriture (y compris l'augmentation de la longueur du fichier, la création de fichiers, de répertoires et le déplacement de fichiers vers des répertoires) échouent et un message d'erreur similaire à Disk quota exceeded est renvoyé.

• Solution

  1. Nous vous recommandons de nettoyer les données pour libérer de l'espace ou d'augmenter la limite de capacité du répertoire dès que possible. Pour plus d'informations, consultez Modifier un quota utilisateur unique.

  2. Une fois le nettoyage terminé, nous vous recommandons d'effectuer d'abord des opérations d'écriture de test sur le répertoire avec quota (par exemple, créer et écrire des données dans un fichier de test) pour déclencher l'actualisation asynchrone du cache de quota. Vérifiez que ces opérations d'écriture de test réussissent avant de redémarrer votre activité.

Erreur « Permission denied » lors de l'accès à NFS

Vous pouvez suivre ces étapes pour configurer AnonymousGid et AnonymousUid pour votre système.

1. Connectez-vous à l'instance ECS sur laquelle le système de fichiers est monté.

2. Ouvrez l'invite de commandes et exécutez la commande regedit pour ouvrir l'Éditeur du Registre.

3. Accédez à .

4. Cliquez avec le bouton droit dans une zone vide, sélectionnez , et créez les deux entrées de registre suivantes.

   • AnonymousGid, avec une valeur de 0.

   • AnonymousUid, avec une valeur de 0.

     Dans l'Éditeur du Registre, vérifiez que le chemin HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default contient désormais à la fois AnonymousGid et AnonymousUid, chacun défini sur 0.

5. Redémarrez l'instance ECS.

6. Remontez le système de fichiers NAS général utilisant NFS.

   mount -o nolock -o mtype=hard -o timeout=60 \\file-system-id.region.nas.aliyuncs.com\! Z:

   Remplacez la lettre de lecteur Z: et le nom de domaine du point de montage file-system-id.region.nas.aliyuncs.com par vos valeurs réelles.

7. Exécutez la commande mount pour vérifier si le système de fichiers est monté avec succès.

   Une fois le montage terminé, la sortie doit inclure mount=hard, locking=no et une valeur de timeout supérieure ou égale à 10. Sinon, le montage a échoué. Voici un exemple de sortie attendue :

   C:\Users\Administrator>mount
   Local    Remote                              Properties
   Z:       \\29xxx.nas~          UID=-2, GID=-2
                             rsize=1048576, vsize=1048576
                             mount=hard, timeout=10.0
                             retry=1, locking=no
                             fileaccess=755, lang=GB2312-80
                             casesensitive=no
                             sec=sys

Modification des permissions du répertoire racine avec chown

Vous ne pouvez pas modifier les permissions d'un répertoire racine NAS.

Pour contrôler les permissions sur un répertoire NAS monté localement, vous pouvez monter un sous-répertoire. Par exemple, si vous montez le répertoire racine NAS sur /data, vous ne pouvez pas utiliser chown pour changer le propriétaire et le groupe du répertoire /data. Si vous montez un sous-répertoire NAS, qui doit être créé au préalable, sur le répertoire local /data, vous pouvez utiliser chown pour changer le propriétaire et le groupe du répertoire /data. Notez que pour créer un sous-répertoire dans NAS, vous devez d'abord monter le répertoire racine NAS, puis créer le sous-répertoire. Pour savoir comment créer et monter un sous-répertoire, consultez Comment créer et monter un sous-répertoire NAS sur un système Linux ?.