# \`rake uploads:migrate\_to\_s3\` échoue avec \`Aws::S3::Errors::SignatureDoesNotMatch\`
**URL:** https://meta.discourse.org/t/rake-uploads-migrate-to-s3-fails-with-aws-signaturedoesnotmatch/141518
**Category:** Self-hosting
**Tags:** s3
**Created:** [Février 13, 2020, 3:17 UTC](https://meta.discourse.org/t/rake-uploads-migrate-to-s3-fails-with-aws-signaturedoesnotmatch/141518 "2020-02-13T15:17:02Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@md-misko](https://meta.discourse.org/u/md-misko)
#### Post date: [Février 13, 2020, 3:17 UTC](https://meta.discourse.org/t/rake-uploads-migrate-to-s3-fails-with-aws-signaturedoesnotmatch/141518/1 "2020-02-13T15:17:02Z")
Le téléchargement de fichiers locaux vers DigitalOcean Spaces (S3) avec `rake uploads:migrate_to_s3` démarre et migre certains fichiers, puis échoue soudainement pour un fichier avec l’erreur `Aws::S3::Errors::SignatureDoesNotMatch`.
Lorsque ce fichier est téléchargé manuellement en utilisant le script mentionné dans [Extend S3 configuration for other S3 API compatible services - #4 by rishabh](https://meta.discourse.org/t/extend-s3-configuration-for-other-s3-api-compatible-services/90371/4?u=md-misko) et que le script est relancé, il télécharge plus de fichiers mais échoue à nouveau pour un autre fichier.
Quelqu’un de l’équipe pourrait-il s’en occuper ? J’ai près de 50 Go de fichiers que je dois déplacer du stockage local vers S3 dans un proche avenir (la configuration et le téléchargement des nouveaux fichiers fonctionnent sans problème).
Je serais même satisfait d’une simple solution de contournement pour l’instant : j’ai examiné le code `to_s3_migration.rb` et je peux identifier les fichiers problématiques, mais lorsque je les télécharge sur S3 en utilisant `Aws::S3::Resource` à partir du script mentionné ci-dessus, les métadonnées du fichier sont manquantes et le nom original du fichier est perdu lors du téléchargement.
Une recherche sur le web renvoie de nombreux problèmes liés à SignatureDoesNotMatch : l’un d’eux mentionne que la version de l’algorithme de signature utilisé par le gem pourrait être incorrecte, mais cela dépasse mes compétences actuelles pour vérifier.
Voici la configuration pour rake :
```plaintext
DISCOURSE_S3_ACCESS_KEY_ID="id" \
DISCOURSE_S3_SECRET_ACCESS_KEY="secret" \
DISCOURSE_S3_REGION="sfo2" \
DISCOURSE_S3_BUCKET="mybucket/uploads" \
DISCOURSE_S3_ENDPOINT="https://sfo2.digitaloceanspaces.com" \
DISCOURSE_S3_CDN_URL="https://mybucket.sfo2.cdn.digitaloceanspaces.com" \
rake uploads:migrate_to_s3 --trace
```
---
### Author:  [@md-misko](https://meta.discourse.org/u/md-misko)
#### Post date: [Février 13, 2020, 8:55 UTC](https://meta.discourse.org/t/rake-uploads-migrate-to-s3-fails-with-aws-signaturedoesnotmatch/141518/2 "2020-02-13T20:55:17Z")
Il s’est avéré que DO Spaces n’accepte pas les espaces consécutifs dans les métadonnées des fichiers et échoue avec une erreur totalement sans rapport. Peut-être vaut-il la peine de vérifier si AWS S3 impose la même contrainte.
Quoi qu’il en soit, la solution rapide a été de fusionner les espaces multiples en un seul :
>
```plaintext
%Q{attachment; filename="#{upload.original_filename.gsub(/\s+/, ' ')}"}
```
---
### Author:  [@eextra](https://meta.discourse.org/u/eextra)
#### Post date: [Mars 13, 2020, 8:26 UTC](https://meta.discourse.org/t/rake-uploads-migrate-to-s3-fails-with-aws-signaturedoesnotmatch/141518/3 "2020-03-13T08:26:03Z")
s’agit-il d’un amendement officiel ? qu’en est-il des autres erreurs lors de la migration vers S3 ?
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [Avril 12, 2020, 8:26 UTC](https://meta.discourse.org/t/rake-uploads-migrate-to-s3-fails-with-aws-signaturedoesnotmatch/141518/4 "2020-04-12T08:26:07Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.