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.
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…
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.
EDIT:
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.
–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 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.
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.
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.
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?
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…
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.
