rclone backup failed failed to make directory: AccessDenied

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

Permission denied publickey means the SFTP server refused the key the restic process offers: confirm which key file the backup's user context loads, that the matching public key is in the server account's authorised keys, and that file permissions on the key and the server-side file satisfy the SSH server's strict checks. Test the exact connection with a plain SFTP login using the same user, host, and key before involving restic.

restic backup to SFTP failed "unable to connect: permission denied (publickey)"

Use this when

• The job or restore fails with this symptom: restic backup to SFTP failed with unable to connect: permission denied (publickey).
• You are working on a restic backup writing to an SFTP backend and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A server that disabled public key authentication in favour of another method, where the fix is the server's auth configuration.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Reproduce the connection with a verbose SFTP or SSH attempt using the backup job's user, host, and key file. Verify: the offered key and the server's response are visible
2. Compare the offered key's fingerprint with the public keys authorised on the server account. Verify: key pairing is confirmed or found mismatched
3. Check permissions: the private key readable only by its owner, and the server-side authorised keys file owned and writable only by its account. Verify: permission causes are cleared
4. Run the restic backup again and confirm snapshots begin landing in the repository. Verify: the backup connects and writes

Variant phrasings

restic sftp unable to connect permission denied publickey

The verbatim phrasing.

restic backup sftp publickey denied key authorised fix

The key phrasing.

restic sftp backend authentication failed verbose ssh

The verbose phrasing.

Compatibility: restic backups over SFTP with public key authentication

Why it happens

SFTP key authentication fails in identical words for a wrong key, an unauthorised key, and permission problems at either end, because the server deliberately reveals little. The verbose client output and the fingerprint comparison are what turn the generic refusal into a named cause.

Edge cases / pitfalls

• Scheduled jobs run as a different user with a different home and key set than the interactive setup; always test as the job's user.
• A rotated server host key produces a different error, but in some wrappers it is folded into this one; check host key verification too.

Provenance

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

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

Thread query: restic backup to SFTP failed "unable to connect: permission denied (publickey)"

TL;DR: Permission denied publickey means the SFTP server refused the key the restic process offers: confirm which key file the backup's user context loads, that the matching public key is in the server account's authorised keys, and that file permissions on the key and the server-side file satisfy the SSH server's strict checks. Test the exact connection with a plain SFTP login using the same user, host, and key before involving restic.

Not specified by the original author.

TL;DR

Rsync permission denied splits into source reads and destination writes, and the log line names which side. For reads, the backup user needs traverse and read rights on the tree, often via a dedicated backup account or sudo-wrapped rsync on the remote side. For writes, check destination ownership and whether preserving owner and group needs elevated rights.

rsync "permission denied" during backup

Use this when

• rsync logs permission denied on specific files or directories.
• Files owned by other users or root are skipped every run.
• Destination files arrive but ownership preservation errors fill the log.

Not for this skill when

• SSH authentication itself is denied before rsync starts. Fix keys and accounts first.
• The destination disk is mounted read-only. That is a mount problem.

Steps

1. From the log, separate denied lines into source read failures and destination write failures with their paths. Verify: each denial is assigned a side
2. Check the identity rsync runs as on both ends, including the remote command user for SSH transfers. Verify: both identities are known
3. Grant the backup identity read access on the source tree via group membership or ACLs, avoiding world-readable changes on sensitive data. Verify: the backup user can read one previously denied file
4. On the destination, fix directory ownership or drop owner and group preservation flags the run cannot honour, keeping permissions flags that matter. Verify: a test transfer writes without denial lines
5. Rerun the full backup and confirm no permission denied lines remain. Verify: the run exits 0 with a clean log

Variant phrasings

rsync permission denied backup user sudo

The sudo-rsync phrasing.

rsync failed to set permissions destination

The destination-preservation variant.

rsync cannot read files permission denied root

The root-owned files wording.

Compatibility: rsync 3.2 and later over SSH and daemon modes on Linux and macOS, including sudo rsync remote helper setups.

Why it happens

Backups want to read everything and preserve everything, which collides with least-privilege defaults. An unprivileged backup user cannot read other users private files or chown destination files, so the same run shows two different denial classes. Fixing them needs access design, not a retry.

Edge cases / pitfalls

• Using --fake-super on the destination stores ownership in extended attributes without needing root.
• A dedicated backup group with read ACLs is safer than running the whole backup as root over SSH.
• Daemon mode has its own uid and gid settings that override the connecting user. Check rsyncd configuration.

Provenance

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

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

Thread query: rsync "permission denied" during backup

TL;DR: Rsync permission denied splits into source reads and destination writes, and the log line names which side. For reads, the backup user needs traverse and read rights on the tree, often via a dedicated backup account or sudo-wrapped rsync on the remote side. For writes, check destination ownership and whether preserving owner and group needs elevated rights.