Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Dépannage des fichiers S3

Cette page vous aide à diagnostiquer et à résoudre les problèmes courants liés aux fichiers S3.

La commande de montage échoue

La mount -t s3files commande échoue avec une erreur.

Causes et actions courantes :

Autorisation refusée pour les opérations sur les fichiers

Vous pouvez monter le système de fichiers mais recevoir des erreurs « Autorisation refusée » ou « Opération non autorisée » lors de la lecture, de l'écriture ou de l'accès à des fichiers.

Causes et actions courantes :

Le routage de lecture intelligent ne fonctionne pas

S3 Files effectue un routage de lecture intelligent en acheminant automatiquement les demandes de lecture vers la couche de stockage qui leur convient le mieux, tout en conservant la sémantique complète du système de fichiers, notamment la cohérence, le verrouillage et les autorisations POSIX. De petites lectures aléatoires de fichiers activement utilisés sont diffusées à partir du stockage haute performance pour une faible latence. Les lectures séquentielles volumineuses et les lectures de données ne figurant pas dans le système de fichiers sont effectuées directement depuis votre compartiment S3 pour un débit élevé, sans frais de données du système de fichiers.

Le routage de lecture intelligent peut ne pas fonctionner si l'une des mesures de connectivité du client (NFSConnectionAccessibleS3BucketAccessible, etS3BucketReachable) affiche 0, ou si vous n'obtenez pas le débit de lecture attendu.

Causes et actions courantes :

Le système de fichiers renvoie systématiquement une erreur de serveur NFS

Un système de fichiers chiffré renvoie systématiquement des erreurs de serveur NFS. Ces erreurs peuvent se produire lorsque S3 Files ne peut pas récupérer votre clé AWS KMS depuis KMS pour l'une des raisons suivantes :

Action à exécuter

Tout d'abord, vérifiez que la clé AWS KMS est activée. Vous pouvez consulter vos clés dans la console AWS KMS. Pour plus d’informations, consultez Affichage des clés dans le Guide du développeur AWS Key Management Service.

Si la clé n’est pas activée, activez-la. Pour plus d’informations, consultez Activation et désactivation de clés dans le Guide du développeur AWS  Key Management Service.

Si la clé est en attente de suppression, annulez-la et réactivez-la. Pour plus d'informations, consultez la section Planification et annulation de la suppression des clés dans le Guide du développeur du service de gestion des AWS clés.

Si la clé est activée et que vous rencontrez toujours des problèmes, contactez le AWS support.

Objet manquant dans le compartiment S3 après l'écriture du système de fichiers

Vous avez écrit un fichier via le système de fichiers et vous vous attendiez à ce qu'il apparaisse en tant qu'objet dans votre compartiment S3, mais l'objet n'y figure pas. S3 Files attend une période d'inactivité d'écriture (60 secondes) avant d'exporter les modifications vers votre compartiment S3. Si l'objet n'apparaît toujours pas après cette période, l'exportation a peut-être échoué. Dans ce cas, vous constatez une augmentation de la FailedExports CloudWatch métrique.

Action à exécuter

Vérifiez l'état d'exportation du fichier à l'aide d'attributs étendus :

getfattr -n "user.s3files.status;$(date -u +%s)" missing-file.txt --only-values

L'horodatage figurant dans le nom de l'attribut vous permet d'obtenir le statut le plus récent. Exemple de sortie :

S3Key: s3://bucket/prefix/missing-file.txt
ExportError: PathTooLong

ExportErrorne s'affiche pas s'il n'y a pas d'échec d'exportation. S3Keyest vide si aucun objet S3 n'a jamais été lié au fichier.

Le tableau suivant répertorie toutes les ExportError valeurs possibles :

S3 Files réessaie automatiquement les exportations ayant échoué. ExportErrors'affiche uniquement pour les erreurs qui ne peuvent pas être réessayées.

L'objet S3 n'est pas visible dans le système de fichiers

Un objet existe dans votre compartiment S3 mais n'apparaît pas dans le système de fichiers. Le nom de la clé de l'objet peut ne pas correspondre à un chemin de fichier POSIX valide. S3 Files ne prend pas en charge l'accès aux noms de clé S3 avec des composants de chemin vides (foo//bar), à des composants de chemin relatifs (foo/./bar,foo/../bar), aux noms de clé contenant des octets nuls ou aux noms de clé dont l'un des composants de chemin dépasse 255 octets. Les objets dont les noms de clé sont incompatibles ne sont pas importés dans le système de fichiers.

Fichiers figurant dans le répertoire des objets trouvés

Les fichiers sont apparus dans le .s3files-lost+found-file-system-id répertoire du répertoire racine de votre système de fichiers. Dans ce cas, vous constatez une augmentation de la LostAndFoundFiles CloudWatch métrique. Cela se produit lorsqu'un conflit de synchronisation survient. Un conflit se produit lorsque le même fichier est modifié via le système de fichiers et que l'objet S3 correspondant change avant que S3 Files ne synchronise les modifications du système de fichiers vers S3. S3 Files considère le compartiment S3 comme source de vérité, déplace le fichier en conflit vers le répertoire des objets trouvés et importe la dernière version du compartiment S3 dans le système de fichiers.

Identification des fichiers dans le répertoire des objets trouvés

Lorsque S3 Files déplace un fichier vers le répertoire des objets trouvés et perdus, le nom du fichier est précédé d'un identifiant hexadécimal pour distinguer les différentes versions du même fichier susceptibles d'être déplacées au fil du temps. Les noms de fichiers de plus de 100 caractères sont tronqués pour faire de la place pour cet identifiant. Le chemin du répertoire d'origine du fichier n'est pas conservé dans le répertoire des objets trouvés.

Action à exécuter

Obtenez le chemin d'origine du fichier et la clé d'objet S3 correspondante :

getfattr -n "user.s3files.status;$(date -u +%s)" .s3files-lost+found-fs-12345678/abcdef1234_report.csv --only-values

Exemple de sortie :

S3Key: s3://bucket/prefix/report.csv
FilePath: /data/report.csv

Vous pouvez ensuite soit conserver la dernière version de votre compartiment S3 et supprimer le fichier du répertoire des objets trouvés, soit copier le fichier du répertoire des objets trouvés vers son chemin d'origine pour remplacer la version S3.

La synchronisation prend du retard

La PendingExports CloudWatch métrique augmente, ce qui indique que votre charge de travail génère des modifications plus rapidement que S3 Files ne peut les synchroniser avec S3.

Cela signifie que votre charge de travail dépasse peut-être le taux de synchronisation. S3 Files exporte jusqu'à 800 fichiers par seconde et par système de fichiers. Envisagez de réduire le taux de modification des fichiers ou de répartir le travail sur plusieurs systèmes de fichiers. Surveillez la PendingExports métrique au fil du temps. S'il se stabilise ou diminue, S3 Files rattrape son retard. S'il continue de croître, contactez le AWS support.

Activation des journaux de débogage des clients

Si vous êtes en train de résoudre des problèmes de montage, de connectivité ou de contournement de lecture, vous pouvez activer la journalisation au niveau du débogage sur le client S3 Files pour obtenir plus de détails.

Logs d'assistance au montage et de surveillance

Modifiez /etc/amazon/efs/s3files-utils.conf et changez le niveau de journalisation de INFO à DEBUG :

[DEFAULT]
logging_level = DEBUG

Démontez et remontez le système de fichiers pour que la modification soit prise en compte :

sudo umount /mnt/s3files
sudo mount -t s3files file-system-id:/ /mnt/s3files

Les journaux sont écrits dans/var/log/amazon/efs/. Le journal d'assistance au montage estmount.log.

Journaux du proxy (efs-proxy)

Le proxy gère le trafic NFS et le contournement de lecture S3. Pour activer la journalisation du débogage pour le proxy, modifiez /etc/amazon/efs/s3files-utils.conf :

[proxy]
proxy_logging_level = DEBUG

Démontez et remontez pour que la modification prenne effet. Les journaux du proxy sont écrits dans/var/log/amazon/efs/.

Journaux du tunnel TLS (stunnel)

Les journaux du tunnel TLS sont désactivés par défaut. Pour les activer, modifiez /etc/amazon/efs/s3files-utils.conf et définissez les paramètres suivants :

[mount]
stunnel_debug_enabled = true

Pour enregistrer tous les journaux de tunnel d'un système de fichiers dans un seul fichier, supprimez également les commentaires de la stunnel_logs_file ligne :

stunnel_logs_file = /var/log/amazon/efs/{fs_id}.stunnel.log

Limites de taille des journaux

Les fichiers journaux font l'objet d'une rotation automatique. Vous pouvez configurer la taille maximale et le nombre de fichiers pivotés dans s3files-utils.conf :

[DEFAULT]
logging_max_bytes = 1048576
logging_file_count = 10

La valeur par défaut est de 1 Mo par fichier journal avec 10 fichiers pivotés, pour un maximum de 10 Mo par type de journal.

Partage de journaux avec AWS le support

Lorsque vous contactez le AWS support, collectez les journaux et la configuration du client dans une archive unique :

sudo tar -czf /tmp/s3files-support-logs.tar.gz \
  /var/log/amazon/efs/ \
  /etc/amazon/efs/s3files-utils.conf

/tmp/s3files-support-logs.tar.gzInclus dans votre étui de support.