Hi
I set up a new Ubuntu 22.04 server
Everything went well thanks to the contact/calendar manual fix
When I want to restore my MIAB data, I got this error:
root@srv:/opt# export PASSPHRASE=$(cat secret_key.txt)
root@srv:/opt# sudo -E duplicity restore --force file:///opt/encrypted /opt/xxx/
Restore '/opt/xxx' is not empty or is current_dir.
Will not overwrite.
Do you know how to resolve it please?
Thanks
FYI
root@srv:~# duplicity --version
duplicity 3.2.0.2 August 22, 2026
Hi
What happens if you run the command from /tmp ?
Cheers
that error is duplicity being picky, not the backup being dead.
Restore ‘/opt/xxx’ is not empty or is current_dir means the target already has stuff in it (or you were standing in that folder when you ran it). --force doesnt always override that on duplicity 3.x.
mkdir /opt/restore-empty
cd /tmp
sudo -E duplicity restore file:///opt/encrypted /opt/restore-empty
dont restore straight into /home/user-data on a half-installed box. restore to an empty dir then copy, or wipe the target first if you really want to overwrite.
also if /opt/xxx is just leftover from running it while cwd was that folder, thats the current_dir half of the message.
Hi
I tried to extract to another new folder:
export PASSPHRASE=$(cat /opt/secret_key.txt)
sudo -E duplicity restore --force file:///opt/encrypted /opt/NEW
Synchronizing remote metadata to local cache…
Copying duplicity-full-signatures.20260831T2xxx45Z.sigtar.gpg to local cache.
Duplicity backup complete.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
Thread exception: Invalid passphrase
===== End GnuPG log =====
So it seems passphrase is wrong 
But I took it from secret_key.txt in MIAB folder
As I still have access to the original server, do you now how to reset the encrypted file and perform a new backup with new key file please?
I’m stuck in the same situation. Cannot restore from the latest backup with duplicity 3.2.0.2
I have also tried to start a new back-up from scratch (by moving/deleting /home/user-data/backup/encrypted/ folder), but it didn’t resolve it.
I’m running this restore directly on the mail server itself, so the secret_key.txt is the same file used to make the backup. /home/ubuntu/test_dir/ is empty before running this test as well.
ubuntu@mail:~$ duplicity --version
duplicity 3.2.0.2 August 22, 2026
ubuntu@mail:~$ export PASSPHRASE=$(cat /home/user-data/backup/secret_key.txt)
ubuntu@mail:~$ sudo -E duplicity restore --force file:///home/user-data/backup/encrypted/ /home/ubuntu/test_dir/ --verbosity debug
GPG binary is /usr/bin/gpg, version 2.2.27
Using archive dir: /home/ubuntu/.cache/duplicity/fd9ab703e6cef97859887d4e7fcb77a5
Using backup name: fd9ab703e6cef97859887d4e7fcb77a5
================================================================================
duplicity 3.2.0.2
Args: /usr/bin/duplicity restore --force file:///home/user-data/backup/encrypted/ /home/ubuntu/test_dir/ --verbosity debug
Linux mail.mydomain.com 6.8.0-1060-oracle #63~22.04.1-Ubuntu SMP Mon Aug 10 15:20:43 UTC 2026 x86_64 x86_64
/usr/bin/python3 3.10.12 (main, Jul 15 2026, 23:40:17) [GCC 11.4.0]
================================================================================
Acquiring lockfile /home/ubuntu/.cache/duplicity/fd9ab703e6cef97859887d4e7fcb77a5/lockfile
Using temporary directory /tmp/duplicity-ca_9ewtd-tempdir
Registering (mkstemp) temporary file /tmp/duplicity-ca_9ewtd-tempdir/mkstemp-fcpo7w8n-1
Temp has 38,838,681,600 available, backup will use approx 482,344,960.
1 file(s) exist in cache
7 file(s) exists on backend
Extracting backup chains from list of files: ['duplicity-full.20260905T231656Z.manifest.gpg', 'duplicity-full-signatures.20260905T231656Z.sigtar.gpg', 'duplicity-full.20260905T231656Z.vol2.difftar.gpg', 'duplicity-inc.20260905T231656Z.to.20260906T052918Z.vol1.difftar.gpg', 'duplicity-inc.20260905T231656Z.to.20260906T052918Z.manifest.gpg', 'duplicity-full.20260905T231656Z.vol1.difftar.gpg', 'duplicity-new-signatures.20260905T231656Z.to.20260906T052918Z.sigtar.gpg']
File duplicity-full.20260905T231656Z.manifest.gpg is not part of a known set; creating new set
File duplicity-full-signatures.20260905T231656Z.sigtar.gpg is not part of a known set; creating new set
Ignoring file (rejected by backup set) 'duplicity-full-signatures.20260905T231656Z.sigtar.gpg'
File duplicity-full.20260905T231656Z.vol2.difftar.gpg is part of known set
File duplicity-inc.20260905T231656Z.to.20260906T052918Z.vol1.difftar.gpg is not part of a known set; creating new set
File duplicity-inc.20260905T231656Z.to.20260906T052918Z.manifest.gpg is part of known set
File duplicity-full.20260905T231656Z.vol1.difftar.gpg is part of known set
File duplicity-new-signatures.20260905T231656Z.to.20260906T052918Z.sigtar.gpg is not part of a known set; creating new set
Ignoring file (rejected by backup set) 'duplicity-new-signatures.20260905T231656Z.to.20260906T052918Z.sigtar.gpg'
Found backup chain [Sat Sep 5 19:16:56 2026]-[Sat Sep 5 19:16:56 2026]
Added incremental Backupset (start_time: Sat Sep 5 19:16:56 2026 / end_time: Sun Sep 6 01:29:18 2026)
Added set Sun Sep 6 01:29:18 2026 to pre-existing chain [Sat Sep 5 19:16:56 2026]-[Sun Sep 6 01:29:18 2026]
Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20260905T231656Z.sigtar.gpg to local cache.
Registering (mktemp) temporary file /tmp/duplicity-ca_9ewtd-tempdir/mktemp-51focltz-2
GPG decryption thread failed: Invalid passphrase
Registering (mktemp) temporary file /tmp/duplicity-ca_9ewtd-tempdir/mktemp-6qdwe83p-3
Duplicity backup complete.
Removing still remembered temporary file /tmp/duplicity-ca_9ewtd-tempdir/mkstemp-fcpo7w8n-1
Removing still remembered temporary file /tmp/duplicity-ca_9ewtd-tempdir/mktemp-51focltz-2
Removing still remembered temporary file /tmp/duplicity-ca_9ewtd-tempdir/mktemp-6qdwe83p-3
GPG error detail: Traceback (innermost last):
File "/usr/lib/python3/dist-packages/duplicity/__main__.py", line 79, in dup_run
with_tempdir(main)
File "/usr/lib/python3/dist-packages/duplicity/__main__.py", line 55, in with_tempdir
fn()
File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1701, in main
do_backup(action)
File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1730, in do_backup
sync_archive(col_stats)
File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1480, in sync_archive
copy_to_local(fn)
File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1424, in copy_to_local
gpg.GzipWriteFile(src_iter, tdp.name, size=sys.maxsize)
File "/usr/lib/python3/dist-packages/duplicity/gpg.py", line 608, in GzipWriteFile
new_block = next(block_iter)
File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1398, in __next__
self.fileobj.close()
File "/usr/lib/python3/dist-packages/duplicity/dup_temp.py", line 266, in close
assert not self.fileobj.close(), "self.fileobj failed to close"
File "/usr/lib/python3/dist-packages/duplicity/gpg.py", line 441, in close
self.gpg_failed()
File "/usr/lib/python3/dist-packages/duplicity/gpg.py", line 413, in gpg_failed
raise GPGError(msg)
duplicity.gpg.GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
Thread exception: Invalid passphrase
===== End GnuPG log =====
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
Thread exception: Invalid passphrase
===== End GnuPG log =====
update:
No it’s not a permission error as far as I can tell. I added the following to my test after the export. It does indeed show the expected contents (first ten characters from the secret_key.txt file) without any permission issues:
echo ${PASSPHRASE:0:10}
This is not a read rights issue? I.e. does the output of echo $PASSPHRASE indeed reflect the content of the file?
Yes
cat $PASSPHRASE shows the content