Remote Access seems to have screwed up my Duplicati Installation

Support
1

I run Duplicati on Windows 10 64 bit. I run it in service mode.

I turned on “Allow Remote Access” in Duplicati. When I went to Duplicati, it showed my last Backup was back in October, not the day before like I had setup.

October was when the Windows Fall Creators update nuked all my Duplicati settings (in service mode, Duplicati stores the settings in a folder that Windows wipes out on major updates). I managed to get everything running again at the time until now when I turned on “Allow Remote Access”

Duplicati started using settings stored in the folder that they were stored in before I started running in service mode. I don’t know why turning on remote access would do this, but that is the only Duplicati setting I have changed recently.

I stopped the service, and moved the files to the location that Duplicati is using now (C:\Windows\system32\config\systemprofile\AppData\Local\Duplicati\QSNQNCEYAT.sqlite). Upon restarting Duplicati, I tried to run a backup to Backblaze B2. But now I keep getting error messages along the lines of:

“Remote file referenced as duplicati-b998bd710bb6241bdbdb3d5ce80e939bb.dblock.zip.aes, but not found in list, registering a missing remote file”

I ran a database repair, that didn’t stop the errors from happening. I did a Recreate (delete and repair), and now I am seeing less errors, but I am still getting the same errors.

I’ve tried to turn off “Allow remote access (requires restart)”. But the setting doesn’t stick. I assumed the restart meant the service, so I saved the setting and restarted the service. When I go back into settings, Allow Remote Access is still checked. I tried again, this time restarting the computer instead of just the service. Again, the Allow Remote Access setting is still checked.

Anyone know how I can fix all of this?

2

I decided to completely uninstall Duplicati (but first backing up my configuration). I also deleted the local database

On reinstall (and importing my config), I get the same errors. Recreating the database doesn’t help either.

I created a new backup routine, which will backup to Backblaze B2 in a different folder. Running it now. If this is successful, I’m just going to delete all of the old backup data.

I run Duplicati as well as Arq Backup (a backup program to my backup program, if you will). So I have copies of everything backed up via Arq just for situations like this.

I’d still like to know why this happened though. I found other people on the forum with the same issue going back a couple of years and it doesn’t seem like there is a fix.

3

What version of Duplicat where you running and what version did you re-install?

4

I was running 2.0.2.1, and that was the version I reinstalled.

The new backup is currently running with no issues.

5

That’s good to hear at least, did you enable remote access on the re-install as well?

The issue with the Windows Fall Creator update is known - it’s because Microsoft renames the pre-update \Windows folder to \Windows.old, does a fresh install into \Windows, then copies over from the \Windows.old foldre whatever settings & such THAT IT KNOWS ABOUT. Unfortunately, Duplicati isn’t one of those. (Note that you can manually copy that stuff over if you need to).

Now why enabling remote access would have any effect on that I don’t have a clue. What it feels like is somehow you’re getting multiple copies of Duplicati running at different times. (That might explain the “Allow remote access” change not sticking.)

When you say you found other people with the same issue did you mean the “Allow remote access” thing or just “Remote file referenced as …”

@kenkendk, in the code that generates the error mentioned above, it looks like we’re logging an error about a missing file, but then running .RegisterRemoteVolume() with RemoteVolumeState.Verified…is that logically correct?

6

I didn’t enable remote access on the new install. I’m using a reverse proxy (Caddy) instead, and that essentially fools the Duplicati web interface into thinking it’s a “local” connection. So I am able to access it remotely this way. Works quite well.

I’m using Duplicati in the standard mode now (instead of service mode). Hopefully this will prevent multiple instances of Duplicati starting up and putting database files into different folders. I’m guessing when I moved the database files to the location that Duplicati was looking for them in, I must have messed it up somehow.

When I said I found other people with the same issue, I was referring to the “Remote file referenced as …” error. Sorry for not being clear on that. I couldn’t find anyone else who seemed to have the same problem with remote access that I did.

7

Nice solution, and probably more secure than allowing remote connections. :slight_smile:

Please let us know if the new backup works correctly for you.

8

I originally enabled remote connections because I figured I would need it to access Duplicati from the outside (even via a reverse proxy). Then I though “hmm, but if it’s a reverse proxy, it wouldn’t know…”

I was originally trying Nginx, but using Let’s Encrypt was going to be a bit of a chore for SSL. My ISP blocks port 80 so I can’t use the usual automated Let’s Encrypt configuration. Caddy actually has built in Let’s Encrypt support for DNS challenges to various DNS providers, and it configures and renews the SSL certificate automatically. Pretty slick!

The new backup seems to have worked fine, it reran on it’s schedule today with no errors. Duplicati has been working great for the last few months on my system (after getting the Fall Creators Update mess fixed). It just happened to break when I tried to turn on remote access so I assumed the two were related in some way (seems like a big coincidence if they aren’t related).

9

Just because I don’t see how the code could do what you experienced doesn’t mean it didn’t…but since you’ve got things working I’m inclined to leave things be and just remember this topic if somebody else reports the same issue. :slight_smile: