[GH-ISSUE #61] Use s3fs with a proxy - no write permission #36

New issue

Closed

opened 2026-03-04 01:41:23 +03:00 by kerem · 2 comments

kerem commented

2026-03-04 01:41:23 +03:00

Owner

Originally created by @cjuste on GitHub (Oct 1, 2014).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/61

Hello,

I'm using s3fs with a transparent proxy squid.
I'm using the allow_other option.

I can read data on s3 without any problem, s3 and my directory are synced.
But if I try for example

 mkdir /mnt/s3/test/

I always get :

 mkdir: cannot create directory ‘/mnt/s3/test/’: Operation not permitted

For this machine, I have to use a proxy. I've tried on another machine, which works fine without the proxy (it's the same accessKey/secretKey and the same bucket). If I activate the proxy on this other machine, I get the same problem (without changing anything else).

I've looked to the http data. I get the following messaging from Amazon, for the PUT method :

<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message>

I have the same problem if I want to copy/create a file in the mounted directory.
It seems Amazon is recalculating the signature only in the case of a PUT method.

I've configured Squid with, looking to the Issue 59 :

via off
forwarded_for off
ignore_expect_100 on

Originally created by @cjuste on GitHub (Oct 1, 2014). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/61 Hello, I'm using s3fs with a transparent proxy squid. I'm using the allow_other option. I can read data on s3 without any problem, s3 and my directory are synced. But if I try for example ``` mkdir /mnt/s3/test/ ``` I always get : ``` mkdir: cannot create directory ‘/mnt/s3/test/’: Operation not permitted ``` For this machine, I have to use a proxy. I've tried on another machine, which works fine without the proxy (it's the same accessKey/secretKey and the same bucket). If I activate the proxy on this other machine, I get the same problem (without changing anything else). I've looked to the http data. I get the following messaging from Amazon, for the PUT method : ``` <Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message> ``` I have the same problem if I want to copy/create a file in the mounted directory. It seems Amazon is recalculating the signature only in the case of a PUT method. I've configured Squid with, looking to the <a href="https://code.google.com/p/s3fs/issues/detail?id=59">Issue 59</a> : ``` via off forwarded_for off ignore_expect_100 on ```

kerem closed this issue

2026-03-04 01:41:23 +03:00

kerem commented

2026-03-04 01:41:24 +03:00

Author

Owner

@gaul commented on GitHub (Oct 1, 2014):

Some proxies rewrite or add some headers, probably the Date in this case. If you can dump the HTTP request before and after it hits the proxy we can debug this further. If it is rewriting date, you might be able to configure squid differently or we can change s3fs-fuse to use the x-amz-date header instead:

http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

@gaul commented on GitHub (Oct 1, 2014): Some proxies rewrite or add some headers, probably the Date in this case. If you can dump the HTTP request before and after it hits the proxy we can debug this further. If it is rewriting date, you might be able to configure squid differently or we can change s3fs-fuse to use the x-amz-date header instead: http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

kerem commented

2026-03-04 01:41:24 +03:00

Author

Owner

@cjuste commented on GitHub (Oct 2, 2014):

Thanks a lot for the tip, I found the problem.
Squid wasn't rewriting the date, it was simply than some custom headers were'nt allowed in the configuration and so were cut by Squid.

Adding the squid configuration :

request_header_access All allow all

solved the problem.

@cjuste commented on GitHub (Oct 2, 2014): Thanks a lot for the tip, I found the problem. Squid wasn't rewriting the date, it was simply than some custom headers were'nt allowed in the configuration and so were cut by Squid. Adding the squid configuration : ``` request_header_access All allow all ``` solved the problem.

kerem referenced this issue

2026-03-04 01:53:22 +03:00

[PR #36] [MERGED] Changed codes for CR code in passwd file(googlecode issue#417). #1320