Restore Problem: Failed to retrieve the config file: cipher: message authentication failed

Support
#1

Hello, I have a serious restore problem with duplicacy.

This is what works as expected:
I configured a new encrypted storage “N” (with the same password “P” as all my other storages).
I configured a new backup “N”. Then I did a backup.
I tested the restore with my duplicacy-web (saspus) docker on unraid and it worked as expected.
To test the worst case, I installed duplicacy web (duplicacy_web_linux_x64_1.6.3) on my laptop to test the restore again:
I added the new storage “N” (see above) and entered the same storage name “N” an the same password “P”.
Then I tested the restore and it worked as expected.

Finally I also wanted to test the restore of my other backups “A,B,C,D” I configured 2 years ago that are in other storages “S,T”. The restore worked as expected on my duplicacy-web (saspus) docker installation.

This is what did NOT work:
I cannot restore my other backups “A,B,C,D” I configured 2 years ago that are in other storages “S,T” from my laptop.

As above, I added an existing storage “S” and entered the same storage name “S” an the same password “P” (I always use the same password on all the storages for encryption).
When clicking “Add” following message appears:
“Failed to initialize the storage at /mnt/unraid-nfs/unraid_UD_Backup6TB/Backup/Duplicacy/Lokal-02-copy2cloud: Failed to download the configuration file from the storage: Failed to retrieve the config file: cipher: message authentication failed”

I tried the following in my saspus duplicacy-web docker and on my laptop:
Under “Settings > Passwords > Encryption Password” I entered my old encryption password “P” an the same (!) twice as “new” password. This worked, so I’m sure the password is correct!

Another thing I tried:
I copied the “config” file from the newly created storage “N” to one of my older storage “S”.
After this I was able to add the existing storage “S” using the same storage name “S” an the same password “P”!!
BUT when I tried the restore following message appears after choosing the Backup ID:
“Failed to list revisions for backup ‘Media’ in the storage Lokal-01: Failed to decrypt the file snapshots/Media/639: cipher: message authentication failed”

So now I’m lost and don’t know what I ca do.
I just know that in a worst case scenario I am NOT able to restore the backups/storages I configured 2 years ago…
One thing to note: I am 100% sure the encryption password is correct!

Threads I found but that didn’t help me:
newbie-i-cant-access-my-duplicacy-backups-failed-to-retrieve-the-config-file-cipher-message-authentication-failed
failed-to-retrieve-the-config-file-cipher-message-authentication-failed
encryption-password

#2

There are only two possibilities:

  • You misremember your password (caps lock, keyboard, layout, etc.)
  • Config file is corrupted

In either case you cannot restore your data unless you guess what other password you could have used, or you saved config file elsewhere, respectively.

These passwords are not related to storage encryption. It all proves that you remember the password you’ve used few minutes ago. It does not tell us anything abour your ABCD storages encryption password.

Bad idea. Config file contains cryptographic keys that are used to encrypt data in chunks. You need these exact keys to decrypt your data. The storage encryption password you specify is used to encrypt the contents of the config file to protect those keys. When you copied over config file from another storage of course you are able to decrypt the keys with the password they were just encrypted with. But this won’t help you decrypt the data, because the data was encrypted with different keys, the ones in the storage config file you have overwritten.

Hope you saved a copy. Revert it back.

If this was to be believed, this leaves us with one other possibility, that your config file got corrupted due to e.g. media failure. Unless you have a copy – you cannot restore your data, it’s completely gone.

I therefore recommend downgrade your degree of certainty. What media was the dataset on? Redundant array with check-summing?

Nothing is ever 100% in this universe.

I recommend follow the advice in the threads you linked and try to guess the password you might have used. Maybe you added a suffix. Maybe caps lock was on. Maybe your keyboard was switched to different language. Etc.

#3

How exactly did you set this up 2 years ago? Did you initialise the storage with the CLI or the Web Edition?

The distinction could be important if, at some point, you specified passwords using the preferences json file - as it has to be escaped properly, and may be different to what’s pasted. Does the password consist of special chars (backslash etc.)?

You need to undo this pronto, and put back the original config file on “S”. Not only are they not compatible, it doesn’t sound like you initialised “N” by making it a copy-compatible with “S”.

It sounds like you’re just testing restores and still have backups setup and running, and it’s working because the storage password is stored in the keyring.

There might be a way to recover that info directly (though it can be a bit involved)…

Another method might be to add a new storage on the same computers that have “S” and “T” already setup, and make this new storage copy-compatible with them. This setup won’t prompt you for the password, as it’s stored in the keyring, so you could theoretically do a copy job to make a copy of all your old backups, but into a new storage where you know the password works (because you’re copy-pasting it from a password manager, and not typting it, right? :wink: ). You’d need spare disk space, but at least you can access old backups while you have a system that remembers the password internally.

#4

I never used the CLI for those storages on my unraid server. I used the web-edition from the beginning.
I did some tests with the CLI on my old client but I used other storages.

It’s already undone! (Before I did this I made backups of all the files to be able to recover…)

Yes, as described above everything (backup/retore) is working fine on the server.

How?

Ok, I’ll try this… (mybe I have to free some disk space)

no… I’m typing it because I know it (but yes, it’s in a passwordmanager)

#5

I believe it’s corrupted because I’m (ok) 99% sure I never changed the password and I remember it…

  • I’ll once again test various passwords I use(d)
  • I’ll search for a config file backup in my data, but I don’t think I have one (I made a backup now!)

ok…I thought so…

Yes sure, I saved a copy and stopped the duplicacy-web docker while testing on the laptop.
I already reverted the changes and my duplicacy-web docker works fine as before.

I downgraded it to 99% :laughing:
Nope, no check-summing (single xfs formatted drive)

1 Like
#6

I do remember investigating dumping details from Windows credential store, in conjunction with Duplicacy, but that was a while ago and I can’t find the original posts that led me there. Besides, you’ll be Linux-based, and that won’t help you. However, apparently it should be possible…

Don’t think there’s any info on the forum on how to utilise that, however. Maybe @gchen can assist?

It’s a shame the add storage setup in the Web Edition doesn’t let you create a -bit-identical copy-compatible storage, coz then you could make a storage with a compatible config file without having to copy any chunks. I guess that’s probably for the best, security-wise.

#7

If the password in question is indeed stored in the keyring, the contents can be decrypted and dumped out with lssecret -s. As lssecret is not a standard tool in most installations, it will need to be installed first.

Also, working with keyring can be a pain, just saying.

1 Like
#8

@florian you’ll just need to pass -print-credentials to the web GUI executable to print out the storage password. This storage password is different from the master encryption password used by the web GUI (the one you entered through Settings > Passwords > Encryption Password).

For an unraid docker here are steps to show the storage password with -print-credentials:

  • Open the docker console (when the docker is running), run vi /usr/local/bin/launch.sh
  • Change the last line to exec duplicacy_web -print-credentials
  • Restart the docker
  • Now go to the web GUI and open the restore page, select the storage
  • You should see in the docker log (on the unraid docker page) a line like: Env: DUPLICACY_PASSWORD=xxxx
  • xxxx is your storage password
2 Likes
#9

I read about this parameter before, but didn’t try to use it…
Thank you very much for mentioning it here in the thread!

And you see me very surprised about myself, because it was indeed another password I used here.
What a shame that I didn’t document this!
I downgraded once again my degree of certainty.
Ironically, it would have been one of the next passwords to test…

#10

That pesky one percent strikes again :wink:

Glad it was resolved :).

Personally I don’t even attempt to memorize or create passwords anymore. I have over 600 various credentials/accounts/keys/passcodes in my password manager. There is absolutely no way for me or for most people for that matter to remember so many nonsensical strings of text. I don’t know any of my passwords, except the one to unlock the password manager. Which is printed on a cardboard, laminated, and stored away. Because I fully expect myself to wake up one day not remembering it inspite of having typed it in weekly for the past decade. :slight_smile: can’t wait for the passwords to become a thing of the past.

1 Like
#11

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.