System is Windows 10 running Duplicati 2.0.7.103_canary_2024-04-19. Duplicati runs as a system service on localhost:8200.
I downloaded and ran the duplicati-2.0.9.108_canary_2024-10-03-win-x64-gui.msi install file. If I launch Duplicati from the system tray, it comes up on localhost:8300 running the correct version. But as I run Duplicati as a system service (so it can back up everything) there are no backups configured. When I change to localhost:8200, Duplicati is there and has my configured backup - but it is still running 2.0.7.103_canary_2024-04-19.
That indicates that the Duplicati instance running as a service is not finding the same database as when running the tray icon.
This is usually caused by the service running as another user, meaning it has another folder under C:\Users.
The most secure way would be to move the database(s) from your account folder into the folder used by the service. This ensures that less privileged users cannot access the database.
You can find the database from the current account by pressing WIN+R and typing:
%localappdata%\Duplicati
Then press enter.
You can poke around and see where the other database is located, or you can edit the service and supply --server-datafolder=<path-to-folder> and force a specific location.
Beware that running Duplicati as a service under a more privileged account is also running a webserver with elevated privileges. Make sure you have sufficiently protected the machine to avoid compromise through the webserver.
If this was true historically, then you would have had to manually start the service (or reboot).
makes me wonder if you restarted this time. I think the installer could be more helpful about it.
After you get service onto the new Duplicati, the next hurdle may be setting password for that.
Did it do a popup with “First run setup” in title, leading you through setting chosen password?
This has long been there, but it could be skipped before. Now it’s required for added security.
How do you like to get to service? Duplicati.GUI.TrayIcon.exe--no-hosted-server is good, however potentially fragile during upgrades which might reinstall shortcut without any options.
--no-hosted-server
Set this option to not spawn a local service, use if the TrayIcon should connect to a running service.
Yes - sorry if this wasn’t clear in my original post. It is running as a system service under the admin account so it doesn’t have access issues.
The issue isn’t finding the database, the issue is that this instance of Duplicati is not running the upgraded version. On another system (a Windows 10 VM) running with the same configuration the admin service was upgraded along with the user service. The only difference is that I believe that VM was upgraded using Canary from September (and then later upgraded to the October release).
Mostly correct - I had to create a service so that it automatically starts at reboot.
Process was stop the service, stop using the systray, install, reboot.
Having encountered the password issue on my prior Windows 10 VM, I set the password on the “service” instance prior to doing the upgrade. So as far as I am aware I did the same process on both systems(1), but with different outcomes. (1 = I believe the VM was upgraded using the September Canary release)
Password was set before the upgrade.
I get to the “service” instance using localhost:8200 from Firefox. I don’t use the “user” instance from the systray - it has no configured backups, so it just sits in the background doing nothing.
That should get rid of old processes. What path does the service run?
can point to a Duplicati update if Duplicati.WindowsService.exe ran in an updated Duplicati.
Updates from the old autoupdater scheme are not removed by new install, and can still run.
I believe it is running out of an “update” directory - I will check and confirm. But the same should be true for the VM where the update worked without trouble. I will check the VM the next time it is up to see what it says for comparison.
The “service” instance “Path to executable” is “C:\ProgramData\Duplicati\updates\2.0.5.111\Duplicati.WindowsService.exe” “–server-datafolder=C:\ProgramData\Duplicati\Data”
The “update” directory feature in Duplicati was a bit unstable. In several cases, “something” was modifying the update folder, causing unexpected downgrades.
The 2.0.9.x line no longer has the update folder, so upgrades are now normal re-installs as other software does it.
That one probably looked around for the latest old-style update it could find, and ran it.
It depends on when the service install was last done. Maybe other is like my image.
In the old autoupdater design, a Duplicati is just a launcher for the latest update, but
when there are no updates, it just stays where it is, due to no better version around.
About --> System info could sort of show this jump with output like the following:
I think you can stop the service, Duplicati.WindowsService.exe uninstall, install, and start.
Updates folder can be removed once you’re sure you’re on 2.0.9.x and not the older stuff.
Progress, I think. The service no longer shows the path to the updates folder. However, it no longer accepts my password on localhost:8200. I tried changing the password using the systray instance on localhost:8300, but that didn’t seem to help with :8200.
I think these Duplicati-server.sqlite databases are in different spots, totally independent.
Need some developer input, e.g. has the database form of the password now changed?
This might have been done for security tightening, e.g. maybe better password hashing.
Documentation of what to do is pretty weak and scattered, but maybe try something like:
C:\Program Files\Duplicati 2>Duplicati.CommandLine.ServerUtil.exe change-password --server-datafolder "C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati"
Connecting to http://localhost:8200/...
Please provide the new password: ********
in Command Prompt (Admin) or similar, as default DB location needs admin for access.
EDIT:
Securing the database and password hash info might explain need to re-enter password.
I’m not sure, but it would be nice if old password could be converted into the new design.
Hashing is usually meant to prevent this, but the info speaks about some prior weakness.
Are you using the default database location for your system service? That’s what I showed.
If you added a custom --server-datafolder on last service install, then use that instead.
You can also look around the path I gave to see the names and ages of the files kept there.
I doubt it. It’s offering download of an old Canary, so is probably a leftover in the database.
Sometimes there’s also a bottom-of-screen popup from when a specific DB was last used.
Irrelevant ones can be dismissed. Maybe a check for updates will also find there are none.
If the default folder (what I showed) looks right after exam, the 2.0.7.103 database before conversion will probably be there (as a backup), but DB upgrade should keep the old jobs.
Any chance your recently used databases are elsewhere?
EDIT:
The default location has also been known to be cleaned out by Windows version upgrades.
Unless you like digging things out of C:\Windows.old. a different spot is a good thing to use.
As far as I am aware it should be using the default location - I don’t remember changing it.
I’m running a search for all *.sqlite files. I’ll have to dig through the list since the vast majority are related to Firefox, but I’ll see what is there.
The only other option would be something that was uploaded to backblaze that I can download from the website - i.e. if a simple copy of the dartabase gets uploaded as part of the backup.
I know the database has survived the upgrade to Windows 10 on all my Windows systems where I run Duplicati. Maybe the upgrade before that as well. But I have no objections to relocating the database if there is benefit in doing so.
Everything does that nicely (might delay a little while reading the MFT into its index though).
There used to be, but in looking into reports, it’s quieted down, despite Windows 11 updates.
Windows 10 is nearing end of life, so hasn’t been releasing new much lately. So I’m not sure.
