[GH-ISSUE #1019] Time problem with large files #559

New issue

Closed

opened 2026-03-04 01:46:45 +03:00 by kerem · 3 comments

kerem commented

2026-03-04 01:46:45 +03:00

Owner

Originally created by @DigitalCyberSoft on GitHub (Apr 25, 2019).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1019

This is using the latest built version of s3fs.

While uploading a very large file, it eventually starts throwing the following error until retries run out

[ERR] curl.cpp:RequestPerform(2273): HTTP response code 403, returning EPERM. Body Text: <?xml version="1.0" encoding="UTF-8"?>
<Error><Code>RequestTimeTooSkewed</Code><Message>The difference between the request time and the current time is too `large.</Message><RequestTime>20190425T030525Z</RequestTime><ServerTime>2019-04-25T03:20:29Z</ServerTime><MaxAllowedSkewMilliseconds>900000</MaxAllowedSkewMilliseconds><RequestId>6DF0BC81DF47A</RequestId><HostId>Bk0RsQE3gAMknO52Din1h13t0b57Vpphx6fTizHRlTspybFoIDCmvhbW+s6mEwz96EUybZcA=</HostId></Error>`

File size is 342,798,923,129 bytes and the error at around [start=342360064000][size=438859129][part=654]

For reference:

# ntpdate us.pool.ntp.org
24 Apr 20:23:53 ntpdate[4203]: adjust time server 74.117.214.2 offset -0.002418 sec

Originally created by @DigitalCyberSoft on GitHub (Apr 25, 2019). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1019 This is using the latest built version of s3fs. While uploading a very large file, it eventually starts throwing the following error until retries run out ``` [ERR] curl.cpp:RequestPerform(2273): HTTP response code 403, returning EPERM. Body Text: <?xml version="1.0" encoding="UTF-8"?> <Error><Code>RequestTimeTooSkewed</Code><Message>The difference between the request time and the current time is too `large.</Message><RequestTime>20190425T030525Z</RequestTime><ServerTime>2019-04-25T03:20:29Z</ServerTime><MaxAllowedSkewMilliseconds>900000</MaxAllowedSkewMilliseconds><RequestId>6DF0BC81DF47A</RequestId><HostId>Bk0RsQE3gAMknO52Din1h13t0b57Vpphx6fTizHRlTspybFoIDCmvhbW+s6mEwz96EUybZcA=</HostId></Error>` ``` File size is 342,798,923,129 bytes and the error at around [start=342360064000][size=438859129][part=654] For reference: ``` # ntpdate us.pool.ntp.org 24 Apr 20:23:53 ntpdate[4203]: adjust time server 74.117.214.2 offset -0.002418 sec ```

kerem closed this issue

2026-03-04 01:46:45 +03:00

kerem commented

2026-03-04 01:46:46 +03:00

Author

Owner

@gaul commented on GitHub (Apr 25, 2019):

I wonder if the retry code updates x-amz-date and resigns the request?

@gaul commented on GitHub (Apr 25, 2019): I wonder if the retry code updates `x-amz-date` and resigns the request?

kerem commented

2026-03-04 01:46:46 +03:00

Author

Owner

@DigitalCyberSoft commented on GitHub (Apr 25, 2019):

I wonder if the retry code updates x-amz-date and resigns the request?

I assumed something like this, as the problem appears to have popped up 30-40 minutes after the upload started.

@DigitalCyberSoft commented on GitHub (Apr 25, 2019): > I wonder if the retry code updates `x-amz-date` and resigns the request? I assumed something like this, as the problem appears to have popped up 30-40 minutes after the upload started.

kerem commented

2026-03-04 01:46:46 +03:00

Author

Owner

@gaul commented on GitHub (Jul 2, 2019):

You can probably work around this by downgrading to version 1.84 until we can address this properly.

@gaul commented on GitHub (Jul 2, 2019): You can probably work around this by downgrading to version 1.84 until we can address this properly.

kerem referenced this issue

2026-03-04 02:01:00 +03:00

[PR #560] [MERGED] Fixed about multipart uploading at no free space related to #509 #1550