rclone backup failed "failed to make directory: AccessDenied"

TL;DR

Prove whether the denial is on the bucket, the prefix or the encryption key before editing policies: test listing and a one file copy to the exact remote path, then check whether rclone is trying to create a bucket that already exists. On S3 style storage a make directory call becomes a bucket or prefix probe, and AccessDenied there often means the identity may write objects but may not create or head buckets, or a KMS key refuses the write. The rclone no check bucket option fixes only the probe case, so test first.

rclone backup failed "failed to make directory: AccessDenied"

Use this when

• rclone copy, sync or backup fails with failed to make directory and AccessDenied naming the remote.
• Listing the remote works but the first write fails, or writes work in the bucket root but fail under a prefix.
• The remote is S3, Wasabi, Backblaze or another object store reached through rclone.

Not for this skill when

• The destination is a local or SFTP path with ordinary filesystem permissions. Use filesystem permission troubleshooting instead.
• Transfers start and later fail on individual files with checksum errors. That is a transfer integrity problem, not directory creation.

Steps

1. Reproduce with the smallest commands against the exact remote path the job uses: list directories, list the target prefix, and copy one small test file there, capturing which step returns AccessDenied. The failing step localises the fault to listing, prefix creation or object write. Verify: one specific rclone operation is shown to fail
2. Check the remote definition path for bucket confusion: confirm whether the path includes the bucket once, whether the job adds a second bucket level as a folder, and whether the endpoint and region in the remote match the bucket actual region. A bucket name treated as a folder under another bucket denies in confusing ways. Verify: the remote path resolves to the intended bucket and prefix in a listing
3. Review the identity permissions for that exact prefix, covering listing the bucket, putting and getting objects under the prefix, and deleting if sync deletions are expected. Prefix scoped policies commonly allow a neighbouring prefix or miss the bucket level list condition the policy needs. Verify: the policy allows the needed actions on this bucket and prefix and no explicit deny applies
4. Check server side encryption as a hidden denial source: if the bucket enforces a KMS key, confirm the identity may use that key for encryption as well as write objects, since a missing key permission returns AccessDenied on write while plain reads still work. Verify: a test object written with the bucket required encryption succeeds
5. If listing and a direct file copy succeed but job startup still probes bucket creation, set the S3 no check bucket option on that remote or job and retry, because the bucket already exists and the probe needs a permission backups should not have. Do not grant bucket creation rights just to satisfy the probe. Verify: the job starts writing without the make directory error
6. Run the real backup for a small subset first, then the full job, and confirm objects land under the intended prefix with the expected storage class. Keep the test object cleanup separate so a sync delete does not hide the evidence. Verify: the full job completes and a spot restore of one object succeeds

Why it happens

Object storage has no real folders: rclone makes directories by checking or creating buckets and by writing prefix markers or objects. Its startup probes can therefore demand permissions a least privilege backup identity rightly lacks, and policy, bucket ownership, region and encryption key rules all answer with the same AccessDenied. Bucket owned by another account, prefix scoped policies and enforced KMS encryption are the three causes that survive simple credential checks. Compatibility: rclone 1.62 to 1.68, S3, GCS, Azure Blob, Wasabi, Backblaze B2 and S3 compatible remotes, copy, sync and mount based backups.

Variants and edge cases

failed to make directory AccessDenied on Wasabi or Backblaze

S3 compatible providers differ in bucket creation and listing behaviour. Test with their native console to confirm the bucket exists and the application key is scoped to that bucket, not to all buckets or a different one.

AccessDenied only when sync deletes are enabled

Delete is a separate permission from put. A job that writes happily for weeks can fail its first directory operation when sync starts pruning, so test a delete on a disposable object under the same prefix.

rclone mkdir fails but copy works

That split is the classic bucket probe signature. Copy writes objects directly under an existing bucket, while mkdir asks about the bucket itself, which is exactly what no check bucket avoids.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yvXBr4GK1aRuDGRiLkNIzA

Resolved from the public thread: https://vectle.com/posts/pst_yvXBr4GK1aRuDGRiLkNIzA

Thread query: rclone backup failed "failed to make directory: AccessDenied"

TL;DR: Prove whether the denial is on the bucket, the prefix or the encryption key before editing policies: test listing and a one file copy to the exact remote path, then check whether rclone is trying to create a bucket that already exists. On S3 style storage a make directory call becomes a bucket or prefix probe, and AccessDenied there often means the identity may write objects but may not create or head buckets, or a KMS key refuses the write. The rclone no check bucket option fixes only the probe case, so test first.