One thing I have noticed when launching duplicati as an application and installing it as a service, is that they seem to use two completely different sets of configuration data.
This can be a bit of an annoyance, as duplicati installs as an application by default and gives no option to install as a service on install. This means that if you have set up duplicati, like it, and then decide to install it as a service using the executable in the program directory, you will find your self having to set everything back up again.
is there a technical reason why the service mode uses its own configuration domain rather than using the configuration data from when it is run in application mode?
The technical reason is that when running As A Service in Windows the “user” is called SYSTEM. And this “user” stores its settings in the Windows Folder.
When running “normally” it runs as the currently logged in desktop user hence the files going to the user’s %APPDATA% folder.
There is a setting that allows this location to be changed as explained by @ts678.
I’m a Windows user like you and we are too used to soppy GUIs helping us out. Underneath Duplicati is a tough command line application which is why we get a little confused at times. The options are there, but in a long complex list of choices.
Migrating from User to Service install on Windows speaks to this, until a proper install-as-service facility exists. Setting the DUPLICATI_HOME environment variable (mentioned in that article) can also help unify operations.
I figgered it was something like that. Was just wondering if there were plans to unify the configuration sets for quality of life purposes. Now I know there is no technical reason that this can not be done, I’m a happy bunny.
I think I will whip up a .bat script to auto-migrate and unify the directories and update the post when I’m done
When an application is running as SYSTEM it can work when no users are logged in. On a multi-user system this can be important. It can be a little confusing on a single user desktop install.
One thing I’ve learnt is that the GUI may be a bit confusing for us Windows users, but the setting is in there somewhere…
As you can see from the Migrating article, it’s not even agreed where the best place to use would be. Maybe someday, meanwhile my personal practice is to use C:\ProgramData, not the SYSTEM profile. I lose the high security, but the twice-yearly clobber from Windows version upgrades doesn’t affect me (I hope…). Duplicati gives users options sometimes (and sometimes it gets confusing…). Tradeoffs exist. Keeping configs in user related areas even lets multiple users keep somewhat independent Duplicati backups, e.g. on shared server.
Mabe some setting masking could be in order.
Have duplicati pull settings from ProgramData as its administrator set/default parameters. This is what the service uses and is also what users are given as default settings.
Use %APPDATA% as an overlay for user-specific settings.
Forgive my sudo code. But i think you get what I mean.
I also understan sat some settings you may not want in user land, so don’t think of the above exsample as being what a user should be able to edit over what an admin has set.
Note that I may be misremembering the paths here so feel free to correct me.
Assuming OS consistency is desired the MacOS/Linux equivalent would likely be /root/.config/Duplicati with an overlay from ~/root/.config/Duplicati.
So when running as root (daemon) it would pull solely from /root but when running as user it would try to pull from /root but fail due to permissions and only get the “overlay” settings from ~/root.
There’s also the issue of the …/Duplicati/updates folder. As user, updates would be in the/root party users can’t access so they’d end up potentially running a different version.
As root, updates could be in many /[user]/.config/Duplicati/updates folder which may not all be at the same version.
Assuming I’m not just confusing myself here, if those scenarios can be handled OR Windows is declared an outlier then I could see the overlay process working.
My opinion (and I’m certainly not who decides what happens) is that this reminds me of the current global Settings on the main screen, and questions people have about how it interacts with specific backups. and what exports get, but this adds a similar-but-orthogonal direction.based on user. It may get unexplainable.
There’s also the new concept of set/del/add, which maybe can be separated and/or dropped if necessary. Currently I think deleting a global Settings default override is done by job setting the value back to default, which unfortunately requires figuring out the default (or just set what you want). In that way, del is nicer…
When service mode is more common, we’ll also be explaining that the browser user is not the backup user.
It seems far simpler to me to just set DUPLICATI_HOME to an area that all relevant modes have access to, however even this may need some setup to avoid permission issues. I just recently relaxed mine further… Previously I was using “Run as administrator” from a “Standard User” account to do Duplicati experiments.
The time to seriously get into sorting out the UX is possibly whenever anyone frees up for a proper service installer, however with all the hotter issues around, I’m not sure when that can be. Meanwhile we’ll chat.
Another idea. Why not use a proper login system to the web interface and have duplicati run as an elevated service as its only mode of operation. That way, PC user domains become irrelevant, Duplicati will always have system/root permissions for file access, and all settings can be self-contained in a DUPLICATI_HOME directory in one place, with authentication and authorization managed by the duplicati server.
FYI: I’m not expecting any of this, just think its good to spitball ideas and see what we get.
Edit: Obviously, standard users should not be able to backup files that they do not have permission to access. Some concept of administrator elevation would have to be given to duplicati, so that even though it is operating in the system/root domain, it will not just blindly let any user mess with any file they like.
I was looking for a discussion on multi-user support, and this is the closest that my search dug up. I’m coming at this from a rather different angle, but I hope you get my point.
Duplicati is essentially a single-user installation for closed networks. This time and age, I think multi-user support should be based on GPG/PKI credentials, independently from local or domain accounts. By multi-user support I mean that each user cand create, run, restore, etc. only their own backup jobs. Duplicati already supports the use of GPG keys instead of AES for encryption, which alone does not lead to multi-user support. I would imagine that adding a wrapper to the Duplicati CLI would not be too hard, but adding a wrapper to the web GUI is quite another undertaking. The support really has to be in Duplicati itself.
So, my point is not about which folders to tinker with, but how to add actual multi-user support. Is there someone who believes it should be based on local or domain accounts?
But i think you get what I mean.
