So far I have been using Duplicati in user mode, on both of my laptops. Every now and then I entertain the idea of setting it up in service mode so I could launch a backup on one laptop from the other, maybe in both directions. I have never bothered to actually set it up that way, but every time I ponder this, I find myself stuck with the explanation of --read-config-from-db. It kind of seems clear enough, yet I cannot make head or tail of it.
Since this behavior is offered as an option, it clearly is not always needed. So what is the purpose, when is it needed? For what, what does it achieve? Does it matter if I want to commandeer a service process of one host from another host?
That’s not really the purpose of running Duplicati as a service. The advantage to running it as a service is that you can have it operating even when no one is logged in. For servers this could be useful. The other reason to do it this way is if you want a single Duplicati instance to handle all data on the machine with a single setup, regardless of who or how many people log in.
If you are talking about regular desktop/laptop machines that are only used by a single person, then there is almost no reason to switch to the service type installation.
Regardless of which mode Duplicati is running, you can enable “remote” access to the web UI by enabling the “Allow remote access” option on the main Duplicati Settings page. This causes Duplicati listener to bind to all addresses (0.0.0.0) instead of just localhost (127.0.0.1) so that it listens on any interface. You obviously should be careful with this mode and probably set a password for the UI.
If you allow remote access to the web UI, you can then see all the jobs and trigger backups on remote machines.
One can also right-click on a Duplicati shortcut, then Properties --> Advanced, then check this box.
and then put up with manually answering a UAC prompt. The current installer seems to offer no assistance for this workaround, or Task Scheduler workaround, or installing as a service. In fact, subsequent install as a service works best with two .msi installer manual changes shown below:
This is one of my nominees for can-use-improvement-for-good-out-of-box-run-with-Admin-privileges.
But to get back to the original topic, Duplicati.GUI.TrayIcon.exe is presumably the explanation which doesn’t say quite enough, and there’s also not much talk in forum or GitHub issues – it’s uncommon:
Set this option to read server connection info for running service from its database (only together with no-hosted-server).
Set this option to not spawn a local service, use if the TrayIcon should connect to a running service.
On a default .msi install, TrayIcon contains its own Duplicati Server for the web browser to connect to, and which also does the backup and other operations. In a Windows service install, the server portion starts at boot time, and the TrayIcon at login time. TrayIcon then needs to connect to the server which sometimes means it may need a web UI password or certificate information so it can update its status.
The following code looks like --read-config-from-db connects to the configuration database to read info:
and sometimes this works, but sometimes its blocked by file access permissions to read the database.
Reading configuration from the DB will have fewer permissions problems with non-default DB location which does not put it in SYSTEM account profile, and this also lets it survive Windows’ version update.