I successfully changed the default web UI port to '9090' after adding a manual port configuration to set the new port on both the host and container side. The web UI is now available under 'http://<local-ip>:9090'.

 

I also changed the actual 'WebUI' configuration field (hidden behind 'Advanced View') to match the new port, in order for the 'WebUI' option in the Unraid context menu on the qbittorrent container to point to the new location, but this change seems to just get ignored. I tried to change this option on some other containers and they update just fine. I can put in 'https://google.com' and they happily link to that.

 

I rebooted the array/server a couple of times to make sure, but the qbitorrent container context menu always points to 'http://<local-ip>:8080'. The 'WebUI' option doesn't get reset and stays on whatever I last set it to, but it's just ignored.

 

 

 

Edited September 27, 20214 yr by guyyst
missing word

12 hours ago, guyyst said:

I successfully changed the default web UI port to '9090' after adding a manual port configuration to set the new port on both the host and container side. The web UI is now available under 'http://<local-ip>:9090'.

 

I also changed the actual 'WebUI' configuration field (hidden behind 'Advanced View') to match the new port, in order for the 'WebUI' option in the Unraid context menu on the qbittorrent container to point to the new location, but this change seems to just get ignored. I tried to change this option on some other containers and they update just fine. I can put in 'https://google.com' and they happily link to that.

 

I rebooted the array/server a couple of times to make sure, but the qbitorrent container context menu always points to 'http://<local-ip>:8080'. The 'WebUI' option doesn't get reset and stays on whatever I last set it to, but it's just ignored.

 

 

 

I don’t believe these changes will effect the webUI link in the docker tab (didn’t for me anyway). Only the app itself. Your best bet would be to manually enter the IP:port in your browser and bookmark it.

10 hours ago, wgstarks said:

I don’t believe these changes will effect the webUI link in the docker tab (didn’t for me anyway). Only the app itself. Your best bet would be to manually enter the IP:port in your browser and bookmark it.

 

From the description I feel like that's exactly what this setting is for: 

 

Again, my other docker containers behave exactly the way this description says they should, qbitorrent is the only outlier so far.

Of course this isn't a huge deal, and a bookmark is an O.K. workaround, it's just a bit irksome when I know that 1 out of my 10 containers is always slightly wrong :p

3 hours ago, guyyst said:

 

From the description I feel like that's exactly what this setting is for: 

 

Again, my other docker containers behave exactly the way this description says they should, qbitorrent is the only outlier so far.

Of course this isn't a huge deal, and a bookmark is an O.K. workaround, it's just a bit irksome when I know that 1 out of my 10 containers is always slightly wrong 😛

 

Alright I figured it out, kind of. I did a grep through all the config files in the 'dockerMan' folder to find where '8080' might still be listed. It was still set as the default value for the WEBUI_PORT variable, so I changed that to 9090 as well. After that I could set the 'WebUI' to whatever I want. (Even a hard coded link like 'https://google.com', which... why was that previously prevented by an old default port in WEBUI_PORT ?)

 

Also, changing the default value of WEBUI_PORT back to 8080 doesn't get me back into the broken state I was in before.

 

So I really don't know what was going on there, but for anyone else having trouble with this, try changing the default value of WEBUI_PORT ¯\_(ツ)_/¯

 

On 9/27/2021 at 9:36 PM, guyyst said:

 

Alright I figured it out, kind of. I did a grep through all the config files in the 'dockerMan' folder to find where '8080' might still be listed. It was still set as the default value for the WEBUI_PORT variable, so I changed that to 9090 as well. After that I could set the 'WebUI' to whatever I want. (Even a hard coded link like 'https://google.com', which... why was that previously prevented by an old default port in WEBUI_PORT ?)

 

Also, changing the default value of WEBUI_PORT back to 8080 doesn't get me back into the broken state I was in before.

 

So I really don't know what was going on there, but for anyone else having trouble with this, try changing the default value of WEBUI_PORT ¯\_(ツ)_/¯

 

This problem has been vexing me all day as well; I'm glad I'm not the only one. 

 

I can't get this to work even if I change the default value of WEBUI_PORT. I'm beginning to suspect there is something odd in this particular Docker image that is forcing all Unraid WebUI GUI links to the default IP:8080 regardless of the link specified in the Advanced view of the Docker configuration page.

 

My goal: Multiple instances of binhex-qbittorrentvpn, each using a different port for their respective WEBUIs.

 

I can get the WebUI to be active on a non-default port by doing the following:

1. Delete Host Port 3 (default 8080:8080)

2. Add new TCP mapping [newport]:[newport]

3. Change WEBUI_PORT to [newport]

 

But regardless of what I change in the WebUI field (Unraid advanced view), the Unraid GUI link redirects me to IP:8080. The only exception is if I manually map container port 8080 to [new port], in which case I get linked to IP:[new port]. But since the container requires a [newport]:[newport] mapping for the WebUI to function, I can't add a second mapping of 8080:[new port] to force the link in the Unraid GUI to work properly.

 

The field just doesn't seem to change even if I hard code the WebUI link to http://[IP]:[newport] or change it to http://google.com. Other containers let me change the WebUI link to literally anything I want, which leads me to believe this has something to do with this specific container. I can't find anything in the dockerMan XML file referencing port 8080 so it's got to be somewhere deeper. 

 

Yes I could just bookmark the individual links and never access them via the Unraid Docker page, but it would really be nice to have so that in the future I don't have to reinvent the wheel if I ever lose track of which ports I used.

 

I'd love to help troubleshoot this because I'm at my wit's end trying to get this to work and am pretty close to giving up and just using binhex-rtorrentvpn.

9 hours ago, exces6 said:

But regardless of what I change in the WebUI field (Unraid advanced view), the Unraid GUI link redirects me to IP:8080.

 

doesnt this work?, left click container icon select edit, then toggle to 'advanced view' (top right) and then change the value for 'WebUI' to 'http://[IP]:[PORT:<port number you want>]/' click on apply at the bottom.

16 hours ago, exces6 said:

I'd love to help troubleshoot this because I'm at my wit's end trying to get this to work and am pretty close to giving up and just using binhex-rtorrentvpn.

I edited the file on the flash as @guyyst suggested. /config/plug-ins/dockerMan/templates-user/my-binhex-qbittorrentvpn.xml.

<Variable>
      <Value>8088</Value>
      <Name>WEBUI_PORT</Name>
      <Mode/>
</Variable>

I’m using 8088. You should enter the appropriate port number. Then reboot your server.

 

Edit: Instead of a reboot you need to update the docker settings. Just make any change in the settings and then revert it then click “apply”.

Edited September 30, 20214 yr by wgstarks

6 hours ago, binhex said:

 

doesnt this work?, left click container icon select edit, then toggle to 'advanced view' (top right) and then change the value for 'WebUI' to 'http://[IP]:[PORT:<port number you want>]/' click on apply at the bottom.

 

It seems to accept this input and the XML file under dockerMan/templates-user saves the desired input correctly (unlike some posters above), but the generated link in the Unraid GUI still sticks to 8080.

 

 <WebUI>http://[IP]:[PORT:8089]/</WebUI>

 <Variable>
      <Value>8089</Value>
      <Name>WEBUI_PORT</Name>
      <Mode/>
</Variable>  

<Config Name="8089" Target="8089" Default="8089" Mode="tcp" Description="Container Port: 8089" Type="Port" Display="always" Required="true" Mask="false">8089</Config>

 

 

This persists even with a complete Unraid reboot as suggested by wgstarks.

 

Edited September 30, 20214 yr by exces6
add link photo

Just now, exces6 said:

 

It seems to accept this input and the XML file under dockerMan/templates-user saves the desired input correctly (unlike some posters above), but the generated link in the Unraid GUI still sticks to 8080.

 

 <WebUI>http://[IP]:[PORT:8089]/</WebUI>

 <Variable>
      <Value>8089</Value>
      <Name>WEBUI_PORT</Name>
      <Mode/>
</Variable>  

<Config Name="8089" Target="8089" Default="8089" Mode="tcp" Description="Container Port: 8089" Type="Port" Display="always" Required="true" Mask="false">8089</Config>

 

This persists even with a complete Unraid reboot as suggested by wgstarks.

 

I posted that wrong. Was just working on an edit when I saw your reply.

 

Instead of a reboot you need to update the docker settings. Just make any change in the settings and then revert it then click “apply”.

2 minutes ago, wgstarks said:

I posted that wrong. Was just working on an edit when I saw your reply.

 

Instead of a reboot you need to update the docker settings. Just make any change in the settings and then revert it then click “apply”.

 

I've tried this too (that's what I was doing at first), but no luck.

 

I even just tried manually editing the XML to something random for testing purposes (http://www.google.com) but Unraid still forces IP:8080 in the context menu.

Been trying to fellow the video below. but as you can see in the picture i dont have the bittorrent config file. only folder i have inside bittorrent is for openvpn and its empty   <---im a dumbass

 

Edited the qbittorrent config file adding the line from the video. still can access webui and log just keeps spitting out e":"No such container: 31b1f9d436e2"}

 

 

 

 

 

 

 

Edited October 10, 20214 yr by Razielxv

My container crapped out all of a sudden. It seems DNS resolution is no longer working and the status for every tracker is "Not working".

I'm using WireGuard via Mullvad. I've rebooted the server and my router. I've generated new WireGuard config files from Mullvad and verified they're unchanged.

 

I've attached my debug log. Any ideas?

 

supervisord.log

Edited October 10, 20214 yr by KnifeFed

1 hour ago, KnifeFed said:

My container crapped out all of a sudden. It seems DNS resolution is no longer working and the status for every tracker is "Not working".

I'm using WireGuard via Mullvad. I've rebooted the server and my router. I've generated new WireGuard config files from Mullvad and verified they're unchanged.

 

I've attached my debug log. Any ideas?

 

supervisord.log 20.53 kB · 1 download

i see this specified in your wireguard conf file, from your log:-

DNS = 193.138.218.74

perhaps there is an issue with this name server (assuming its mullvad?), try removing that line from your wireguard conf file, this should then force use of the nameservers defined via NAME_SERVERS env var.

10 minutes ago, binhex said:

i see this specified in your wireguard conf file, from your log:-

DNS = 193.138.218.74

perhaps there is an issue with this name server (assuming its mullvad?), try removing that line from your wireguard conf file, this should then force use of the nameservers defined via NAME_SERVERS env var.

Yup, that's the Mullvad DNS server. I removed it and set NAME_SERVERS to "1.1.1.1,1.0.0.1" but got pretty much the same result.

 

supervisord2.log

13 minutes ago, KnifeFed said:

Yup, that's the Mullvad DNS server. I removed it and set NAME_SERVERS to "1.1.1.1,1.0.0.1" but got pretty much the same result.

 

supervisord2.log 19.28 kB · 0 downloads

hmm ok i can only assume isues with the endpoint you are attempting connection to, try a different endpoint.

24 minutes ago, binhex said:

hmm ok i can only assume isues with the endpoint you are attempting connection to, try a different endpoint.

This is what I did initially, i.e. tried a whole bunch of endpoints with the same result, leading me to believe it wasn't an issue with the endpoints, especially seeing as they all have an online status on the Mullvad website. However, now I tried a bunch again and suddenly one worked. I guess Mullvad has been experiencing some weird issues today. Thanks for your help troubleshooting!

Hey folks, I'm really struggling here. First time setup. Everything looks like it's working well, torrents are downloading fine, but they aren't uploading. I believe the ports are forwarded correctly (using PIA on a port forwarding enabled server [Montreal]) and I'm not seeing any errors in the supervisord.log file. I'm hoping someone can point out what I'm doing wrong. Let me know if more info is needed.

supervisord - Copy.log

Hello everyone, hope you're all well.

 

I'm having an issue with this docker container. Until a few days ago, I could access the webui while away from home by way of the Wireguard access server built into Unraid. Lately though, requests to the webui are timing out, but only when Wireguarding into my home. If I'm not on Wireguard but am connected to my home wi-fi, I can reach the webui just fine. It's not a firewall issue; if I change the port of for example Radarr to 8080, it connects fine, even through Wireguard. So it seems to be the QBVPN docker that's giving clients the cold shoulder if they VPN into the home via Wireguard. Can anyone help me out with regards to what changed or what I need to change to give my away-from-home devices the green light?

 

Many thanks.

17 hours ago, exlibermortis said:

Hey folks, I'm really struggling here. First time setup. Everything looks like it's working well, torrents are downloading fine, but they aren't uploading. I believe the ports are forwarded correctly (using PIA on a port forwarding enabled server [Montreal]) and I'm not seeing any errors in the supervisord.log file. I'm hoping someone can point out what I'm doing wrong. Let me know if more info is needed.

supervisord - Copy.log 82 kB · 0 downloads

Update: I used https://www.yougetsignal.com/tools/open-ports/ as recommended in the FAQ to check to see if the port autoconfigured by PIA is open and it is not. How do I resolve this? Thanks for any help anyone can provide!

9 hours ago, thatsthefrickenlightning said:

Hello everyone, hope you're all well.

 

I'm having an issue with this docker container. Until a few days ago, I could access the webui while away from home by way of the Wireguard access server built into Unraid. Lately though, requests to the webui are timing out, but only when Wireguarding into my home. If I'm not on Wireguard but am connected to my home wi-fi, I can reach the webui just fine. It's not a firewall issue; if I change the port of for example Radarr to 8080, it connects fine, even through Wireguard. So it seems to be the QBVPN docker that's giving clients the cold shoulder if they VPN into the home via Wireguard. Can anyone help me out with regards to what changed or what I need to change to give my away-from-home devices the green light?

 

Many thanks.

you need to add the wireguard assigned network to the value for env var LAN_NETWORK, using a comma to separate the values, so you should end up with LAN_NETWORK value defining your LAN and your wireguard network.

 

Long time user of this docker, but I just started using it with VPN and now my RSS feeds from jackett don't work.

 

Any idea if it is possible to have the VPN and RSS feeds from jackett docker??

10 hours ago, binhex said:

you need to add the wireguard assigned network to the value for env var LAN_NETWORK, using a comma to separate the values, so you should end up with LAN_NETWORK value defining your LAN and your wireguard network.

 

My hero. I saw the setting, but somehow forgot to fiddle with it. I feel a bit silly now. I've donated to you again. Thank you!

15 hours ago, exlibermortis said:

Update: I used https://www.yougetsignal.com/tools/open-ports/ as recommended in the FAQ to check to see if the port autoconfigured by PIA is open and it is not. How do I resolve this? Thanks for any help anyone can provide!

are you sure of this?, are you putting in the external ip and the port as shown in the supervisord.log?, you cannot enter in your isp's ip address as the port will not be shown as open.

Been using this for months without issue, and then the last few days I cannot access the UI after starting the docker.

 

I've tried renaming the appdata folder for it (copying the openvpn config into the new one it creates), and renaming the torrent and complete/incomplete folders in case that's a factor. Something weird is going on.

 

I've also tried with debug on but that doesn't yield any clues.

 

The last entry in the log is:

2021-10-15 11:45:33,020 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process started
[info] Waiting for qBittorrent process to start listening on port 8117...

2021-10-15 11:45:33,131 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process listening on port 8117

2021-10-15 11:45:33,155 DEBG 'watchdog-script' stdout output:
[debug] VPN incoming port is 54846
[debug] qBittorrent incoming port is 54846
[debug] VPN IP is 10.3.112.113
[debug] qBittorrent IP is 10.3.112.113

2021-10-15 11:45:33,628 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '54846'

2021-10-15 11:46:03,163 DEBG 'watchdog-script' stdout output:
[debug] Checking we can resolve name 'www.google.com' to address...

2021-10-15 11:46:03,190 DEBG 'watchdog-script' stdout output:
[debug] DNS operational, we can resolve name 'www.google.com' to address '142.250.187.228'

2021-10-15 11:46:03,191 DEBG 'watchdog-script' stdout output:
[debug] Waiting for iptables chain policies to be in place...

2021-10-15 11:46:03,200 DEBG 'watchdog-script' stdout output:
[debug] iptables chain policies are in place

 

Does anyone have any ideas?

Has there been a recent update that may have affected anything?

 

I am trying direct access, so no reverse proxy or anything like that to consider.

 

Cheers,

Pacman

 

 

PS: Oh, and if I access the console for the docker I cannot see anything going nuts in "top".

Edited October 15, 20214 yr by SudoPacman

48 minutes ago, SudoPacman said:

I've also tried with debug on but that doesn't yield any clues.

that looks like a clean start from the small snippet of the log you have provided, have you changed lan network range?, created more vlan's?, reconfigured firewall etc?.