Failed Encrypted Restore on Win10 and Duplicati 2.0

Support
1

I seem to be having issues restoring with Duplicati. I get a message that says that my files were restored and a whole bunch or red warnings about invalid password or corrupted data. I’ve done this over and over with different sets of sample data trying to figure out what is going on. Duplicati is reinstating my folder directory structure just not the actual files therein. I have created the exact same backups without encryption and been able to do a proper restore.

I need the encryption part to work, it’s nice that I can create and restore non-encrypted archives but I should be able to do the same thing with AES-256 enabled and everything should work out just fine…

I’ve tried a few different ways to restore encrypted backups and none seem to work. Here’s one method that I’ve used:

1269×643

Once I click the restore files link like in the pic above I get presented with a plain view of my folders, filenames and a 2 step process to restore the files. Seems all too easy, although I feel like I shouldn’t be able to see anything inside the archive until after I enter my passphrase, which I’m not asked for.

So at this point I continue onto the next screen and leave the defaults of restoring to original location and overwriting existing files. Then click restore. At no point during this restore process am I asked to give my AES passphrase.

Then a couple of minutes later, I’m informed files and folders are successfully restored. They are not. My directory structure and folders are restored but none of the actual files inside them. Here’s a sample of the error I’m getting:

1151×600

I am at a loss here. I have tried and tried to restore a small sampling of my data just to make sure I understand exactly how all this works. I don’t feel as though I am doing anything wrong, but I must be since it’s not working.

The most surprising thing to note here is the 2 step process without having to enter passphrase.

I did try this method too:

1280×479

This attempt I am presented with a 4 step process, not the 2 step process like above, I feel like both methods should probably be the same. I test my connection with success for the path to my backup location. So, moving on. Yes, now we’re talking. Duplicati is asking for my passphrase. Things seem like we’re all good. Entering my passphrase exposes the contents of my archive. All seems good and I check off my files to restore and proceed to the next/final step and leave the defaults in place. Basically, restore to the original location and overwrite existing. This attempt still fails, I get the same results as my first attempt.

What am I doing wrong? I really want this to work perfectly, as Duplicati seems to be just the right tool for my needs. Simple, on-schedule, local backups that are encrypted. I seem to be able to generate the backups on a nifty schedule but I can’t for the life of me restore them. That’s a big problem and one that I hope is an easy fix. What am I missing here?

Thank you kindly for your help.

2

After many trials and so forth I got it working! I can now create and restore AES encrypted backups with Duplicati.

All of my first attempts were using Google Chrome Browser and having Lastpass and Google store passwords/autofill etc. I read on this forum disabling those autofills fixed their problems. I disabled those features in Chrome and still no go.

I opened Duplicati in Microsoft Edge and made sure those features were shut down, I never use Edge so it’s pretty virgin as far as any collected data for input fields etc.

Well, low and behold, Duplicati restored my various encrypted backups with ease and with proper expectation of results!

Now I know that I should probably plan on using Edge or other browser pretty much exclusively with Duplicati to avoid having these issues. That was super frustrating.

3

Welcome to the forum @wrems77

I think Edge can do the same thing, but you can test and see. You’ve probably seen some notes on this elsewhere, but one common problem is that the web UI access password gets saved for convenience, however the password saver then autofills it into improper places, because the URLs look too similar…

If there was actually an intent to have autofill be a convenience, you could stop by this issue to say how:

Password saver may autofill too many places, getting --auth-password is not supported #4102

If you happen to be a web developer, your input is even more needed, because the solutions look clunky.

One workaround is to maintain a tight limit on what your browser or password keeper can autofill, so this might mean declining some offers to save. If you let it save, make sure it doesn’t get into the wrong spot. Duplicati’s HTML usage tends to have lots of URLs that look similar except for the anchor (string after #).

http://127.0.0.1:8200/ngax/index.html#/edit/2

might just be known to the autofill as the URL part ending in index.html, so it can’t tell which backup it got.
I’m somewhat hard pressed to think of any password that should get autofill besides GUI login, but inputs from people who use saved password autofill (I don’t) would be helpful in figuring out how hard a kill to try.

EDIT:

The password is saved. It has to be, otherwise unattended backups wouldn’t be possible. I guess there’s some risk of an unattended system giving access to backup, but a snoop has access to system directly.

Access to user interface password is the one I mentioned earlier, to keep others out of UI if that’s wanted.