17 hours ago, wgstarks said:

And you are attempting to connect via you LAN?

Yes sorry over LAN is correct. hardwired from local desktop all the way to the server.

Having an issue with accessing the GUI menu.

Unraid had an issue where I needed to shutdown the server and restart it. 

The container clearly works, as I can see my items being seeded (from a private tracker's website), showing the items are indeed being seeded through the container. 

However, any attempts to access the GUI no longer work, whereas they worked before.

How would I go about troubleshooting this at all? Not sure where to start since it worked before, so it was configured correctly (I don't see any changes). Could I just need to uninstall and reinstall the container to fix things? I forced an update already to no avail. 

Thank you in advance.

EDIT: I swapped it to OpenVPN and it works, but with wireguard, it no longer works. Could something of been corrupted with the Wireguard file in my configuration folder? I tried swapping to a different wg0.conf server like ca-vancouver to no avail as well.

Edited January 16, 20251 yr by StabbyMeowkins

3 hours ago, StabbyMeowkins said:

Having an issue with accessing the GUI menu.

Unraid had an issue where I needed to shutdown the server and restart it. 

The container clearly works, as I can see my items being seeded (from a private tracker's website), showing the items are indeed being seeded through the container. 

However, any attempts to access the GUI no longer work, whereas they worked before.

How would I go about troubleshooting this at all? Not sure where to start since it worked before, so it was configured correctly (I don't see any changes). Could I just need to uninstall and reinstall the container to fix things? I forced an update already to no avail. 

Thank you in advance.

EDIT: I swapped it to OpenVPN and it works, but with wireguard, it no longer works. Could something of been corrupted with the Wireguard file in my configuration folder? I tried swapping to a different wg0.conf server like ca-vancouver to no avail as well.

 

On 11/10/2018 at 3:39 PM, binhex said:

Need further help?, please >click< here and follow the instructions.

 

I seem to be having an issue with port forwarding that I can't resolve after a few hours of troubleshooting. I've followed the relevant question 31 in the FAQ and configured it to the best of my knowledge according to the documentation. 

I use ProtonVPN: both OVPN and WireGuard VPN configurations work great with the exception of port forwarding. My WireGuard configuration has port forwarding enabled, confirmed by the wg0 config, and my user has the appropriate +pmp appended. 

Without STRICT_PORT_FORWARD enabled, I can see the following in the logs:
 

[info] Port forwarding is not enabled

 

This is my primary issue that I'd like to understand a bit better. I'm not sure where how this determination is made.  I have enabled port forwarding enabled from ProtonVPN, it's set in my wg0, the server supports it, and my user is appended with the correct flag/identifier for port forwarding. 

 

Doing some more tinkering, I came across this: 

With STRICT_PORT_FORWARD enabled, I can see some other things in the debug logs which appear to be doing some port assignment from ProtonVPN.
 

2025-01-16 22:13:57,120 DEBG 'start-script' stdout output:
initnatpmp() returned 0 (SUCCESS)
using gateway : 10.2.0.1
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned 0 (OK)
Public IP address : <redacted>
epoch = 4978682
closenatpmp() returned 0 (SUCCESS)

2025-01-16 22:13:57,121 DEBG 'start-script' stdout output:
[debug] Running infinite while loop to keep assigned incoming port for ProtonVPN live...

2025-01-16 22:13:57,272 DEBG 'start-script' stdout output:
[debug] ProtonVPN assigned incoming port is '50862'

Cursory port-forwarding checks while running in this configuration came up with the particular port being closed. Also, with STRICT_PORT_FORWARD enabled, I am unable to access the GUI--this is likely a separate issue. 

Should STRICT_PORT_FILTERING have any bearing on an ProtonVPN setup?  As I understand, the STRICT_PORT_FILTERING is a setting relevant to PIA. 

I'd appreciate any help that someone could offer. I think this is my 3rd time trying to get port forwarding up and running and am still having little luck. 

5 hours ago, Nickatony said:

I seem to be having an issue with port forwarding that I can't resolve after a few hours of troubleshooting. I've followed the relevant question 31 in the FAQ and configured it to the best of my knowledge according to the documentation. 

I use ProtonVPN: both OVPN and WireGuard VPN configurations work great with the exception of port forwarding. My WireGuard configuration has port forwarding enabled, confirmed by the wg0 config, and my user has the appropriate +pmp appended. 

Without STRICT_PORT_FORWARD enabled, I can see the following in the logs:
 

[info] Port forwarding is not enabled

 

This is my primary issue that I'd like to understand a bit better. I'm not sure where how this determination is made.  I have enabled port forwarding enabled from ProtonVPN, it's set in my wg0, the server supports it, and my user is appended with the correct flag/identifier for port forwarding. 

 

Doing some more tinkering, I came across this: 

With STRICT_PORT_FORWARD enabled, I can see some other things in the debug logs which appear to be doing some port assignment from ProtonVPN.
 

2025-01-16 22:13:57,120 DEBG 'start-script' stdout output:
initnatpmp() returned 0 (SUCCESS)
using gateway : 10.2.0.1
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned 0 (OK)
Public IP address : <redacted>
epoch = 4978682
closenatpmp() returned 0 (SUCCESS)

2025-01-16 22:13:57,121 DEBG 'start-script' stdout output:
[debug] Running infinite while loop to keep assigned incoming port for ProtonVPN live...

2025-01-16 22:13:57,272 DEBG 'start-script' stdout output:
[debug] ProtonVPN assigned incoming port is '50862'

Cursory port-forwarding checks while running in this configuration came up with the particular port being closed. Also, with STRICT_PORT_FORWARD enabled, I am unable to access the GUI--this is likely a separate issue. 

Should STRICT_PORT_FILTERING have any bearing on an ProtonVPN setup?  As I understand, the STRICT_PORT_FILTERING is a setting relevant to PIA. 

I'd appreciate any help that someone could offer. I think this is my 3rd time trying to get port forwarding up and running and am still having little luck. 

 

On 11/10/2018 at 3:39 PM, binhex said:

Need further help?, please >click< here and follow the instructions.

 

13 hours ago, Nickatony said:

I seem to be having an issue with port forwarding that I can't resolve after a few hours of troubleshooting. I've followed the relevant question 31 in the FAQ and configured it to the best of my knowledge according to the documentation. 

I use ProtonVPN: both OVPN and WireGuard VPN configurations work great with the exception of port forwarding. My WireGuard configuration has port forwarding enabled, confirmed by the wg0 config, and my user has the appropriate +pmp appended. 

Without STRICT_PORT_FORWARD enabled, I can see the following in the logs:
 

[info] Port forwarding is not enabled

 

This is my primary issue that I'd like to understand a bit better. I'm not sure where how this determination is made.  I have enabled port forwarding enabled from ProtonVPN, it's set in my wg0, the server supports it, and my user is appended with the correct flag/identifier for port forwarding. 

 

Doing some more tinkering, I came across this: 

With STRICT_PORT_FORWARD enabled, I can see some other things in the debug logs which appear to be doing some port assignment from ProtonVPN.
 

2025-01-16 22:13:57,120 DEBG 'start-script' stdout output:
initnatpmp() returned 0 (SUCCESS)
using gateway : 10.2.0.1
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned 0 (OK)
Public IP address : <redacted>
epoch = 4978682
closenatpmp() returned 0 (SUCCESS)

2025-01-16 22:13:57,121 DEBG 'start-script' stdout output:
[debug] Running infinite while loop to keep assigned incoming port for ProtonVPN live...

2025-01-16 22:13:57,272 DEBG 'start-script' stdout output:
[debug] ProtonVPN assigned incoming port is '50862'

Cursory port-forwarding checks while running in this configuration came up with the particular port being closed. Also, with STRICT_PORT_FORWARD enabled, I am unable to access the GUI--this is likely a separate issue. 

Should STRICT_PORT_FILTERING have any bearing on an ProtonVPN setup?  As I understand, the STRICT_PORT_FILTERING is a setting relevant to PIA. 

I'd appreciate any help that someone could offer. I think this is my 3rd time trying to get port forwarding up and running and am still having little luck. 

Relevant logs attached -- apologies for the oversight.

binhex_qbit_command_execution_logs.txt binhex_qbit_supervisord_debug_logs.txt

I've been using rTorrent VPN for the last few years and am happy with it.  Unfortunately Binhex is no longer supporting that so I'm thinking I should migrate over here before it breaks and I'm left scrambling

 

I have a couple of questions about migrating over

 

I am using the rTorrentVPN without a VPN.  I don't remember the process to set that up without a VPN so would appreciate a refresher on that.  Is it as simple as just turning VPN off.  What about all of the VPN settings?  

 

When I clicked on the install tab it was telling me I had port conflicts.  It looks like it is trying to use the same port as Krusader for the UI.  I don't use Krusader very often so it's usually off.  Could I just make sure only one of these is running at a time or best to just swap the ports

 

When I look at the variables to be set I don't see a port for torrents.  Is that because it is set to go through a VPN?  If I'm not using a VPN do I need to specify a port, or port range for seeding and downloading?

 

Final question - Is there any tool out there that can easily copy the torrents and where they point to from rTorrent over to qBittorrent or am I going to have to do it one by one?

 

Sorry for some many questions, but I haven't installed any dockers for awhile and I think this is going to be a major undertaking so I want to get it right

I acknowledge that this might be a very basic question.  I'm very new to Unraid and docker.

 

When I'm in the qBittorrent WebUI and I click to "Add Torrent File" the "Browse" points to my local Windows PC, not my Unraid server.  Short of setting up an SMB share (which I've been struggling to get working), can I have "Add Torrent File" point to my Unraid storage?

7 minutes ago, ManosTheHands said:

When I'm in the qBittorrent WebUI and I click to "Add Torrent File" the "Browse" points to my local Windows PC

Are you running this docker on your Unraid server?

13 minutes ago, trurl said:

Are you running this docker on your Unraid server?

Yes, the qBittorrent docker is running on my Unraid server and I'm accessing it through the web UI on my Windows PC.

On 9/2/2020 at 6:07 PM, ThEdOtOr said:

 

Create a necessary folder in

 

\\yourservername\appdata\binhex-qbittorrentvpn\qBittorrent 

 

Create a folder called ssl

 

 

Open up terminal and type,

 

cd /mnt/user/appdata/binhex-qbittorrentvpn/qBittorrent/ssl

 

This will make it so the directory is now active.  

 

Now we can generate the self signed key and certificate pair.

 

In terminal add this command.

 

openssl req -new -x509 -nodes -out server.crt -keyout server.key

 

Answer the questions or press enter to leave blank.

You should now have two files in your ssl folder.

 

server.crt

server.key

 

Now go to your qbittorrent web-interface then open the Tools -> Options... in the menu bar (or click the screwdriver or cogwheel icon depending on your version), and click on the tab labelled WebUI. Enable HTTPS and add the location of the files.  

 

Add to the boxes,

 

/config/qBittorrent/ssl/server.crt

/config/qBittorrent/ssl/server.key

 

 

Close the page and edit the qbittorrent container in advance mode and on the line WebU:

 

Change http://[IP]:[PORT:8080] / to https://[IP]:[PORT:8080]/

 

 

when you go to the docker webui you will now see this page.

 

 

Select advanced and proceed to the docker login page, you will notice it still says not secure ( https:// ) don't worry thats because of the self signed certificate. 

Because its self signed its not been verified by a third party, so will show not secure ( to my knowledge ) 

 

Now when you click on register to handle magnets a pop up box will apper.

 

 

Click allow,

A pop up box ( user account control ) will open click yes to continue

you can now open magnets, that will open qbittorrent stright away with the necessary URL

 

Have tested this with Google Chrome and Microsoft Edge. 

 

Hope this makes sense.

 

 

I know this is an old post but i had this metadata problem. this seems to have fixed that problem. but i cant access the web ui anymore. i get this error: PR_END_OF_FILE_ERROR and firefox doesnt give me the option to allow the certificat the same in edge and brave... everything else seems to work fine. has someone an idea?

On 1/16/2025 at 3:52 AM, StabbyMeowkins said:

Having an issue with accessing the GUI menu.

Unraid had an issue where I needed to shutdown the server and restart it. 

The container clearly works, as I can see my items being seeded (from a private tracker's website), showing the items are indeed being seeded through the container. 

However, any attempts to access the GUI no longer work, whereas they worked before.

How would I go about troubleshooting this at all? Not sure where to start since it worked before, so it was configured correctly (I don't see any changes). Could I just need to uninstall and reinstall the container to fix things? I forced an update already to no avail. 

Thank you in advance.

EDIT: I swapped it to OpenVPN and it works, but with wireguard, it no longer works. Could something of been corrupted with the Wireguard file in my configuration folder? I tried swapping to a different wg0.conf server like ca-vancouver to no avail as well.

I'm having the same issue of not being able to access the GUI if using wireguard as the VPN. Anyone find a solution to this?

42 minutes ago, turt1e said:

I'm having the same issue of not being able to access the GUI if using wireguard as the VPN. Anyone find a solution to this?

There are many possible causes for this.

 

On 11/10/2018 at 3:39 PM, binhex said:

Need further help?, please >click< here and follow the instructions.

 

I am also not able to get to my GUI.  It seems to be working in the background though.  This was all working a few weeks ago, so an update seems to have broken it.  It was broken on unraid 6.12.10 and now on 7.  

 

qbitlog.txt supervisord.log

7 hours ago, sittingmongoose said:

 

I am also not able to get to my GUI

 

A few ideas-

Are you connecting from the LAN defined in the container settings?

 

Have you tried connecting using <IP>:<port number>?
 

Tried a different browser?

 

Using any content blockers?

 

Seeing any error messages?

 

Tried clearing the cache on your browser?

I have also lost access to the GUI. This appears to have happened immediately after updating to 6.12.15 from 6.12.14. I closed all my dockers before updating, qbittorrent was running no problem. Performed the update and rebooted, no other changes. Now I can't access the GUI, It just hangs regardless of using the IP or the host name. I'm going to have a fiddle around but just posting on here now in case this is a common issues following the recent update.

 

**EDIT** I've found the source of the issue, the container variable LAN_NETWORK was one octet out. I did change my network router but I did this literally months ago and this has been working fine incorrectly configured until the update! Not to mention the configuration that was in there didn't even match my old configuration! Odd one. But resolved now.

Edited January 26, 20251 yr by Poprin
Found the source of the issue.

3 hours ago, wgstarks said:

A few ideas-

Are you connecting from the LAN defined in the container settings?

 

Have you tried connecting using <IP>:<port number>?
 

Tried a different browser?

 

Using any content blockers?

 

Seeing any error messages?

 

Tried clearing the cache on your browser?

This site can’t be reached

192.xxx.xx.xxx took too long to respond.

Try:

Checking the connection

Checking the proxy and the firewall

ERR_CONNECTION_TIMED_OUT

 

 

Tried multiple computers, browsers and cleared cache and cookies.  Same result on all.  Yes I am trying to connect using the ip and port.  I also double checked the LAN in the config and it's as expected.

I have the container up and running well.

 

One nit I am trying to resolve: I use cross-seed. I have a post-download command to run a search, however, I need to specify container IP, hostname does not work.

 

Both containers (qbit and cross-seed) are on the same custom network. Other containers on the same network can reach cross-seed with its host name. I think this must have something to do with DNS. Is there a way to easily resolve this in a manner that is a best practice?

3 hours ago, sittingmongoose said:

This site can’t be reached

192.xxx.xx.xxx took too long to respond.

Try:

Checking the connection

Checking the proxy and the firewall

ERR_CONNECTION_TIMED_OUT

 

 

Tried multiple computers, browsers and cleared cache and cookies.  Same result on all.  Yes I am trying to connect using the ip and port.  I also double checked the LAN in the config and it's as expected.

Sorry, I’m out of ideas. The log shows a successful start and you say the container is running.

On 1/26/2025 at 2:39 PM, wgstarks said:

Sorry, I’m out of ideas. The log shows a successful start and you say the container is running.

I partially figured it out.  Don’t have a solution though.

 

Cloudflare rocket loader was stopping it from loading through reverse proxy.  Turning that off fixed it.

 

The other thing I can’t figure out is, I can’t access it through my local lan with the vpn enabled.  When I disable it, I can access qbit at 192.168.50.119:8080, but when I enable the vpn, it’s not working with the above error.  But the reverse proxy works fine.

40 minutes ago, sittingmongoose said:

I partially figured it out.  Don’t have a solution though.

 

Cloudflare rocket loader was stopping it from loading through reverse proxy.  Turning that off fixed it.

 

The other thing I can’t figure out is, I can’t access it through my local lan with the vpn enabled.  When I disable it, I can access qbit at 192.168.50.119:8080, but when I enable the vpn, it’s not working with the above error.  But the reverse proxy works fine.

Please see Q32 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

On 1/26/2025 at 11:12 AM, sittingmongoose said:

This site can’t be reached

192.xxx.xx.xxx took too long to respond.

Try:

Checking the connection

Checking the proxy and the firewall

ERR_CONNECTION_TIMED_OUT

 

 

Tried multiple computers, browsers and cleared cache and cookies.  Same result on all.  Yes I am trying to connect using the ip and port.  I also double checked the LAN in the config and it's as expected.

 

Okay this is gonna sound dumb but might apply? Is your desktop on the same VLAN as the server/docker?  If not, follow FAQ Q32 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

Turns out it doesn't matter if you have firewall rules set up to properly allow traffic across the VLANs, you have to append both the server/docker vlan AND the Dekstop vlan  in the config of the qbit docker to be able to hit the WebUI.

6 minutes ago, Tygerial said:

 

Okay this is gonna sound dumb but might apply? Is your desktop on the same VLAN as the server/docker?  If not, follow FAQ Q32 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

Turns out it doesn't matter if you have firewall rules set up to properly allow traffic across the VLANs, you have to append both the server/docker vlan AND the Dekstop vlan  in the config of the qbit docker to be able to hit the WebUI.

So I am accessing my server from the same network as my server.  I whitelisted my network in the LAN_Network setting.  Doing that loads the webgui via the IP...but only the login page.  I enter my cred, click login, and nothing happens.

2 hours ago, sittingmongoose said:

So I am accessing my server from the same network as my server.  I whitelisted my network in the LAN_Network setting.  Doing that loads the webgui via the IP...but only the login page.  I enter my cred, click login, and nothing happens.

Try whitelisting your LAN in qbit settings. This will skip the login when accessing from LAN.

appdata/binhex-qbittorrentvpn/qBittorrent/config

Edit WebUI\AuthSubnetWhitelistEnabled=  add your LAN (line 84 in my screenshot). Also be sure AuthSubnetWhitelistEnabled is set to true (line 85).

 

 

You should also ensure AlternativeUIEnabled is set to false (line 83).

 

Restart the container to apply the new settings.

Edited January 29, 20251 yr by wgstarks

Didn't work unfortunately.  It does skip the login screen now, but then it just doesn't load.