Release: 2.1.0.108 (Canary) 2025-01-31

[kenkendk]

2.1.0.108_canary_2025-01-31

This release is a canary release intended to be used for testing.

Important change

This build changes the folder locations for the Duplicati-server.sqlite file on Windows and Linux when running as a service.
There is support for backwards compatibility, so existing installations should not be affected.

The detailed changes are:
Windows: Avoid storing data in C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati and prefer {SystemRoot}\Users\LocalService\Duplicati
Linux: Avoid storing data in /Duplicati and prefer /var/lib/Duplicati.

If you are not running Duplicati as a service, this has no effect.
If you are using --server-datafolder or DUPLICATI_HOME, this has no effect on the database, but may cause your machineid and installid to change.

The machineid.txt and installid.txt would previously be stored in the local app data folder, even when using portable mode or choosing a specific data folder.
This has been fixed, so the files will now follow the database.
If you are using the Duplicati console or otherwise depend on these values, you need to move them into the folder where the database is stored.

New UI

This release contains an updated version of the new UI.
In the url, change ngax to ngclient to try the new UI.

Detailed list of changes:

• Fixed encoding of exported files
• Fixed issue with restore trying to read files opened with write-only
• Improved backend tester
• Missing file detection during recreate is now a warning
• Fixed Minio backend not throwing exceptions
• Fixed hidden files display in source picker
• Added additional source folders for MacOS
• Removed SHA1 signatures on Windows signing
• Rewrote the backend manager to better control backend (re-)use
• Updated reporting to support sending OS type and backend type
• Tagging Docker images with channel, thanks @stavros-k
• Added support for CORS headers in the Webserver
• Unified help arguments across all executables
• Fixed parsing flags as multiple values for FTP SSL type
• Added guard against storing files in Windows folder
• Fixed crash in AutoUpdater

[Taomyn]

@kenkendk

{SystemRoot}\Users\LocalService\Duplicati

Is this correct? There’s no such folder on any Windows machine I use, i.e. C:\WINDOWS\Users\LocalService when SystemRoot=C:\WINDOWS

[drwtsn32]

Same here. I’m guessing he meant %SystemDrive% instead of %SystemRoot%.

But even so, C:\Users\LocalService does not exist. Is that the appropriate location for machine-level data? I thought the norm is somewhere under C:\ProgramData.

[kenkendk]

@drwtsn32

I’m guessing he meant %SystemDrive% instead of %SystemRoot%.

Yes!

Actually, it tries to get the user profiles folder first, which is usually C:\Users and if that fails it goes to {SystemDrive}\Users, for older versions of Windows.

@drwtsn32

But even so, C:\Users\LocalService does not exist. Is that the appropriate location for machine-level data? I thought the norm is somewhere under C:\ProgramData.

I am open to suggestions on the correct location.

From what I could read, C:\ProgramData is for data that is shared between applications (e.g., public data, like textures, etc), and not for data that is intended to be private for the instance.

I have not been able to find any direct recommendations from Microsoft, but a few suggestions were made mentioning C:\Users\LocalService so I considered this the most appropriate.

And yes, the folder does not exist, but will be created as needed. And yes, if you actually have a user called LocalService weird things will happen.

[drwtsn32]

… is for data that is shared between applications (e.g., public data, like textures, etc) …

I think that’s C:\Users\Public

and not for data that is intended to be private for the instance.

This may be true. I believe C:\ProgramData is readable by all users, but writable only by the file owners or admins.

Perhaps being readable by all users is undesirable when Duplicati runs as a service.

In your current approach, are you customizing the ACL if you create C:\Users\LocalService? It is not readable by other users?

On a related tangent, how is the situation handled where Duplicati runs as a service but as a “real” user, like Administrator, instead of LocalService? I run the service using the Administrator user on a couple of my systems, and prefer the Duplicati data be stored in the Administrator’s appdata area.

[kenkendk]

@drwtsn32

I think that’s C:\Users\Public

No, I think the public folder is for sharing data between users on the local network:

• https://answers.microsoft.com/en-us/windows/forum/all/public-folders-windows-10/272d32ef-bc85-4742-9702-6626fd10f5d8

@drwtsn32

This may be true. I believe C:\ProgramData is readable by all users, but writable only by the file owners or admins.

Yes, that is also what I could find:

ProgramData

@drwtsn32

Perhaps being readable by all users is undesirable when Duplicati runs as a service.

If you have field-level encryption, it should be safe to share the database. But for improved security, the database should not be shared.

Since ProgramData is also shared between all users of the system it is not a good fit to store the data there, IMO.

@drwtsn32

In your current approach, are you customizing the ACL if you create C:\Users\LocalService? It is not readable by other users?

That is a very good point. For Linux/MacOS Duplicati will reset the permissions on startup, but this is not done for Windows.

I just checked, and unfortunately, the created folder is readable by “EVERYONE”, so that makes it equally unsafe with the other choices.

I will fix this and remove “EVERYONE” from the ACL when creating the folder. Ideally, only the current user should have access to the Duplicati subfolder, so I will look into making it behave more like the Linux code path.

@drwtsn32

On a related tangent, how is the situation handled where Duplicati runs as a service but as a “real” user, like Administrator, instead of LocalService? I run the service using the Administrator user on a couple of my systems, and prefer the Duplicati data be stored in the Administrator’s appdata area.

If you run as a “real” user, the folder %LOCALAPPDATA% should resolve to the user’s home folder. The change will only kick in if the returned folder is under the %SYSTEMROOT%.

[pb2004]

No application should create itself random folders in c:\users. Only the system has the right to do this when creating a user. There is unknown what will happen to such a folder when the system is upgraded. I have checked several services on my computer and each uses Common Appdata. This is the folder that is used to store such data especially if you use /var/lib/Duplicati on Linux. This is the equivalent of that folder. And, as on Linux, it’s up to the application to set the appropriate acl if the defaults don’t fit.

[ts678]

@pb2004

each uses Common Appdata.

Technically a subfolder? I haven’t verified this lately (and the updater has gone away), but precedent exists (based on shell: common appdata in explorer giving me ProgramData):

@JonMikelV

a. C:\ProgramData\Duplicati\updates (most Windows service instances)
b. C:\Users\<Duplicati user account>\AppData\Local\Duplicati\updates\ (most Windows user / tray-icon instances)

@johnvk

Create a folder called C:\ProgramData\Duplicati\Data **
(this is what solves the windows update problem)
(If you’re running portable, choose a dir under the program directory, eg D:\Duplicati\Data)

@pb2004

I have checked several services

Do the services also run as non-services? That’s one thing that may complicate layout planning, however the plan to use %LOCALAPPDATA% for real users sounds good – and very traditional.

If your services do also run as ordinary users, is this what they do? Just curious for further data.

Thanks for your input.

[pb2004]

@ts678

Technically a subfolder? I haven’t verified this lately (and the updater has gone away), but precedent exists (based on shell: common appdata in explorer giving me ProgramData):

Of course. From what I’ve seen in the code now there is first a check to see if it is a Windows subfolder and if so the new location is then assembled with FOLDERID_UserProfiles + LocalService + application name. Just change in the code to make the new location use FOLDERID_ProgramData + Duplicati.

@ts678

Do the services also run as non-services?

No but that’s not a problem because as I wrote above it’s already in duplicati anyway checking if the data folder is one of the Windows subfolders.

[kenkendk]

@pb2004

No application should create itself random folders in c:\users.

I agree, it is not ideal.

@pb2004

I have checked several services on my computer and each uses Common Appdata.

What kind of data do they store? The problem is that Duplicati stores encryption passphrase and remote storage credentials in the database, and CommonAppData is readable by all users.

Do the service applications apply ACLs to the data they write?

@pb2004

especially if you use /var/lib/Duplicati on Linux

It is my understanding that users do not have access to that folder:
5.8. /var/lib : Variable state information.

Is it different on your systems?

[ts678]

@kenkendk

CommonAppData is readable by all users.

That might be documented plan for top level folder? Is there a reason everything below must be?

[kenkendk]

@ts678

That might be documented plan for top level folder? Is there a reason everything below must be?

Fair point.

@pb2004 is that consistent with what you see? Are the sub folders protected?

[pb2004]

@kenkendk

The problem is that Duplicati stores encryption passphrase and remote storage credentials in the database, and CommonAppData is readable by all users.

Do the service applications apply ACLs to the data they write?

Probably they are rather trying to store login data in a different way. Changes to the access control list under Windows are unfortunately not a simple chmod 600 file.

@kenkendk

It is my understanding that users do not have access to that folder:
5.8. /var/lib : Variable state information.

Is it different on your systems?

drwxr-xr-x 2 root root 4096 lut 5 21:30 test
ls -la /var/lib/test/
total 8
drwxr-xr-x 2 root root 4096 lut 5 21:30 .
drwxr-xr-x 44 root root 4096 lut 5 21:29 …
-rw-r–r-- 1 root root 0 lut 5 21:30 testfile

As you can see the standard 755 and 644.

[pb2004]

@kenkendk

Fair point.

@pb2004 is that consistent with what you see? Are the sub folders protected?

On Windows, there are few folders or files to which the user group did not have read rights by default. In its current state as far as I know Duplicati does not modify acls of the Duplicati folder regardless of where it is created. This is only because the user profile folder has system:(OI)(CI)(F) administrators:(OI)(CI)(F) and username:(OI)(CI)(F) permissions assigned by the system at creation and only such other users cannot access the files. In the other cases discussed, permissions are inherited in the appropriate way from parent folders and so the Users group inherits from ProgramData (OI)(CI)(RX) and (CI)(WD,AD,WEA,WA). From the Users folder, the Users group inherits (OI)(CI)(IO)(GR,GE) and the Everyone group inherits (OI)(CI)(IO)(GR,GE). Data from icacls.

[kenkendk]

@pb2004

drwxr-xr-x 2 root root 4096 lut 5 21:30 test
ls -la /var/lib/test/
total 8
drwxr-xr-x 2 root root 4096 lut 5 21:30 .
drwxr-xr-x 44 root root 4096 lut 5 21:29 …
-rw-r–r-- 1 root root 0 lut 5 21:30 testfile

As you can see the standard 755 and 644.

I looked at a clean Ubuntu installation, and most folders were 755, but a few, such as saned was using a 700.

@pb2004

as far as I know Duplicati does not modify acls of the Duplicati folder regardless of where it is created

Yes, that is correct. The permission fix was only done on Linux, and it was assumed that the location would be safe, due to permissions on the parent folders.

I have made a new PR that applies ACLs to the data folder and the databases on both Linux/MacOS and Windows.

It also switches to C:\ProgramData\Duplicati for the case where the folder would otherwise be under C:\Windows.

If you have time, let me know if there is anything that looks off.

[pb2004]

@kenkendk

I have made a new PR that applies ACLs to the data folder and the databases on both Linux/MacOS and Windows.

It also switches to C:\ProgramData\Duplicati for the case where the folder would otherwise be under C:\Windows.

If you have time, let me know if there is anything that looks off.

As far as Windows is concerned, in the DirectorySetPermissionUserRWOnly and FileSetPermissionUserRWOnly functions I would also add full permission for the System(S-1-5-18) user in case Duplicati is running on a regular user account as a regular program(writes to LocalAppData). Lack of this permission may cause unpredictable system errors.
Something like:

string sidString = "S-1-5-18";
SecurityIdentifier sid = new SecurityIdentifier(sidString);
NTAccount account = (NTAccount)sid.Translate(typeof(NTAccount));
string accountName = account.ToString();
security.AddAccessRule(new FileSystemAccessRule(
    accountName,
    FileSystemRights.FullControl,
    AccessControlType.Allow
));

[kenkendk]

@pb2004

As far as Windows is concerned, in the DirectorySetPermissionUserRWOnly and FileSetPermissionUserRWOnly functions I would also add full permission for the System(S-1-5-18) user in case Duplicati is running on a regular user account as a regular program(writes to LocalAppData). Lack of this permission may cause unpredictable system errors.

Good to know! I have updated the PR with adding LocalSystem permissions as well.