Get Microsoft's Attention Over Windows Update Deleting Duplicati DB/Configs

Support
1

Using duplicati as a service, You may know that the DB and configuration are kept in C:\Windows\System32\config\systemprofile\AppData\Local.

With this directory being likely to contain user data, It should not be removed when windows update upgrades windows. However, users have had there Duplicati Data wiped by windows update because it is wiped in the upgrade process.

If you agree that this folder should not be messed with during an upgrade, Upvote this windows feedback post to get Microsofts attention over this problem.

https://aka.ms/AA5r5sw

2

Done. Thanks for that. Next, someone needs to lobby Synology to stop their root-does-what-it-wants plan.

For now, people on such systems can workaround heavy-handed updating by keeping configs elsewhere.

Migrating from User to Service install on Windows has some ideas but no clear agreement for code work.

3

Nope, Duplicati should be using ProgramData not the system profile folder - then it’s a non-issue.

1 Like
4

ProgramData is what I run, but using --portable-mode on the install has been suggested (config is under Program Files, which some people see as wrong). Main drawback/advantage that I see in ProgramData relative to the profile for SYSTEM is that file permissions are more open – and database hold credentials. They’re obfuscated on Windows, but it’s mostly to thwart unsophisticated malware, e.g. string scanners.

Tray Icon does not start after setting a UI password (Service Mode) suggests an advantage of loosening access to the config. TrayIcon needs to use a lower-level HTTP interface to check server status, and its method of getting the password is to read the DB. But TrayIcon runs as users, so user might see things intended for some other user on multi-user system. Web UI has similar problem for a SYSTEM service.

There seemed at one time to be an idea of how to fix TrayIcon, but even now, ProgramData seems best. Would anyone care to check GitHub issues to see if it’s actually requested? Migration is also an issue…

Duplicati creates large files in the roaming part of the user profile on Windows #2222 is linked from my first link, and there the --portable-mode suggester also suggests ProgramData. A big technical analysis follows.

To make things more complicated, a service doesn’t have to run as SYSTEM. It can run as some end user.

5

Anyway, this is my fix for the profile folder being wiped between major Windows updates:

mklink /d C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati %ProgramData%\Duplicati

Every subsequent update I just re-run the command and file are back.

6

If I had any time I’d do an update that, upon finding no settings, would check for old Windows folders and offer to move them over from there.

7

The plan here is the Synology-version workaround. I wish the OS vendors respected customer data.

8

I researched this a while back and basically Synology does not support modifying the NAS as root, which includes placing files in /root.

I used to do the symlink thing as mentioned in the post, but now I use a different approach. I use Task Scheduler on the NAS to trigger an automatic start of Duplicati when the NAS boots/reboots. This lets me pass command line option so that Duplicati never tries using /root/.config at all.

Script looks like this:

#!/bin/sh

mono "/volume1/@appstore/Duplicati/Duplicati.Server.exe" --webservice-port=8200 --webservice-interface=any --server-datafolder=/volume1/_Duplicati --tempdir=/volume1/_Duplicati/tmp &

I’m actually going to probably switch to using Duplicati in a Docker container at some point and avoid this mess entirely!

For Duplicati on Windows, I’d recommend that if it detects it is running as LocalSystem it should just save in C:\ProgramData\Duplicati instead.

1 Like