Access denied

Fix AccessDenied, missing buckets and sub-user permission problems.

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

You see	Most likely cause	Fix
Bucket list is empty, but you can use the bucket	You use a sub-user key: a sub-user's bucket list is always empty	Open the bucket by its name
AccessDenied when you create a bucket	Sub-users cannot create buckets	Ask the account owner to create it
rclone: AccessDenied on upload or copy	rclone tries to check or create the bucket first	Set no_check_bucket = true
You can upload, but not list or browse	The sub-user has Upload Only	Check the sub-user's permission
You can list, but downloads are denied	A policy allows listing but not Download files, a Deny policy, or a rule for another folder	Check the sub-user's permission
You can upload, but not delete	View & Upload has no delete, or the file is locked by Object Lock	Check the permission or Object Lock
Rename or move fails	A rename is a copy plus a delete, so it needs Full Access	Give the sub-user Full Access on that bucket or folder
Works in the console, AccessDenied in an app	The app uses a different key (another sub-user, the other region, or an old key)	Check which key the app uses
head-bucket is denied, but downloads work	Checking a bucket needs list permission	Allow listing (List files) as well
AWS CLI: argument of type 'NoneType' is not a container or iterable	The AWS CLI cannot display Zata's error	Run the command with --debug

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:

Tool	What to do
rclone	use zata:my-bucket directly, and set no_check_bucket = true
s3fs	mount my-bucket by name
S3 Browser	add the bucket as an external bucket — see S3 Browser for sub-users
Cyberduck	open the path /my-bucket

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:

Permission	Allows	Does not allow
View Only	list and download	upload, delete
Upload Only	upload new files	list, download, delete
View & Upload	list, download and upload	delete
Full Access	everything on the bucket's files, including delete	—

You pick View Only when you add the permission, but an assigned rule shows as View & Download in the bucket list (unless you gave it a note). They are the same permission.

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 can never be given to a sub-user, whatever the permission or policy: changing file or bucket permissions (ACLs), changing versioning, and adding or editing tags. The read-only versions can be granted, though — viewing file permissions, viewing file tags, and removing file tags — with Full Access or a custom policy.

Mount tools such as s3fs list the bucket when they start, so a sub-user with Upload Only cannot mount it. Use View & Upload or Full Access.

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 still delete a locked version early (see Governance mode for who else can); 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.

Tool	Run	Look for
AWS CLI	add --debug to the command	<Code> in the Response body line
rclone	add -vv --dump headers	the HTTP status and api error with the code in the last line
s3fs	mount with -f -o dbglevel=info	the failing request and its HTTP response code
boto3	catch ClientError	e.response["Error"]["Code"]

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