Running official docker container on unRAID. Cannot load web gui, I get “This page isn’t working” and “HTTP ERROR 400” - there are NO logs in the container logs so I can’t even see what’s going on. Where are the logs held within the container?
The only report I find on this involved a reverse proxy on the connection to Duplicati. Do you have one?
Is this a new problem? If so, what changed?
The web server is a separate GitHub project, not really a Duplicati creation, and I don’t know if it can log.
Sometimes browser hard refresh (typically hold Control key and press F5, but it may vary) helps hangs, however I’m not sure you got that far. You might be able to use browser developer tools (often opened by F12) to look.at the network activity to see if you can find any clues. Packet capture is possible, but hard.
EDIT:
Here’s what Firefox web developer tools show when I browse to localhost:8200. What does yours do?
/facepalm bad cookie… Thanks for making me think to open dev tools.
Unfortunately all my backup configurations are gone again…the home screen is empty 
And now after a few restarts they’re randomly back.
Got same error on 2 nas with latest version of docker image dev branch
Is this a new LinuxServer image? Duplicati’s uses different naming, but both have just gotten
Release: 2.0.9.102 (Canary) 2024-08-02
Linuxserver.io version: v2.0.9.102_canary_2024-08-02-ls170
Is this what you just picked up? If so, it’s presumably some new issue the devs need to look at.
EDIT:
and it looks like it’s your issue, or at least same user name.
Yeah it’s yeah it’s me I got this problem still
I don’t know how quickly the devs can look at it. If you have to, maybe you can revert to 2.0.9.101.
In the GitHub version of this, I asked the second report if they’re on same LSIO, or different install.
How to hard refresh your browser and clear your cache is sort of general first-aid you can try.
Had tried from more Than one device and also from private mode windows in browser
Do you use host name or IP in the URL? An IP is not subject to the Duplicati name check.
The error for a name check problem is different now for some reason. I can repro this with
127.0.0.1 localhost-duplicati
in my Windows hosts file, and I can avoid the error by typing 127.0.0.1 instead of the name.
EDIT 1:
But 2.0.9.101 would have said:
which is why I didn’t recognize the new error, but the web server code has just been redone.
I just use ipadress:port it’s just for backing up my home lab stuff
Then this might be a different problem than the suggested solution in this topic had in mind:
and I’m also wondering if the option name change was intentional. From the server help text:
2.0.9.101
--webservice-allowed-hostnames: The hostnames that are accepted, separated with semicolons. If any of the hostnames are "*", all hostnames are allowed and the hostname checking is disabled.
2.0.9.102
--webservice-allowedhostnames: The hostnames that are accepted, separated with semicolons. If any of the hostnames are "*", all hostnames are allowed and the hostname checking is disabled.
You might need to go back to 2.0.9.101, or wait for the right developer to figure this out further.
--webservice-interface: The interface the webserver listens on. The special values "*" and "any" means any interface. The special value "loopback" means the loopback adapter.
should be required (even before) to even get a response from Duplicati from another device, otherwise the network traffic can’t even get into any interface (as only loopback will be used).
Is this a clear network path to Duplicati at its usual ports such as 8200? Sometimes people set reverse proxies which rewrite addresses and change ports to give a nice outward appearance. Proxy might also come out over localhost, therefore avoiding the lack of any other interface up, however if proxy is adding a host header, then possibly it’s still a problem with that host header.
Although question is still of some interest, I can repro with ipaddress:8200 from a Linux VM into Windows 10 Duplicati.Server.exe --webservice-interface=*, starting from the first HTTP request. Browser developer tools makes this pretty easy to see, at least from the browser Network view.
Adding (accidentally?) renamed --webservice-allowed-hostnames=* resolved the 400 error.
So possibly if it’s absolutely necessary to remain on 2.0.9.102, you can fight with Docker further.
possibly would be better like
CLI_ARGS="--webservice-allowed-hostnames=*"
but I don’t use Docker, and am also not familiar with LSIO.
Direct path no reverse proxy, CLI_ARGS=“–webservice-allowed-hostnames=*” do not solve.
Sorry, I intended the new name without the old dash. It’s too bad it doesn’t flag bad names…
CLI_ARGS="--webservice-allowedhostnames=*"
Anyway, to settle the question of whether there’s a bum host header, tcpdump output shows:
14:30:32.860296 enp0s3 Out IP linuxmint21.lan.49946 > hp4.lan.8200: Flags [P.], seq 1:413, ack 1, win 501, length 412
E.....@.@.....Vh..VQ.. ....Q..=.P.../...GET / HTTP/1.1
Host: 192.168.86.81:8200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: default-theme=ngax
Upgrade-Insecure-Requests: 1
Priority: u=0, i
14:30:32.860989 enp0s3 In IP hp4.lan.8200 > linuxmint21.lan.49946: Flags [P.], seq 1:463, ack 413, win 4104, length 462
E...I.@....v..VQ..Vh .....=.....P.......HTTP/1.1 400 Bad Request
Content-Length: 334
Content-Type: text/html
Date: Sat, 03 Aug 2024 18:30:32 GMT
Server: Kestrel
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></ HEAD >
<BODY><h2>Bad Request - Invalid Hostname</h2>
<hr><p>HTTP Error 400. The request hostname is invalid.</p>
</BODY></HTML>
Settings in Duplicati (in the manual anyway) says:
Code looks like it’s been extensively changed in the process of moving to the new web server.
I know where the old check was, but the new layout is far different, so I haven’t found new yet.
Excellent detective work! The change was not intentional, and I was not aware this had changed.
I will fix it to support both names for the option.