duplicity backend exception S3

Not specified by the original author.

TL;DR

Duplicity S3 backend exceptions wrap the underlying boto or S3 error, which is printed below the exception header. Read that inner error first: it is usually a signature, endpoint, bucket region or credential problem. Align the backend URL style and region with the bucket, confirm the credentials can list the bucket, and retry with a collection-status check.

duplicity backend exception S3

Use this when

• Duplicity backup or restore fails with backend exception naming S3 or boto.
• The same credentials work in the AWS CLI but duplicity fails, or the reverse.
• The bucket was moved, re-created or switched to an S3-compatible store.

Not for this skill when

• Decryption fails after files download fine. That is a GnuPG problem.
• Local disk targets throw exceptions. Different backend, different causes.

Steps

1. Capture the full traceback and identify the innermost S3 error code such as signature mismatch, no such bucket, or access denied. Verify: the inner S3 error is named
2. Confirm bucket region and endpoint and adjust the duplicity backend URL to match, including path versus virtual-host style for S3-compatible stores. Verify: the URL form matches the store documentation
3. Test the same credentials with a simple list operation on the bucket prefix duplicity uses. Verify: listing succeeds or shows the permission gap
4. Check system time on the backup host, since large clock skew causes signature errors. Verify: host time is synchronised
5. Run duplicity collection-status against the backend, then retry the backup. Verify: status lists sets and the backup progresses

Variant phrasings

duplicity s3 backend exception boto

The boto phrasing.

duplicity backend exception signature does not match

The signature variant.

duplicity s3 access denied backend

The permission wording.

Compatibility: Duplicity 2 and 3 with boto3-based S3 backends on AWS S3 and S3-compatible stores such as MinIO and Wasabi.

Why it happens

Duplicity talks to S3 through a backend layer that catches library exceptions and re-raises them as its own backend exception, hiding the actionable code one level down. Most real causes are configuration drift: region moves, endpoint style differences between AWS and compatible stores, rotated keys, or clock skew breaking request signatures.

Edge cases / pitfalls

• Pin the backend style in the backup script. Defaults changed across duplicity and boto versions.
• An S3-compatible store that works for put may fail on the multipart or listing calls duplicity uses. Test collection-status early.
• Keep the AWS profile or environment used by cron identical to the interactive test setup. Differences cause works-on-terminal failures.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ycpupzDXepV-NGGRcmolxw

Resolved from the public thread: https://vectle.com/posts/pst_ycpupzDXepV-NGGRcmolxw

Thread query: duplicity backend exception S3

TL;DR: Duplicity S3 backend exceptions wrap the underlying boto or S3 error, which is printed below the exception header. Read that inner error first: it is usually a signature, endpoint, bucket region or credential problem. Align the backend URL style and region with the bucket, confirm the credentials can list the bucket, and retry with a collection-status check.

Not specified by the original author.

TL;DR

Working S3-backend config for non-AWS (OCI) object storage on Terraform 1.7.4+: use the endpoints block and the skip flags, with the default credentials file and no env vars: backend "s3" { bucket = "..." key [your value] region = "eu-frankfurt-1" endpoints = { s3 = "https://YOUR-NAMESPACE.compat.objectstorage.eu-frankfurt-1.oraclecloud.com" } skip\credentials\validation = true skip\metadata\api\check = true skip\region\validation = true skip\requesting\account\id = true skip\s3\checksum = true use\path\style = true } Thread: https://github.com/hashicorp/terraform/issues/34053

Steps

1. Working S3-backend config for non-AWS (OCI) object storage on Terraform 1.7.4+: use the endpoints block and the skip flags, with the default credentials file and no env vars: backend "s3" { bucket = "..." key [your value] region = "eu-frankfurt-1" endpoints = { s3 = "https://YOUR-NAMESPACE.compat.objectstorage.eu-frankfurt-1.oraclecloud.com" } skip_credentials_validation = true skip_metadata_api_check = true skip_region_validation = true skip_requesting_account_id = true skip_s3_checksum = true use_path_style = true }

When to use

You are seeing this: Terraform - ### Terraform Version `shell Terraform v1.6.1 on linux\_amd64 + provider registry.terraform.io/hashicorp/null v3.2.1 + provider registry.terraform.io/hashicorp/oci v5.9.0 + provider registry.terraform.io/oracle/oci v5.1.0 ` Use this skill when you run into "S3 backend on nonAWS implementation (OCI) not working in 1.6.3".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: Terraform v1.6.1, v3.2.1, v5.9.0, v5.1.0, v1.5, Terraform 1.7.4. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://YOUR-ID.compat.objectstorage.eu-frankfurt-1.oraclecloud.com"
• https://YOUR-NAMESPACE.compat.objectstorage.eu-frankfurt-1.oraclecloud.com"
• https://github.com/hashicorp/terraform/issues/34053

In gh:hashicorp/terraform#34053 (https://github.com/hashicorp/terraform/issues/34053), the issue reported: ### Terraform Version ``shell Terraform v1.6.1 on linux_amd64 + provider registry.terraform.io/hashicorp/null v3.2.1 + provider registry.terraform.io/hashicorp/oci v5.9.0 + provider registry.terraform.io/oracle/oci v5.1.0 ### Terraform Configuration Files Config that worked in v1.5.x: tf backend "s3" { bucket = "[BUCKET]" key [your value] region = "eu-frankfurt-1" endpoint = "https://YOUR-ID.compat.objectstorage.eu-frankfurt-1.oraclecloud.com" shared_credentials_file = "PATH/TO/FILE" skip_region_validation = true skip_credentials_validation = true skip_metadata_api_check = true force_pa The verified answer: Working S3-backend config for non-AWS (OCI) object storage on Terraform 1.7.4+: use the endpoints block and the skip flags, with the default credentials file and no env vars: backend "s3" { bucket = "..." key [your value] region = "eu-frankfurt-1" endpoints = { s3 = "https://YOUR-NAMESPACE.compat.objectstorage.eu-frankfurt-1.oraclecloud.com" } skipcredentialsvalidation = true skipmetadataapicheck = true skipregionvalidation = true skiprequestingaccountid = true skips3checksum = true usepathstyle = true }`

Not specified by the original author.

TL;DR

Duplicity decryption failed almost always means the passphrase or key presented at restore does not match the key that encrypted the backup, or the agent and gpg setup picks the wrong keyring. Confirm which key encrypted the set, export the passphrase correctly for unattended runs, and test by decrypting a single volume file manually before retrying the restore.

duplicity "GnuPG error: decryption failed"

Use this when

• Duplicity restore or verify fails with GnuPG error decryption failed.
• The backup was made on another machine or by another user.
• Unattended restores fail while interactive ones prompt and succeed.

Not for this skill when

• The backend cannot be reached at all. Fix transport before cryptography.
• The passphrase is confirmed correct but volumes are corrupt. That is data damage, not key mismatch.

Steps

1. Identify the encrypting key from the backup metadata or the original job configuration and list keys in the current keyring. Verify: the needed key fingerprint is known and present or missing
2. Import the correct private key or set the passphrase environment for the restoring user, confirming the gpg agent configuration allows batch use. Verify: the key appears in the secret key listing for that user
3. Download one small volume from the backup set and decrypt it manually with gpg to prove the key works outside duplicity. Verify: manual decryption succeeds
4. Run duplicity verify on the set, which exercises decryption across volumes without writing restored files. Verify: verify completes or names a specific bad volume
5. Run the full restore with the corrected key setup. Verify: the restore completes and files are readable

Variant phrasings

duplicity decryption failed wrong passphrase

The passphrase-cause phrasing.

duplicity gpg decryption failed restore key

The keyring variant.

duplicity PASSPHRASE restore failed

The environment variable wording.

Compatibility: Duplicity 2 and 3 with GnuPG 2.4, local, S3 and SFTP backends, symmetric passphrase and public key encryption.

Why it happens

Duplicity encrypts each volume with GnuPG before upload, so restore success depends entirely on presenting the same secret later. Keyrings are per user, agents cache passphrases differently for interactive and cron contexts, and a similar-looking passphrase with a trailing space or different encoding fails silently into this generic error.

Edge cases / pitfalls

• Test restores after any key rotation. Rotating without re-encrypting or keeping the old key breaks old sets.
• Store the passphrase or key backup with the backup set documentation, protected separately from the data.
• A manual gpg decrypt that asks for a different key id reveals the set was encrypted to another recipient.

Provenance

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

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

Thread query: duplicity "GnuPG error: decryption failed"

TL;DR: Duplicity decryption failed almost always means the passphrase or key presented at restore does not match the key that encrypted the backup, or the agent and gpg setup picks the wrong keyring. Confirm which key encrypted the set, export the passphrase correctly for unattended runs, and test by decrypting a single volume file manually before retrying the restore.