Environmental variable is wrong for WEBUI

[sgtwtf]

tried to change the WEBUI port with WEBUI_PORT_ENV=8081 and i was not able to access it. When i changed the Variable name to just WEBUI_PORT=8081 as I have see with other QBT docker images it worked.

[chrisjohnson00]

You are correct sir! Seems the docs are out of date. I'm not sure this repo is maintained anymore, but you could PR the readme changes yourself and see.

[aLTeReGo-SWI]

I encountered the same problem. I had to manually change the port the qBittorrent web interface was running on in the app, then call a custom script on container startup that opened the port configured in qBittorrent. In this case, it was port 9090. Then have the original container script called as part of your custom script at the end.

iptables -A OUTPUT -o eth0 -p tcp -m tcp --sport 9090 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 9090 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --sport 9090 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 9090 -j ACCEPT
/etc/openvpn/start.sh

There's no question this is a hack, but it's working great. OpenVPN is working fantastic within the container. Note to the maintainer of this repo, iptables is completely unnecessary here. Instead, all you need to do is bind the qBittorrent application to the tunnel adapter under advanced settings. This will ensure that all torrent traffic ONLY goes through the encrypted tunnel. If the tunnel is down, then qBittorent will stop downloading until the tunnel is brought back up. This is a much simpler and more elegant solution to iptables IMHO.

[istbarp]

Hi, I finally figured out what was wrong with this issue that alterego posted ( i couldn't connect at all to the web gui, but using the script above made me able to , at 8080). The reason why you have to do this is because the LAN_NETWORK variable is improperly configured.

I had the exact same issue and had to use the same script actually, i think you posted this earlier as well?

On my end the issue was the variable was inproperly configured, because i had used the 192.168.1.0/24 The server hosting this docker container is running 192.168.50.XX. After i've spent WEEKS! trying to figure out why i was having to do this, while on my friends pc, where i did the same setup, we didn't have to do this hack. Setting the LAN_NETWORK variable to 192.168.50.0/24 solved my issues and i now have proper access to the web gui. :)

Hope it solves your problem as well

[riekusr]

Thanks guys, for me it was also misconfiguration for the LAN_NETWORK variable. I had it set to my docker host network ip, but it needs a networkIp 'submask/? if i say that correctly.

So in my case, my OVM docker host had the IP: 192.168.1.100 and for the LAN_NEWORK setting in this container I used: 192.168.1.0/24

[istbarp]

Thanks guys, for me it was also misconfiguration for the LAN_NETWORK variable. I had it set to my docker host network ip, but it needs a networkIp 'submask/? if i say that correctly.

So in my case, my OVM docker host had the IP: 192.168.1.100 and for the LAN_NEWORK setting in this container I used: 192.168.1.0/24

You're welcome. I had to share because i had this trouble for weeks

[riekusr]

Thanks guys, for me it was also misconfiguration for the LAN_NETWORK variable. I had it set to my docker host network ip, but it needs a networkIp 'submask/? if i say that correctly. So in my case, my OVM docker host had the IP: 192.168.1.100 and for the LAN_NEWORK setting in this container I used: 192.168.1.0/24

You're welcome. I had to share because i had this trouble for weeks

It was down for me for weeks as well, couldn't figure it out easily.

[riekusr]

I still have the problem that I can access all my containers trought the hostname like nas:8080 but that doesn't work with only the qbittorrent container.

I have everything set in a tailscale network.