Clock and credentials

Fix RequestTimeTooSkewed, and tools that pick up the wrong keys.

This page helps when Zata answers RequestTimeTooSkewed, when a tool uses different keys than you expect, or when a command works in your terminal but fails in cron, systemd or on another computer.

Quick fixes

You see	Most likely cause	Fix
RequestTimeTooSkewed	The computer's clock is more than about 15 minutes off	Sync the clock
Certificate "not yet valid"	The computer's clock is wrong	Sync the clock
InvalidAccessKeyId although the key is right	An environment variable overrides your profile, or the endpoint is missing so requests go to AWS	Check which keys the tool uses
SignatureDoesNotMatch with the right keys in the file	The tool reads a different config file or an old environment variable	Check which keys the tool uses
Works in a terminal, fails in cron or systemd	The job runs as another user, or with almost no environment	Fix the scheduled job
Works on one computer, fails on another	A different config file, tool version or clock	Compare the two computers

The clock is wrong

Zata rejects a request when the computer's clock is more than about 15 minutes off. Every Zata response carries Zata's time in the Date header. Compare it with your computer's time (both in UTC):

curl -sI https://idr01.zata.ai | grep -i '^date'
date -u

If the two differ by minutes, turn on automatic time:

Linux

sudo timedatectl set-ntp true

Windows

In a terminal opened as administrator:

w32tm /resync

macOS

Open System Settings → General → Date & Time and turn on setting the time automatically.

A wrong clock can also show up as a certificate error ("not yet valid").

Which keys a tool really uses

AWS CLI and AWS SDKs

The AWS CLI shows each value it uses, the last four characters of the keys, and where each value came from (environment, credentials file or config file):

aws configure list --profile zata
aws configure get endpoint_url --profile zata

Compare the last four characters with the key on Access Keys in the Zata console.

The AWS CLI and SDKs look for keys in this order, and the first match wins:

1. Keys passed in the code or on the command line.
2. Environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_PROFILE, AWS_ENDPOINT_URL.
3. The profile in ~/.aws/credentials and ~/.aws/config.

A forgotten environment variable therefore overrides the file. To see which AWS_ variables are set without printing their values:

env | grep -o '^AWS_[A-Z_]*'

If the profile or environment in use has no Zata endpoint, requests go to AWS and fail with InvalidAccessKeyId. See Wrong endpoint or region.

rclone

rclone shows which config file it reads:

rclone config file

rclone uses the keys in that file. It reads the AWS_ environment variables only when the remote has env_auth = true.

Linux and Windows paths

	Linux and macOS	Windows
AWS credentials	~/.aws/credentials	%USERPROFILE%\.aws\credentials
AWS config	~/.aws/config	%USERPROFILE%\.aws\config
rclone config	shown by rclone config file	shown by rclone config file (usually %APPDATA%\rclone\rclone.conf)
Set a variable	export AWS_PROFILE=zata	set AWS_PROFILE=zata (cmd) or $env:AWS_PROFILE="zata" (PowerShell)

Works in a terminal, fails in cron or systemd

cron and systemd run jobs as another user, or with another HOME and almost no environment. The tool then reads a different config file, or none at all.

• rclone — give the config file explicitly:

  /usr/bin/rclone --config /home/YOUR_USER/.config/rclone/rclone.conf ls zata:my-bucket

  In a systemd service, set Environment=RCLONE_CONFIG=/home/YOUR_USER/.config/rclone/rclone.conf, or run the service as yourself with User=YOUR_USER.

• AWS CLI — set AWS_PROFILE=zata, and point AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE at your files. Or run the job as your own user.

• Use full paths to the tool, such as /usr/bin/rclone — cron's PATH is short. which rclone shows the path.

• Log the output to see the real error. In a crontab line, add >> /home/YOUR_USER/zata-job.log 2>&1 at the end. In a systemd service, use StandardOutput=append:/home/YOUR_USER/zata-job.log (systemd does not understand >).

A complete cron and systemd setup for backups is on rclone on Linux.

Never write the output of env or rclone config show to a shared place or a ticket: it contains your secret key.

Works on one computer, fails on another

Compare the two computers:

• Config files and environment — run aws configure list --profile zata or rclone config file on both.
• Tool versions — a newer AWS CLI or SDK sends default checksums that break large uploads. See Large uploads fail.
• Clock — check it on both, as above.
• Network — a proxy or security software may inspect TLS on one of them. See Network and certificates.

No temporary credentials

Zata uses access keys only. There are no temporary credentials, STS, AssumeRole or IAM roles, so tools that are set up to use them fail. Use an access key from Access Keys instead. To limit what a key can do, create a sub-user with access to only the buckets it needs. See Access keys.

Still stuck?

Contact Zata support (see Get support) and include:

• the tool and its version (aws --version, rclone version)
• the endpoint you use and the region of the bucket (Indore or Mumbai)
• the output of aws configure list --profile zata (it shows only the last four characters of the keys)
• the exact error code, and the RequestId from the error response
• the debug output (aws --debug, rclone -vv --dump headers), with access keys removed