## 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.

```text
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