S3 Backup failing: The difference between the request time and the current time is too large.

7 posts / 0 new
Last post
#1 Mon, 05/13/2013 - 09:48

S3 Backup failing: The difference between the request time and the current time is too large.

Hi ya all,

Thanks for taking the time out to help.

I have VM running on Centos. Backups to my S3 have been running smoothly up until a day ago. The all now fail:

Failed to list S3 buckets : The difference between the request time and the current time is too large. Backup failed! See the progress output above for the reason why.

After reading around on here I have tried to fix this by:

• Changing the system and hardware time (This was about 10mins out).

• Added: server 0.uk.pool.ntp.org server 1.uk.pool.ntp.org server 2.uk.pool.ntp.org server 3.uk.pool.ntp.org

to ntp.conf

• Check the command line 'date' is correct - it is.

• Changed Webmin > Hardware > System Time > Module Config > System Configuration to 'Detect Automatically

• Restarted the server

None of this has worked. Scheduled and immediate backups fail with the same message. The server is in the UK and the S3 is in Ireland, both of which share the same timezone. Its odd how this has just started to happen.

I did read about Webmin > Hardware > System Time >Time Sync Server being blank could be an issue? My time zone is set to GMT but the time sync schedule isn't active as I have no server in there. Could this be it?

Any help would be gratefully received - I hate running without backups! Scary stuff! Thanks in advance.

Tue, 05/14/2013 - 02:12

Is this forum still alive at all? Does anyone know where I can post to get some help?

Any advice would be awesome and greatly appreciated.


Tue, 05/14/2013 - 07:24

For anyone in the same boat as me here, my advice is to try and figure it out yourself as this forum seems to be dead. No support or advice. Shame.

I went down the track of checking everything that uses dates. My solution was that I un-comment:

date.timezone =



and added our timezone


Restarted Apache

Tue, 05/14/2013 - 09:02


This forum is plenty alive, I think folks just don't know the answer to your question :-)

What fixed your issue is unusual, as I didn't realize the S3 backup process used PHP.

Thanks for posting your solution though, and I'll make sure that Jamie is setting that upon installation of Virtualmin.


Tue, 05/14/2013 - 09:52

Thanks Eric.

I too thought it a bit odd that it was PHP based. After reading a few other posts, it seems that odd, unrelated changes seem to have fixed other peoples issue.

Thanks again. I can brief easy now I have backups. Keep up the good work.

Wed, 06/05/2013 - 03:02

Just wanted to add that I had this issue with a website on a server. Using a website addon that integrates with S3. I had to debug the addon to get the Amazon response, which stated the time difference was too large: http://expressionengine.stackexchange.com/questions/10170/assets-stopped...

So it seems Amazon does need the server time to be the same. I had to set the server time an hour behind because we are in GMT + 1.

P.S. I get great support in here! It wont be immediate but thats expected for non-premium support solutions!

Sat, 01/11/2020 - 09:00
Ilia's picture

The reason why this is happening is that the time is out-of-sync on your box, with the current time. Sync up your system clock and the issue will be solved.

You can sync your system clock by running the following command:

ntpdate 1.ro.pool.ntp.org

You would need to have ntpdate command installed, if not, install it:

apt-get install ntpdate    [On Debian/Ubuntu]
yum  install ntpdate       [On CentOS/RHEL]
dnf install ntpdate        [On Fedora 22+]


Topic locked