Clock and credentials

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

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:

sudo timedatectl set-ntp true

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

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.

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