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.
Résolution des problèmes liés aux 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 :
« mount.s3files : commande introuvable » — Le client S3 Files (amazon-efs-utils) n'est pas installé ou est inférieur à la version 3.0.0. Installez ou mettez à niveau le client. Pour de plus amples informations, veuillez consulter Prérequis pour les fichiers S3.
« Impossible de résoudre le nom DNS du système de fichiers » : il n'existe aucune cible de montage dans la zone de disponibilité où votre instance EC2 est exécutée. Créez une cible de montage dans cette zone de disponibilité ou lancez votre instance dans une zone de disponibilité dotée d'une cible de montage. Pour de plus amples informations, veuillez consulter Création de cibles de montage.
Le délai de connexion a expiré : la configuration du groupe de sécurité n'autorise pas le trafic NFS. Vérifiez que le groupe de sécurité de la cible de montage autorise le TCP entrant sur le port 2049 depuis le groupe de sécurité de votre instance, et que le groupe de sécurité de votre instance autorise le TCP sortant sur le port 2049 vers le groupe de sécurité de la cible de montage. Pour de plus amples informations, veuillez consulter Prérequis pour les fichiers S3.
« Accès refusé » pendant le montage : le rôle IAM associé à votre ressource de calcul ne dispose pas des autorisations requises pour les fichiers S3. Vérifiez que le rôle est associé à la politique
AmazonS3FilesClientFullAccessouAmazonS3FilesClientReadOnlyAccessà la politique gérée, ou au moins qu'il possède l's3files:ClientMountautorisation. Pour de plus amples informations, veuillez consulter Prérequis pour les fichiers S3.botocore non installé — L'assistant de montage nécessite botocore pour interagir avec les services. AWS Installez botocore en suivant les instructions du amazon-efs-utils fichier README sur. GitHub
Autorisation refusée pour les opérations sur les fichiers
Vous pouvez monter le système de fichiers mais recevoir des messages d'erreur « 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 :
Autorisation d'écriture manquante : si vous savez lire mais pas écrire, vérifiez que le rôle IAM associé à votre ressource de calcul inclut l'
s3files:ClientWriteautorisation, ou attachez laAmazonS3FilesClientReadWriteAccesspolitiqueAmazonS3FilesClientFullAccessgérée. Pour plus d'informations, consultez les politiques AWS gérées pour Amazon S3 Files.Accès root manquant : si vous recevez des erreurs d'autorisation lorsque vous accédez à des fichiers appartenant à root (UID 0), votre rôle IAM ne dispose peut-être pas de cette autorisation.
s3files:ClientRootAccessSans cette autorisation, toutes les opérations sont effectuées en tant qu'utilisateur anonyme NFS (généralement nfsnobody), qui n'a peut-être pas accès aux fichiers. Joignez la politiqueAmazonS3FilesClientFullAccessgérée ou ajoutez-las3files:ClientRootAccessà votre politique.Politique de système de fichiers refusant l'accès : si vous avez joint une politique de système de fichiers, vérifiez qu'elle ne refuse pas les actions dont vos clients ont besoin. Une « autorisation » dans la politique basée sur l'identité ou dans la politique du système de fichiers est suffisante pour l'accès. Pour de plus amples informations, veuillez consulter Fonctionnement de S3 Files avec IAM.
Incompatibilité des autorisations POSIX — S3 Files applique les autorisations POSIX standard (propriétaire, groupe, autres) sur les fichiers et les répertoires. Si votre application s'exécute en tant qu'utilisateur ne correspondant pas au propriétaire ou au groupe du fichier, l'accès peut être refusé même si les autorisations IAM sont correctes. Utilisez un point d'accès pour appliquer un code spécifique UID/GID à toutes les demandes. Pour de plus amples informations, veuillez consulter Création de points d'accès pour un système de fichiers S3.
Le routage de lecture intelligent ne fonctionne pas
S3 Files effectue un routage de lecture intelligent car il achemine 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 effectuées à partir du stockage haute performance pour une faible latence. Les lectures séquentielles importantes 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) indique 0 ou si le débit de lecture attendu n'est pas atteint.
Causes et actions courantes :
Politique en ligne S3 manquante sur le rôle de calcul — Le rôle IAM attaché à votre ressource de calcul doit inclure une politique en ligne octroyant
s3:GetObjectets3:GetObjectVersionsur le compartiment S3 lié. Sans cette politique, l'assistant de montage ne peut pas lire directement depuis S3 et toutes les lectures passent par le système de fichiers. Pour de plus amples informations, veuillez consulter Prérequis pour les fichiers S3.Le compartiment S3 n'est pas accessible — Vérifiez la
S3BucketReachablemétrique. S'il indique 0, vérifiez que votre ressource de calcul dispose d'un accès réseau à S3 (par exemple, via un point de terminaison VPC ou une passerelle NAT).Le fichier a été modifié — Les lectures ne sont effectuées directement depuis S3 que lorsque le fichier n'a pas été modifié par le biais du système de fichiers. Si vous avez écrit dans le fichier et que les modifications n'ont pas encore été synchronisées avec S3, les lectures passent par le système de fichiers jusqu'à ce que la synchronisation soit terminée.
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 parvient pas à récupérer votre clé AWS KMS auprès de KMS pour l'une des raisons suivantes :
La clé a été désactivée.
La clé a été supprimée.
L'autorisation pour S3 Files d'utiliser la clé a été révoquée.
AWS KMS est temporairement indisponible.
Action à exécuter
Vérifiez d'abord 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 suppression et réactivez-la. Pour plus d'informations, consultez la section Planification et annulation de la suppression de 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 sous forme d'objet dans votre compartiment S3, mais l'objet n'y figure pas. S3 Files traite les modifications par lots pendant environ 60 secondes avant de les copier dans S3. Si l'objet n'apparaît toujours pas, l'exportation a peut-être échoué. Dans ce cas, vous voyez la FailedExports CloudWatch métrique augmenter.
Action à exécuter
Vérifiez le statut d'exportation du fichier à l'aide d'attributs étendus :
getfattr -n "user.s3files.status;$(date -u +%s)" missing-file.txt --only-values
L'horodatage indiqué dans le nom de l'attribut vous garantit d'obtenir le dernier statut. 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 :
| Erreur | Cause |
|---|---|
S3AccessDenied |
Le rôle IAM assumé par S3 Files ne dispose pas des autorisations suffisantes pour écrire dans le compartiment S3. Pour de plus amples informations, veuillez consulter Prérequis pour les fichiers S3. |
S3BucketNotFound |
Le compartiment S3 source n'existe plus ou a été renommé. Vérifiez qu'il existe dans la AWS région et le compte attendus. |
InternalError |
Une erreur interne du système s'est produite. |
S3UserMetadataTooLarge |
La limite de taille des métadonnées utilisateur S3 a été dépassée. Voir Fonctionnalités, limites et quotas non pris en charge pour plus d'informations sur ces limites. |
FileSizeExceedsS3Limit |
La taille du fichier dépasse la limite de taille des objets S3. Voir Fonctionnalités, limites et quotas non pris en charge pour plus d'informations sur ces limites. |
EncryptionKeyInaccessible |
La clé de chiffrement utilisée par le compartiment S3 n'est pas accessible aux fichiers S3. Accordez à S3 Files l'accès à votre clé de chiffrement. Pour de plus amples informations, veuillez consulter Chiffrement. |
RoleAssumptionFailed |
Impossible d'assumer le rôle. Vérifiez vos politiques de confiance. Pour de plus amples informations, veuillez consulter Prérequis pour les fichiers S3. |
KeyTooLongToBreakCycle |
S3 Files n'a pas pu résoudre une dépendance circulaire (par exemple, en raison du changement du nom de deux fichiers) car le chemin du fichier dépasse la limite de longueur de la clé S3. Raccourcissez le chemin du répertoire pour résoudre cette erreur. |
PathTooLong |
Le chemin de votre fichier dépasse la limite de longueur de la clé S3. Voir Fonctionnalités, limites et quotas non pris en charge pour plus d'informations sur ces limites. |
DependencyExportFailed |
L'exportation d'un parent ou d'une dépendance ne peut pas être réessayée. Vérifiez le statut du parent ou de toute dépendance à l'aide degetfattr. |
S3ObjectArchived |
L'objet S3 est archivé (S3 Glacier Flexible Retrieval ou S3 Glacier Deep Archive) et ne peut pas être lu. Restaurez d'abord l'objet à l'aide du S3 APIs. |
S3 Files réessaie automatiquement les exportations qui ont échoué. ExportErrorest affiché uniquement pour les erreurs non réessayables.
Fichiers figurant dans le répertoire des objets trouvés
Des fichiers sont apparus dans le .s3files-lost+found- répertoire racine de votre système de fichiers. Dans ce cas, vous constatez une augmentation de la file-system-idLostAndFoundFiles 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 avec S3. S3 Files considère le compartiment S3 comme la 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, 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 laisser de la place à 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
| Champ | Description |
|---|---|
S3Key |
Chemin S3 complet de l'objet à l'origine du conflit, ou vide si l'objet a été supprimé dans le compartiment S3. |
FilePath |
Chemin relatif du fichier avant le conflit. |
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.
Note
Les fichiers du répertoire des objets trouvés y restent indéfiniment et sont pris en compte dans les coûts de stockage de votre système de fichiers. Supprimez les fichiers du répertoire des objets trouvés lorsqu'ils ne sont plus nécessaires.
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 entre 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 du client
Si vous résolvez 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.
Montez des bûches pour les aides et les chiens de garde
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 s3filesfile-system-id:/ /mnt/s3files
Les journaux sont écrits dans/var/log/amazon/efs/. Le journal de l'assistant de 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 soit prise en compte. 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 d'étourdissement d'un système de fichiers dans un seul fichier, décommentez également 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 des journaux avec le AWS 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.gzÀ inclure dans votre étui de support.
