Access denied

This page helps when Zata answers 403 AccessDenied, when a bucket is missing from your bucket list, or when some actions work and others are denied. Most of these cases come from sub-user permissions.

Quick fixes

If you get InvalidAccessKeyId or NoSuchBucket instead, see Wrong endpoint or region.

A sub-user’s bucket list is empty

A sub-user key always gets an empty bucket list (aws s3 ls, rclone lsd zata:, s3cmd ls), even for buckets the sub-user can use. This is not an error. Open the bucket by its name:

aws s3 ls s3://my-bucket --profile zata

In apps, type the bucket name instead of choosing it from a list:

Sub-users also cannot create buckets: CreateBucket always gives AccessDenied with a sub-user key. Only the account owner creates buckets. See Sub-users.

rclone gets AccessDenied on upload

Before an upload or copy, rclone checks whether the bucket exists and tries to create it. A sub-user key is not allowed to do that. Turn the check off:

rclone config update zata no_check_bucket=true sign_accept_encoding=false

no_check_bucket fixes AccessDenied on upload and copy; it does not fix listing errors. See rclone on Linux.

Check the sub-user’s permission

The account owner decides what a sub-user may do on each bucket. In the Zata console, open Subusers, select the sub-user and look at Bucket Access Management. Each bucket has one of these permissions:

Also check:

• Folder scope — a rule can be limited to one folder. Everything outside that folder is denied.
• Policies — a policy made on the Policies page can allow single actions (for example List files without Download files), and its Effect can be Deny. This explains most “some actions work, others are denied” cases.
• Status — the sub-user must be Active, not suspended.

Some actions are never given to sub-users, whatever the permission: changing bucket or file permissions (ACLs), changing versioning, and adding or editing tags.

To change access, see Assign a bucket, Access types and Bucket policies.

Object Lock blocks deletes

In a bucket with Object Lock, a locked file version cannot be deleted or overwritten until its retention date passes, and a file under legal hold cannot be deleted until the hold is removed. This is true even with Full Access. Object Lock never blocks downloads.

In Governance mode the account owner can remove the lock; in Compliance mode nobody can. See Object Lock.

Bucket policies that do not work

A bucket policy written for AWS can fail on Zata. Zata has no IAM user or role policies, does not support policy variables such as ${aws:username}, and uses Zata user IDs as principals, not AWS account IDs. The easiest way to get a policy right is to create it in the console: Policies → Create Policy. See Policy support for the actions and condition keys Zata supports.

Find the missing permission

1. Check which key the tool uses. The AWS CLI shows the last four characters of the key:

   aws configure list --profile zata

   Compare it with Access Keys in the Zata console. Make sure the key belongs to the right sub-user and to the bucket’s region.

2. Test each action with the same key, one by one:

   aws s3api head-bucket --bucket my-bucket --profile zata
   aws s3 ls s3://my-bucket/ --profile zata
   aws s3 cp test.txt s3://my-bucket/test.txt --profile zata
   aws s3 cp s3://my-bucket/test.txt ./test-copy.txt --profile zata
   aws s3 rm s3://my-bucket/test.txt --profile zata

   The first command that fails shows the missing permission: check bucket, list, upload, download, delete.

3. As the account owner, open Subusers, select the sub-user and check the rule in Bucket Access Management: the permission, the folder scope and the status.

See the real error

Zata’s error responses contain an error code but no message text, so look for the code. The debug output contains your access key ID — remove it before you share the output.

head-bucket and other HEAD requests have no response body, so they only show 403 Forbidden. Run aws s3 ls s3://my-bucket --profile zata --debug to see the code.

Still stuck?

Contact Zata support (see Get support) and include:

• the tool and its version (aws --version, rclone version, s3fs --version)
• the endpoint you use and the region of the bucket (Indore or Mumbai)
• whether you use the owner’s key or a sub-user’s key
• the exact error code, and the RequestId from the error response
• the debug output from above, with access keys removed