> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.zata.prathamchopde.site/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.zata.prathamchopde.site/_mcp/server.

# 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

| You see                                                 | Most likely cause                                                                                | Fix                                                                    |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- |
| `RequestTimeTooSkewed`                                  | The computer's clock is more than about 15 minutes off                                           | [Sync the clock](#the-clock-is-wrong)                                  |
| Certificate "not yet valid"                             | The computer's clock is wrong                                                                    | [Sync the clock](#the-clock-is-wrong)                                  |
| `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](#which-keys-a-tool-really-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](#which-keys-a-tool-really-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-in-a-terminal-fails-in-cron-or-systemd) |
| Works on one computer, fails on another                 | A different config file, tool version or clock                                                   | [Compare the two computers](#works-on-one-computer-fails-on-another)   |

## 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):

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

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

#### Linux

```bash
sudo timedatectl set-ntp true
```

#### Windows

In a terminal opened as administrator:

```powershell
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):

```bash
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:

```bash
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](/help/troubleshooting/endpoint-and-region).

### rclone

rclone shows which config file it reads:

```bash
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:

  ```bash
  /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](/connect/command-line/rclone-linux).

> **Warning**
>
> 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](/help/troubleshooting/large-uploads).
* **Clock** — check it on both, as above.
* **Network** — a proxy or security software may inspect TLS on one of them. See [Network and certificates](/help/troubleshooting/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](/sub-users/overview) with access to only the buckets it needs. See [Access keys](/access/access-keys).

## Still stuck?

Contact Zata support (see [Get support](/help/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