Can't connect to web-ui from within local network

Support
#1

I’m trying to run the web-ui on an ubuntu 18.04 machine and it seems to work fine when I got to 127.0.0.1:3875 but when I try to access 192.168.1.4:3875 the connection is refused:

image

I added this to my settings.json file

{
    "listening_address": "0.0.0.0:3875"
}

I also did this the following to run duplicacy_web as a service:

But I was unsure whether the ~/.duplicacy-web/settings.json referred to my own home directory or that of root so I put it in both places but to no avail.

What else can I do to fix this?

#2

I just replied to you post in the other thread. No need to edit the settings.json file directly. Instead change the http address on the Setting page.

1 Like
#3

I guess it’s not just “no need” but no point, right? Because it has no effect anymore. Where are the settings stored now. When I changed the IP on the settings page, neither of my settings.json changed… :thinking:

Also, I’d like to mention that updating the settings page did not go as smoothely as intended. I got the message that the server will be restarted but then it was unable to connect to 127.0.0.1:3875 (which kinda makes sense since I just changed the listening IP) but under 192.168.1.4:3875 there was nothing either. The server was still down. I needed to manually restart it with sudo systemctl start duplicacy…

#4

OK, I figured it out: for onknown reasons I had a third settings.json file at /.duplicacy-web/settings.json and that is actually the one duplicacy web is using.

I don’t believe I created that directory myself. Could it be that duplicacy web creates it by itself when it runs for the first time?

How do I tell duplicacy web to use a different .duplicacy-web folder?

This is reproducible. I guess it has to do that I’m running duplicacy-web as a service/daemon. Is there a way to tell how to restart itself properly?

How to access the duplicacy web-interface remotely
#5

I found it worthwhile to change the [Service] section to include a username and a working directory:

[Service]
ExecStart=/home/brian/bin/duplicacy-web
WorkingDirectory=/home/brian/.duplicacy-web/
User=brian
Restart=on-failure
RestartSec=30

Thus allowing the service to run in the same environment as if I’d started it from the command line under my normal user privileges.

Then is sees and uses the normal files in my ~/.duplicacy-web directory.

(This is when running Ubuntu 18.04.4 LTS.)

Addendum: when running as a service under a normal user’s identity, as above, it doesn’t seem to have access to Linux’s keychain. So you have to re-authenticate at the browser window after a restart of the service.

1 Like
#6

Instead of running it under your own user, you should probably use a dedicated service account for isolation.

To the OP: if this wasn’t already addressed, did you ensure the problem was port 3875 not being open instead of the server not listening on the correct IP? You can verify with netstat and iptables.

#7

What I did was I checked the firewall (ufw) if the port was blicked (but the firewall was not even active).

#8

After I once again wasted hours on this very same issue of not being able to access the web-ui on a new linux machine, I just want to clarify how duplicacy works on linux: when it started from the command line, it creates a .duplicacy-web (or whatever you called it) directory in the current user’s home directory and it is in this directory. If you start it as a service, however, that directory is not in your home directory but in / so if you follow the instructions for running duplicacy as a service it is this latter directory where you need to put the settings.json, not your home directory and not anywhere else, like some working directory that you might have specified in your /etc/systemd/system/duplicacy.service. At least that didn’t work for me either (running Debian/ OpenMedieVault).

In retrospect, it is somewhat ironic that @gchen insisted that there is no need to edit the settings file at all because you can just do it through the web-interface… Well, the problem is that I don’t have acces to the @¤#!% web-interface because duplicacy is default-listening on 127.0.0.1 and thus won’t let me in unless I have a browser installed locally. So the whole point in editing the settings.json on the CLI is to be able to access the web-interface in the first place…

Well, I thought I could outsmart duplicacy’s somewhat exaggerated (?) security precausions and installed a CLI browser (lynx) so that I would be able to access the web-ui via the command line, but that didn’t work either because it was not possible to submit the password on the login screen:

image
image966×374 16 KB

@gchen May I suggest a command line option to tell duplicacy which port it is supposed to listen on? And if it exists to document it. I think we still don’t have any accurate guide for installing duplicacy-web on a headless server… Maybe I’m particularly dumb, but I can predict that if I ever end up setting up duplicacy on a headless server again, I’m going to run into the same issue again, … unless I find this post here. Which is why I’ve tried to include as many relevant search terms as possible. Hope this is useful for others too.

Some basics about running duplicacy in a docker container
#9

Sorry I was wrong – that was based on the assumption that you can access 127.0.0.1:3875 from a browser. If you can’t, then the simplest method is of course to create a settings.json file. But you can also set up an ssh tunnel from your local machine to the head-less server:

ssh -L 8000:127.0.0.1:3875 user@server

Then you should be able to open 127.0.0.1:8000 on your local machine.

3 Likes
Some basics about running duplicacy in a docker container
#10

Oh, yes, the tunnel option! I completely forgot about that! I guess I shouldn’t be administering a linux server when I’m still struggling with such basic things… But it would be great if we could have a proper how-to (which could be linked from the setup guide on the website). And why not give dublicacy-web a command line option to specify its working directory? I am not aware of any program that just creates its own directory in \. Is that what daemons are supposed to do?

Anyway, there are obviously many, many server admins successfully using duplicacy since it’s Logo is known by Heimdall.

1 Like
#11

I think this is the only viable way to connect to remote instance of Duplicacy due to this: Web-UI security: HTTPS, sessions, and logout button

1 Like
#12

… unless I find this post here. Which is why I’ve tried to include as many relevant search terms as possible. Hope this is useful for others too.

Thanks for this very thought, I am suffering a little at the moment. I had things working well but am having to troubleshoot all over again, it’s hard to pin down what exactly might rectify things, from within a headless world. I could always mentally assemble a webpage from curling the local address to do some light monitoring. lol

1 Like
#13

ssh -L 8000:127.0.0.1:3875 user@server

Great tip, thank you my friend.