SignatureDoesNotMatch

Suspected Bug
1

What is the problem you are having with rclone?

When we sent big size data to the bucket via rclone, I get this error:

upload id: 4f823a9d-75f5-4529-9972-66d306e707bb
caused by: SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
status code: 403, request id: a6428bb9-6ef3-4228-a598-cc051a371a49, host id: a6428bb9-6ef3-4228-a598-cc051a371a49
2019/12/11 10:49:03 ERROR : tmp/en_windows_7_ultimate_x64_dvd.iso(0xc0001fade0): RWFileHandle.Flush error: failed to transfer file from cache to remote: MultipartUpload: upload multipart failed

However, when we copy small size files that work.

ALSO, I don't have this error with rclone v1.49.5

What is your rclone version (output from rclone version)

rclone v1.50.1

  • os/arch: linux/amd64
  • go version: go1.13.4

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Linux data 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64 GNU/Linux

Which cloud storage system are you using? (eg Google Drive)

S3 compatible storage, provider: Exoscale (exoscale.com)

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone mount data: mnt/ --config /var/lib/data/rclone.conf --vfs-cache-mode=full --vfs-cache-max-size=40G --cache-dir=/var/lib/data/cache
cp big_file mnt/

A log from the command with the -vv flag (eg output from rclone -vv copy /tmp remote:tmp)

upload id: 4f823a9d-75f5-4529-9972-66d306e707bb
caused by: SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
status code: 403, request id: a6428bb9-6ef3-4228-a598-cc051a371a49, host id: a6428bb9-6ef3-4228-a598-cc051a371a49
2019/12/11 10:49:03 ERROR : tmp/en_windows_7_ultimate_x64_dvd.iso(0xc0001fade0): RWFileHandle.Flush error: failed to transfer file from cache to remote: MultipartUpload: upload multipart failed

2

Hmm, this is probably an incompatibility with Exoscale.

Can you try to replicate the problem with rclone copy, then experiment with --s3-upload-cutoff 5G to see if you can work-around the problem?

It would be useful to see the failing transaction with -vv --dump requests and compare that with the same one from v1.49.5 to see if you can spot the difference.

These are the changes from 1.49 to 1.50 in the s3 backend

ab895390f s3: fix nil pointer reference if no metadata returned for object
7b1274e29 s3: support for multipart copy
6b55b8b13 s3: add option for multipart failiure behaviour
6e053ecbd s3: only ask for URL encoded directory listings if we need them on Ceph
33f129fbb s3: use lib/encoder
a8adce9c5 s3: fix encoding for control characters - Fixes #3345
899f28531 s3: fix signature v2_auth headers
25786cafd s3: fix SetModTime on GLACIER/ARCHIVE objects and implement set/get tier
66c23723e Add context to all http.NewRequest #3257
3

Thank you for your response.

When I added --s3-upload-cutoff 5G with rclone copy, the problem is resolved.

4

So that means that the multi part uploads are incompatible for some reason.

Rclone uses the official AWS SDK so I'd guess that this is a bug in exoscale.

I don't know why it was working and now doesn't though...