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.

#14

Hi @Christoph, I’m glad to find this thread, as I have the same issue, accessing the web-gui via a headless server.

I can use the ssh tunnel method and it works. Though from my understanding, I would be logging in remotely (on my lan) to the debian homeserver (where duplicacy runs) which starts the web-gui. If I close the terminal then the gui closes too.

Alternatively, is it possible to keep the gui running without having to ssh tunnel, via using the the settings.json file. What I still don’t understand is where to put it (/ i.e root?), and what to put in the systemd file.

thanks

#15

You only need to use the tunnel once to change the listening IP to 0.0.0.0. After that you just access the web-ui remotely as usual.

#16

No, web-gui shall be already running, otherwise your backups won’t run. You would need to setup systemd service to start duplicacy-web when the server starts.

The ssh in this thread is only to create a tunnel to your server. If you only do that in the trusted lan then it’s indeed overkill, and you can configure duplicacy to listen to all interfaces (0.0.0.0) per comment above (or directly in the settings.json file) and then connect from anywhere.

There is another, my preferred solution, is to use cloudflare zero trust, thus allowing to connect to duplicacy webui (or to any other private web service in your lan) from anywhere in the world, without messing with vpns, tunnels, ports, or firewalls, protected by cloudflare and identity provider of your choice.

That said, there are of course ways to start an app via ssh session in a way that will let it survive session disconnect, if that is what you want to do.

One way is to start tmux session and launch app there. When ssh disconnects — app will continue running in the tmux session.

Another — use disown command of your shell. For example,

% ssh me@myserver
# /usr/local/bin/my_app & disown
# exit
%

Have a look at the first comment to this blog post: Duplicacy Web on Synology Diskstation without Docker | Trinkets, Odds, and Ends. The example service definition file is there provided by the fellow kind user.

#17

I’m totally confused. (Apologies, newbie ignorance)

At the moment, if I login to headless server via tunnel on LAN:
ssh -L 8000:127.0.0.1:3875 zed@192.168.1.82
I can access webgui at: http://127.0.0.1:8000/

Now, when I close the terminal, I lose the webgui access.

Duplicacy is still running (I created a systemd service), and it carried out a scheduled backup when the terminal was closed. What I’m confused about is as duplicacy is still running, why can’t I access via webgui without having to have an opened ssh tunnel session?

Thanks

BTW, I use tailscale to access the homeserver when outside the LAN. (Homeserver otherwise has no external access). From what you say, accessing webgui could be done that way? Though I’d like to figure out what’s going on above.

#18

Ah, got it. I misunderstood. I thought you ssh to the server and start duplicacy there in the same ssh session.

Yes, because when you close the terminal the tunnel gets destroyed.

If you want, you can make sure the ssh tunnel keeps running after you close the terminal by disowning the process:

ssh -L 8000:127.0.0.1:3875 zed@192.168.1.82 & disown

By default duplicacy web is listening on a loopback interface only. This effectively means you can only connect to it from the same machine. The ssh tunnel brings you to that machine, just like any other vpn tunnel would.

If you want to be able to connect to duplicacy from outside of the server without vpn — have it listen on the lan adapter interface by providing its IP, 192.168.1.82 in settings.json. Or, all interfaces, which is 0.0.0.0.

#19

Yes. Using Tailscale (I prefer Zerotier myself, as mDNS does not work over Tailscale) or any other vpn solution is an overkill. VPN connects networks and devices. You don’t want to establish connectivity to your server, or join its lan; you just want to reach the web app.

Cloudflare zero trust creates an outbound tunnel to the cloudflare services where then you configure which application to expose and to who. This way you don’t need any vpn on client devices, just credentials for the identity provider you chose to guard access behind.

But for duplicacy even this is too much. Backup is getting configured once and never touched again… you can do that with the temporary ssh tunnel as well.