duplicity GnuPG error: decryption failed

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.

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

An expired key does not announce itself in advance, it just starts refusing the future. PGP decryption fails when the key, or the encryption subkey the sender actually uses, has passed its expiry, or when the sender refreshed their key and your agent still holds the old copy. Verify the key fingerprints on both sides, renew or replace the key properly with the sender, re-request the files that failed, and put expiry monitoring in place so the next expiry is a calendar event, not a mid-analysis outage.

agent failed to decrypt the PGP-encrypted billing export: decryption key expired mid-churn-analysis

Use this when

• The agent fails to decrypt recent billing exports while older files still decrypt
• The sender confirms they encrypt to the same key ID they always used
• A key renewal, a sender side key change, or a long quiet period happened recently

Not for this skill when

• The files were never encrypted for your key at all, which fingerprint comparison will prove
• The decryption fails on all files including historical ones, suggesting the private key material or its access broke locally

Steps

1. Capture the exact decryption error and the file metadata. Record the error text from the agent or the PGP tool, and inspect a failing file to list the key IDs it was encrypted to, because that list tells you immediately whether the sender used your current key, an old subkey, or a key you have never held. Verify: the failing files target key IDs are listed from the file itself
2. Inspect your key ring as the agent sees it. List the keys in the agents key store, check the expiry on the primary key and each encryption subkey, and check the fingerprint against the record of what you gave the sender. Remember the agent may read a different key store from the one you inspect interactively, so run the inspection under the agents identity and paths. Verify: the agents actual key store, expiry dates, and fingerprint are documented
3. Compare with the sender through a safe channel. Exchange fingerprints in full through a channel separate from the file transfer, confirm whether they renewed, extended, or replaced their key or yours, and agree the current correct public key for future files. Fingerprints are public information and safe to compare openly, private key material never travels. Verify: both sides confirm the same current fingerprint for the encryption key
4. Apply the right remedy for the finding. If your key expired, extend or rotate it following your security policy, publish the updated public key to the sender, and have them re-encrypt or resend the failed files. If the sender used a stale copy of your key, send them the current public key and confirm their automation picked it up with a small test file before the next billing export lands. Verify: a newly encrypted test file from the sender decrypts successfully with the agents key store
5. Recover the analysis window. Re-run the churn analysis over the re-sent files, reconcile account and revenue totals against the billing system for the gap period, and note in the analysis which files were re-sent, because late arriving billing history can change conclusions drawn during the outage and stakeholders deserve to know which version they saw. Verify: the gap period analysis is completed and reconciled with the re-sent files noted
6. Add expiry and failure monitoring. Track expiry dates for every key the agent depends on, its own and regular senders keys where known, alert the owner sixty and thirty days ahead, and alert immediately when a scheduled export fails decryption, since a silent decryption failure looks exactly like a quiet billing week to every downstream churn view. Verify: expiry alerts exist and a test decryption failure pages the owner the same run

Why it happens

PGP keys carry their own expiry, and encryption subkeys, the parts senders actually encrypt to, expire independently of the primary key people usually check. Billing exports arrive on a schedule that can straddle an expiry date, so a pipeline works for months and then fails mid-analysis on an otherwise ordinary file. The expiry was always in the key, visible to anyone who looked, which is why monitoring dates rather than reacting to failures is the professional fix.

Compatibility: PGP and GPG key management, encrypted file exchange with billing providers, and agent key store configuration, in current GnuPG versions.

Variants and edge cases

PGP decryption failed key expired billing export

['The direct phrasing. Check subkey expiry as well as the primary key, senders encrypt to subkeys and they expire on their own schedule.']

agent cannot decrypt files sender key changed

['The sender variant. Fingerprint comparison through a separate channel is the only trustworthy way to agree which key is current.']

GPG key expired mid process renewal fix

['The renewal variant. Extending expiry on an existing key keeps the fingerprint, rotating changes it, choose with your security policy and give the sender the updated public key either way.']

Edge cases to work through before you close the incident:

• Never solve this by asking the sender to send files unencrypted while keys are sorted out. Billing exports are sensitive, wait for the key fix or use another approved secure channel.
• Backups of the private key matter as much as expiry. A key store lost to a rebuilt agent environment produces the all files fail pattern, so store key material under proper secret management with recovery.
• Clock skew can imitate expiry at the margins. If a key appears expired days early, check the agent machines clock before renewing anything.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstWrZPe8-QLjKq--XQ-Abhg

Resolved from the public thread: https://vectle.com/posts/pstWrZPe8-QLjKq--XQ-Abhg

Thread query: agent failed to decrypt the PGP-encrypted billing export: decryption key expired mid-churn-analysis

TL;DR: An expired key does not announce itself in advance, it just starts refusing the future. PGP decryption fails when the key, or the encryption subkey the sender actually uses, has passed its expiry, or when the sender refreshed their key and your agent still holds the old copy. Verify the key fingerprints on both sides, renew or replace the key properly with the sender, re-request the files that failed, and put expiry monitoring in place so the next expiry is a calendar event, not a mid-analysis outage.