Bug 795124 - Deja-dup keeps asking for encryption password
Summary: Deja-dup keeps asking for encryption password
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: deja-dup
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Rahul Sundaram
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-19 14:09 UTC by seventhguardian
Modified: 2012-07-28 00:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-24 22:21:21 UTC
Type: ---


Attachments (Terms of Use)

Description seventhguardian 2012-02-19 14:09:44 UTC
Description of problem:

I've been using dejadup to perform regular backups of my home directory. The backups are password encrypted.

Today I noticed that dejadup is stuck in the "Encryption Password Needed" screen. I've entered the correct password, still it won't perform the backup. I suspect it won't restore the existing backups either.


Version-Release number of selected component (if applicable):
deja-dup-20.1-1.fc16
duplicity-0.6.17-1.fc16

Steps to Reproduce:
1. Run $ deja-dup --backup
2. Enter the correct password
  
Actual results:
After some seconds the password prompt will appear again

Expected results:
The backup should start.

Additional info:

The first time I ran deja-dup today, I noticed that the gid/uid for my owned directories on the backup disk were wrong (set to 500:500 instead of renato:renato). The root owned directories were correctly set to root:root. I've corrected my ownership on the affected directories.

Comment 1 seventhguardian 2012-02-24 21:38:34 UTC
I believe I found the problem. Please take note the debug command and the output:

** (deja-dup:12685): DEBUG: DuplicityInstance.vala:196: Running the following duplicity (12700) command: duplicity 'collection-status' '--exclude=/media/Renato2/backups-dejadup' '--exclude=/home/renato/.local/share/Trash' '--exclude=/home/renato/.xsession-errors' '--exclude=/home/renato/.thumbnails' '--exclude=/home/renato/.gvfs' '--exclude=/home/renato/.adobe/Flash_Player/AssetCache' '--exclude=/home/renato/.cache/deja-dup' '--exclude=/home/renato/.cache' '--include=/home/renato' '--exclude=/sys' '--exclude=/proc' '--exclude=/tmp' '--exclude=**' '--gio' 'file:///media/Renato2/backups-dejadup' '--verbosity=9' '--gpg-options=--no-use-agent' '--archive-dir=/home/renato/.cache/deja-dup' '--log-fd=14'

** (deja-dup:12685): DEBUG: DuplicityInstance.vala:568: duplicity (12700) exited with value 0

** (deja-dup:12685): DEBUG: DuplicityInstance.vala:196: Running the following duplicity (12704) command: duplicity '--exclude=/media/Renato2/backups-dejadup' '--exclude=/home/renato/.local/share/Trash' '--exclude=/home/renato/.xsession-errors' '--exclude=/home/renato/.thumbnails' '--exclude=/home/renato/.gvfs' '--exclude=/home/renato/.adobe/Flash_Player/AssetCache' '--exclude=/home/renato/.cache/deja-dup' '--exclude=/home/renato/.cache' '--include=/home/renato' '--exclude=/sys' '--exclude=/proc' '--exclude=/tmp' '--exclude=**' '--dry-run' '--gio' '--volsize=50' '/' 'file:///media/Renato2/backups-dejadup' '--verbosity=9' '--gpg-options=--no-use-agent' '--archive-dir=/home/renato/.cache/deja-dup' '--log-fd=18'

** (deja-dup:12685): DEBUG: DuplicityInstance.vala:571: duplicity (12704) process killed


The first command succeeds ('collection status') succeeds, but the second one doesnt. Running the command myself (removing the "--log-fd" part) I get this:

(...)

GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: bad key
===== End GnuPG log =====

I believe this is a red herring. The duplicity command specifies '/' as the backup directory.

I attempted to run the command again, removing any --exclude that is outside of my home directory, and replacing '/' by '/home/renato'. It worked perfectly.

Just to make sure I had the correct password, I attempted to use an incorrect one, and if failed as expected.

Comment 2 seventhguardian 2012-02-24 21:49:48 UTC
Please disregard my last comment, I was doing a backup to a different directory when it "worked perfectly".

Comment 3 seventhguardian 2012-02-24 22:21:21 UTC
I attempted to do a new test backup/verify using just duplicity (it worked).

I'm assuming this is the (unlikely but possible) case of a lost password. Closing the report.

Comment 4 James 2012-07-28 00:16:47 UTC
I've seen this behavior 3 times on F16/F17. deja-dup runs fine for several weeks then suddenly wants a password but refuses the one I give it. The only workaround I have now is to change the backup path whenever this problem arises.


Note You need to log in before you can comment on or make changes to this bug.