mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 05:16:00 +03:00
[GH-ISSUE #133] SignatureDoesNotMatch #82
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#82
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Simon-87 on GitHub (Feb 28, 2015).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/133
Hi!
I have got a problem using the latest version of s3fs.
OS: CentOS Linux release 7.0.1406 (Core)
Kernel: 3.14.18-x86_64-jb1 #2 SMP Mon Sep 15 05:23:31 CEST 2014 x86_64 x86_64 x86_64 GNU/Linux
S3 Bucket Region: eu-central-1
Mountcommand: s3fs -d mybucketname /s3mnt -oendpoint=eu-central-1 -oallow_other
Every time i try to copy a file lager than 5MB to the S3 bucket, i get this error:
SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
Copying files up to ~5MB to the bucket works correctly. And receiving files from amazon also.
I hope someone could help me.
@ggtakec commented on GitHub (Mar 1, 2015):
@Simon-87 I'm sorry about bugs, I merged PR by @andrewgaul into master branch.
Please test latest codes.
@andrewgaul Thanks very much.
@delx commented on GitHub (Apr 14, 2015):
I cloned the master branch (
07e007052a), but I still get the error: SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.@ggtakec commented on GitHub (Apr 14, 2015):
@delx
I reopen this issue.
And I tried to check s3fs with same option as you( but another region ), and got no problem.(ex under/over 5MB file uploading etc)
If you have debug messages from s3fs, please let me know.
And please check your credential(/etc/passwd-s3fs or $HOME/.passwd-s3fs).
Thanks in advance for your assistance.
@delx commented on GitHub (Apr 14, 2015):
@ggtakec: Thank you very much for your quick answer.
I created a new bucket "s3fs-fuse-test" in Frankfurt (eu-central-1). I enabled versioning on this bucket. Then I created a new user "s3fs-fuse-test" with an access key. I added the following inline policy to the new user:
Then I added the access key and secure key separated by a colon to my /etc/passwd-s3fs. The secure key contains multiple plus signs and a slash. If you contact me privately I can share the keys. Then I created the directory /mnt/s3fs-fuse-test as root. I executed the s3fs command also as root:
I'm using the latest master branch.
Thank you very much in advance.
@ggtakec commented on GitHub (Apr 18, 2015):
I merged #168.
I close this issue, if this problem is kept, please reopen this issue.
Thank you very much.
@jurov commented on GitHub (Jun 22, 2015):
I have installed current master (commit
8f85e5e) and got the same problem.@jurov commented on GitHub (Jun 22, 2015):
Adding -o url="http://s3-eu-central-1.amazonaws.com" option to above solved the problem completely.
@MattFenelon commented on GitHub (Jan 14, 2016):
I'm getting the same problem with a bucket in the eu-west-1 region, using https.
Changing the command to set the url parameter to eu-west-1 fixes the problem.
@ggtakec commented on GitHub (Jan 16, 2016):
Could you try to run s3fs without endpoint option.
s3fs try to connect http(s)://s-.amazonaws.com automatically, after failing to connect first.
If that does not help, you should specify url option.
Thanks in advance for your help.
@MattFenelon commented on GitHub (Jan 18, 2016):
@ggtakec Removing the endpoint option and setting url=https://s3.ama... worked. Checking the logs, it looks like s3fs correctly detects the url change, and then uses the region-specific url from that point on. Should the endpoint option be removed?
Thanks for the help.
@ggtakec commented on GitHub (Jan 18, 2016):
@MattFenelon
Because endpoint option is for compatibility and there is still a possibility that there is a use value, we are supporting it now.
However, it is an option that should be removed in the future.
Thanks for your reporting.
Regards,