Duplicati Tray icon & --no-hosted-server / Running as a service

Hi Guys,

Good morning, I’ve migrated a duplicati tray/server install to a service. The new service is running fine on localhost:8200

No matter what I add to the tray icons startup path it’s still trying to connect and starting server on 8300

“C:\Program Files\Duplicati 2\Duplicati.GUI.TrayIcon.exe” --hosturl=http://localhost:8200 --no-hosted-server

The additional CLI commands do nothing, I’ve tried them either way around and each without the other, it’s still opening a connection to 8300 however.

Any ideas? It would be good to have the tray icon running to keep an eye on backup jobs status as VSC service is also involved at some points.


Issue was Duplicati needed the server/services data folder specifying as it was defaulting to the users app data location rather than the services.


Interesting, I wouldn’t think the GUI.TrayIcon process would need that at all if it’s connecting to a separate server process.

Even more interesting that it makes a difference, as if it needs it, it has no access permission to get it unless TrayIcon is running as something like an elevated (e.g. go through UAC prompt) user in Administrators group.

I think there’s one exception where one may want to arrange for direct access to server database to get into server password-protected HTTP interface, but that doesn’t seem to be the problem described here.

I guess the tray process needs to check rather than assume that a service process isn’t already running and default to whats required?

You would have thought --no-hosted-server kinda indicated that already though?

The tray process did need to be elevated too.


What are you suggesting happened in your case, and what should happen? This is simply a user-option. There may be a large number of servers on the system, and Duplicati doesn’t know which one you want.

This says don’t put up the internal server, use one that’s already up. Unfortunately, if not up, it times out…

Duplicati Tray Icon Silently Dies with --no-hosted-server arg #3137

Are you in a special situation such as GUI password? I can manually start TrayIcon just fine with just --no-hosted-server on an unelevated Standard User account, and it connects to a server running as SYSTEM.

My test case used Command Prompt, then run a cut-and-paste of the invocation line from original post.
If I change 8200 to an 8300, Task Manager shows the TrayIcon hanging around for perhaps 12 seconds.

Does this work for you after stopping existing TrayIcon? Just SYSTEM server and new TrayIcon as you.


For debugging any problem situation, Task Manager columns can include “User name”, “Elevated”, and “Command line” with the options. Sysinternals Process Monitor is nicer and can show TCP/IP situation.

Don’t be alarmed to see Duplicati processes come in pairs. The parent starts the latest version as child which means that the child does the actual work, puts up the TCP/IP LISTEN (also visible in netstat) etc.

1 Like

I think the original solution already answered your question then? The tray process didn’t know where the service/server datafolder was located.

Without being elevated the tray process can access system folders?

Just to add to that, how many tray processes are you planning on running with different servers? They all look the same to me. :rofl:

–no-hosted-server - specified another was not required as there was already one running, the service?
–hosturl=http://localhost:8200 - pointed the tray icon to where it was listening?

It appears that the tray process also wanted the location of the data folder though, as per the solution.

I’m not sure what point you’re trying to make?

I posted puzzlement over why it would need access to that folder, and showed my success without that.

You could have many users logged in, if a system is set up for that. Each user uses their own Duplicati.

Sorry I don’t understand that. When intending to connect to the Windows service server, use this to stop TrayIcon from putting up its own server. At best, it wastes that server. At worst, it uses its own by default.

None of what you did should have been required, and was not required in my test. Can you test that test?
UAC elevation also creates problems, as start-at-login scripts can’t do it. If they could, it’s still a nuisance.

If you really want to leave things just as they are, let’s drop it, but I would prefer knowing why results differ.
You also seemed to have some questions, or think that things were not working the way you would prefer.

Your system must have slacker user access control policies than my mother in laws 12yr old dungarees.

In relation and answer to all your questions, re-read the first sentence of this thread. :+1:

It doesn’t need to know that. Only the server process does. The TrayIcon just needs to know what server to talk to (via http) when it itself is not hosting the server.

I still think there is some confusion about your setup.

In general case, yes, because server as SYSTEM has full access to its profile (and more), and TrayIcon doesn’t need access. Security on my system does not allow file-level access, yet TrayIcon runs just fine.

For password-protected servers, TrayIcon needs to either be told or be able to get the server password, which is discussed in the cited GitHub issue, but we need to know user use (or not) of password to say.

I’ve tested adding an access password and blocking TrayIcon this way. I also tested the listed solutions.
What I haven’t been able to get is the “connection to 8300” of original post unless I specifically ask for it.

Knowing (e.g. via netstat -ano) what process has that (did --no-hosted-server not work?) would help.
For my test, I don’t have anything at 8300, but I’m watching port 8300 on my loopback using Wireshark.

The “re-read the first sentence of this thread” suggestion isn’t clarifying, nor is not doing suggested tests.
This sounds like an invitation to drop this because solution is satisfactory, even if it’s not understood why.

I’m guessing you’re one of the developers?

Setup of the tray icon in order for it to function with the service rather than server was exactly as I described.

If this is some sort of issue, perhaps refer it to github?

Not me. Almost everyone on this forum is a user. Two regular volunteers are trying to work on this.

If you mean file an issue on GitHub, those don’t get far unless they’re reproducible from exact steps.
Steps should be simplified as far as possible, for example does it need startup or can CLI cause it?
There are far too few developer volunteers (any out there?), and forum pre-investigation helps them.

I have a vague sense of what you did, but am not getting enough clarification to reproduce the issue.
I’m using an approximation from Command Prompt and asking how that is working on your system.

If you mean search GitHub, I haven’t searched but know issues pretty well and pointed to a suspect.
Only you can tell me whether or not the UI password lead applies to your Settings. See picture there.

This doesn’t mean it was sufficient in detail and clarity. A not-described factor might be the difference.
Sometimes some experimentation is needed. If you prefer not to work on this, then let’s just drop this.
The forum is also short on volunteers (any out there?) and can best help people who help the helpers.

Problem: Server to service migration. No matter what I add to the tray icons startup path it’s still trying to connect and starting server on 8300

Solution: --hosturl=http://localhost:8200 --no-hosted-server --server-datafolder=“C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati”

That’s all I’ve got for you, it’s what got the tray process connecting to the service properly. Yes the UI on 8200 was password protected, but that’s not going to block access to UI itself or the datafolder?

Over and out.

Thanks for the clues. For the UI itself, you type the password. For TrayIcon, use --webserver-password on start to tell it the password, or using --server-datafolder will let it get it from the database directly, but due to access control on SYSTEM profile it needs elevation or loosening at least Duplicati parts of profile security. This matches open issue so far, except for 8300 connect. You can stay on current setup, or test another…

Over and out for now at least.

You might be able to find a better guinea pig for issues like this, the computer/network etc I’m using is controlled by the high command as such it probably doesn’t provide the best test environment for yourself, or Duplicati.