Déjà Dup doesn't save backups anymore - don't stop asking me for the encryption password

Bug #1812912 reported by Achim Hinke on 2019-01-22
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Déjà Dup

Bug Description

I was making backups to local hdd. The last successful backup was made in december 6 2018. On a weekly basis Deja Dup tries to make a backup as configured, but fails to do so. It prompts password for encryption, then duplicity process is running for several minutes, while reading disk extensively and consuming cpu ressources. After that it prompts password again, and no backup is made in target directory. Entering password and running backup again doesn't help either.

I've tried to reinstall deja-dup, but failed, because after installing again backup location and settings remained the same as before uninstalling.
This problem occured after the upgrade from 16.04 LTS to 18.04 LTS.

1. distribution of Linux:

Ubuntu 18.04.1 LTS

2. The version of deja-dup and duplicity:

deja-dup 37.1-2fakesync1
duplicity 0.7.17-0ubuntu1

3. The file /tmp/deja-dup.gsettings:

org.gnome.DejaDup last-restore ''
org.gnome.DejaDup periodic false
org.gnome.DejaDup periodic-period 7
org.gnome.DejaDup full-backup-period 90
org.gnome.DejaDup backend 'local'
org.gnome.DejaDup last-run '2018-12-06T18:15:42.789529Z'
org.gnome.DejaDup nag-check 'disabled'
org.gnome.DejaDup prompt-check '2015-12-05T15:00:24.595427Z'
org.gnome.DejaDup root-prompt true
org.gnome.DejaDup include-list ['/home/erv']
org.gnome.DejaDup exclude-list ['/home/erv/.local/share/Trash', '/home/erv/Downloads', '/home/erv/erv_sync', '/home/erv/Downloads']
org.gnome.DejaDup last-backup '2018-12-06T18:15:42.789529Z'
org.gnome.DejaDup allow-metered false
org.gnome.DejaDup delete-after 182
org.gnome.DejaDup.Rackspace username ''
org.gnome.DejaDup.Rackspace container 'cosmos'
org.gnome.DejaDup.S3 id ''
org.gnome.DejaDup.S3 bucket ''
org.gnome.DejaDup.S3 folder 'cosmos'
org.gnome.DejaDup.OpenStack authurl ''
org.gnome.DejaDup.OpenStack tenant ''
org.gnome.DejaDup.OpenStack username ''
org.gnome.DejaDup.OpenStack container 'cosmos'
org.gnome.DejaDup.GCS id ''
org.gnome.DejaDup.GCS bucket ''
org.gnome.DejaDup.GCS folder 'cosmos'
org.gnome.DejaDup.Local folder '/data/backup'
org.gnome.DejaDup.Remote uri ''
org.gnome.DejaDup.Remote folder 'cosmos'
org.gnome.DejaDup.Drive uuid 'ECD42598D4256654'
org.gnome.DejaDup.Drive icon '. GThemedIcon drive-harddisk-usb drive-harddisk drive'
org.gnome.DejaDup.Drive folder 'Backup-Erv'
org.gnome.DejaDup.Drive name 'erv-storage'
org.gnome.DejaDup.GOA id ''
org.gnome.DejaDup.GOA folder 'cosmos'
org.gnome.DejaDup.GOA type ''
org.gnome.DejaDup.File short-name 'erv-storage'
org.gnome.DejaDup.File type 'normal'
org.gnome.DejaDup.File migrated true
org.gnome.DejaDup.File name 'Freecom Hard Drive XS: erv-storage'
org.gnome.DejaDup.File path 'file:///data/backup'
org.gnome.DejaDup.File uuid 'ECD42598D4256654'
org.gnome.DejaDup.File icon '. GThemedIcon drive-harddisk-usb drive-harddisk drive'
org.gnome.DejaDup.File relpath b'Backup-Erv'

4. The file /tmp/deja-dup.log after running the line below and replicating the problem:
    DEJA_DUP_DEBUG=1 deja-dup --backup | tail -n 1000 > /tmp/deja-dup.log:
(deja-dup read in the files for the backup, than I put in the password for encryption at the prompt, after this it starts reading again ...)

At the end of the log it says (translated from German): "Encryption failed: incorrect session keys"
DUPLICITY: . GPGError: GPG Failed, see log below:
DUPLICITY: . ===== Begin GnuPG log =====
DUPLICITY: . gpg: WARNUNG: "--no-use-agent" ist eine veraltete Option - sie hat keine Wirkung.
DUPLICITY: . gpg: AES verschlüsselte Daten
DUPLICITY: . gpg: Verschlüsselt mit einer Passphrase
DUPLICITY: . gpg: Entschlüsselung fehlgeschlagen: Fehlerhafte Sitzungsschlüssel
DUPLICITY: . ===== End GnuPG log =====

Complete log file is attached.

Achim Hinke (erv-m) wrote :
description: updated
Michael Terry (mterry) wrote :

OK. That gpg error translates to “decryption failed: bad session key” which a few other bugs reference. That’s the message you get when the password is wrong.

But you and others swear that they get that message for the right password.

Hmm. I don’t know how to reproduce unfortunately. I can look again at the password handling code, but I’m not sure I’ll be able to find the issue without being able to reproduce it.

Achim Hinke (erv-m) wrote :

Thanks Michael.
Well before the problem occured, I wasn't asked for the password on every backup task.
Could this possibly relate with the change of the desktop (unity in 16.04 to Gnome in 18.04)?
stumped ...

Michael Terry (mterry) wrote :

I think this was due to a few bugs working in concert, causing situations where your backup chain was encrypted with two different passphrases. See the following wiki page to see if you are affected and how to recover.

I will optimistically close this as “fixed in 39.1” but please reopen if you believe this to be caused by something else.

Changed in deja-dup:
status: New → Fix Released
Achim Hinke (erv-m) wrote :

Great, it works with version 39.1 and a fresh backup in a new folder!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions