1 hour ago, Axelfony said:

Hi there, thank you for providing this docker - worked for me flawlessly... until now

Do this:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

1 hour ago, binhex said:

Do this:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Thanks for getting back. See attached. I just compared to when it was working and it seems it is an issue with the port forwarding configuration? With VPN Port being different than qBittorrent incoming port 6881?

supervisord_new.log

Edited October 24, 20232 yr by Axelfony
More info provided

11 minutes ago, Axelfony said:

I just compared to when it was working and it seems it is an issue with the port forwarding configuration?

nope, nothing wrong with port forwarding according to your latest attached log, that is working as expected.

11 minutes ago, Axelfony said:

With VPN Port being different than qBittorrent incoming port 6881?

Incoming port is not defined at the container level, it is defined by your VPN provider, port 6881 is included as a incoming port if you do NOT use the VPN part of the image, i.e. VPN_ENABLED = no, which is not the case for you.

 

What is the IP address of the machine running the web browser that you are using to attempt connection to the web ui? is it 192.168.178.xxx ?

55 minutes ago, binhex said:

nope, nothing wrong with port forwarding according to your latest attached log, that is working as expected.

Incoming port is not defined at the container level, it is defined by your VPN provider, port 6881 is included as a incoming port if you do NOT use the VPN part of the image, i.e. VPN_ENABLED = no, which is not the case for you.

 

What is the IP address of the machine running the web browser that you are using to attempt connection to the web ui? is it 192.168.178.xxx ?

That is correct Sir. Machine is reachable via 192.168.178.2 and according to my understanding 192.168.178.2:8080 should be Bittorrent. Container is configured using bridge network:

31 minutes ago, Axelfony said:

and according to my understanding 192.168.178.2:8080 should be Bittorrent

that SHOULD get you access to the web ui as long as you didn't change the value for env var 'WEBUI_PORT', this is set to 8080, correct?.

1 hour ago, binhex said:

that SHOULD get you access to the web ui as long as you didn't change the value for env var 'WEBUI_PORT', this is set to 8080, correct?.

That is correct! Both are set to 8080, as you can see from the docker screen, here also the container config:

 

From my logs when it worked, I got the message that the process has started listening on port 8080:

2023-05-21 04:41:48,976 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process started
[info] Waiting for qBittorrent process to start listening on port 8080...

2023-05-21 04:41:49,198 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process listening on port 8080

2023-05-21 04:41:49,201 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Privoxy...

2023-05-21 04:41:50,209 DEBG 'watchdog-script' stdout output:
[info] Privoxy process started
[info] Waiting for Privoxy process to start listening on port 8118...

2023-05-21 04:41:50,214 DEBG 'watchdog-script' stdout output:
[info] Privoxy process listening on port 8118

 

But this does not happen now, he is somehow stuck at: 

[info] Waiting for qBittorrent process to start listening on port 8080...

 

Do you know of any additional possibilities/options to check, why the process does not start listening besides enabling debug function?

@binhex Just wanted to first say thanks for your work and your support.

 

I too was having issues since last night (my system auto-updated my containers for the month).  It looks like qtbitorrent was updated to 4.6, which im guessing needs whitelisted on one of the trackers I use.  I downgraded to last version, and all is well.  @Axelfony have you tried downgrading by chance?

 

I used: binhex/arch-qbittorrentvpn:4.5.5-1-04 

and it's working again.

(found on https://github.com/binhex/arch-qbittorrentvpn/releases)

9 minutes ago, Axelfony said:

But this does not happen now, he is somehow stuck at: 

Ha yes you are quite right, it does appear that qbittorrent process has not started, the config of the port was fooling me here, OK so most probably a config related issue, you could try restoring your config from a backup from when it was working, or simply let qbittorrent re-create the default, if you want to do this then simply rename the file /config/qbittorrent/config/qBittorrent.conf and then restart the container to re-generate the file, you will then need to reconfigure again of course but i expect it will get you access again.

11 minutes ago, MisterLas said:

@binhex Just wanted to first say thanks for your work and your support.

 

I too was having issues since last night (my system auto-updated my containers for the month).  It looks like qtbitorrent was updated to 4.6, which im guessing needs whitelisted on one of the trackers I use.  I downgraded to last version, and all is well.  @Axelfony have you tried downgrading by chance?

 

I used: binhex/arch-qbittorrentvpn:4.5.5-1-04 

and it's working again.

(found on https://github.com/binhex/arch-qbittorrentvpn/releases)

 

Thanks @MisterLas - downgrade worked. Also the suggestion of Binhex did the trick for 4.6! You can also give it a try.

 

7 minutes ago, binhex said:

Ha yes you are quite right, it does appear that qbittorrent process has not started, the config of the port was fooling me here, OK so most probably a config related issue, you could try restoring your config from a backup from when it was working, or simply let qbittorrent re-create the default, if you want to do this then simply rename the file /config/qbittorrent/config/qBittorrent.conf and then restart the container to re-generate the file, you will then need to reconfigure again of course but i expect it will get you access again.

 

@binhex Thanks for the hint! Process started again and the initial credentials were working.

4 minutes ago, Axelfony said:

 

Thanks @MisterLas - downgrade worked. Also the suggestion of Binhex did the trick for 4.6! You can also give it a try.

 

@binhex Thanks for the hint! Process started again and the initial credentials were working.

 

Awesome.  Thanks for confirming that config update as well.  I'll give that a shot tonight. 

7 hours ago, binhex said:

looks like permissions related issue, from your snippet above:-
 

cannot touch '/tmp/dnsfailure': Permission denied

 

from your supervisord log i think you have dns set to an internal name server which results in name lookup failure:-
 

nameserver 10.128.0.1

set NAME_SERVERS to the default values:- 

NAME_SERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1

 

Thanks for getting back to me! Really appreciate it. I thought the same about the permissions issues, but as far as I can tell the permissions are properly configured- everything inside my /config belongs to the docker user/their group and I'm running with privileged: true.  My name servers were also set to the values you've mentioned here.

The lines that stick out to me from my supervisord.log file are a bunch of:
 

qbit-vpn | sed: cannot rename /config/wireguard/sedYuVf6t: Device or resource busy
qbit-vpn |
qbit-vpn |
qbit-vpn  | 2023-10-24 12:00:34,626 DEBG 'start-script' stderr output:
qbit-vpn  | sed: cannot rename /config/wireguard/sedhqJ868: Device or resource busy
qbit-vpn  |
qbit-vpn  |
qbit-vpn  | 2023-10-24 12:00:34,630 DEBG 'start-script' stderr output:
qbit-vpn  | sed: cannot rename /config/wireguard/sedRTHJaC: Device or resource busy
qbit-vpn  |
qbit-vpn  |
qbit-vpn  | 2023-10-24 12:00:34,634 DEBG 'start-script' stderr output:
qbit-vpn  | sed: cannot rename /config/wireguard/sedxYdLDW: Device or resource busy

In case this helps, I'm running the container on Synology DSM 7.2 through docker compose. I can paste my compose file if that helps at all!

I also tried downgrading to no success 😕

Edited October 24, 20232 yr by gray-pouch1731

Hi, if I need to create a second instance of the qbittorent docker what is the recommendation route the vpn (Airvpn) through the first instance or connect separately both instances? this because I made some tests route through the qbittorrent vpn but I noted that the connection is very unstable or I don't know if I'm missing something or some configuration can be wrong.  anyway I attached my supervisor log if anyone can help me with this.

 

Thanks

supervisord.log

Just wanted to update, I solved the problem!!

Turns out something was up with my wg0.conf file. I regenerated the configuration from my VPN (AirVPN), and the endpoint had changed on me. My wg0.conf file has a bunch of extra Synology stuff going on in it, ( I think I followed this guide a couple months ago), but long story short I just had to update the endpoint.

Just in case anyone else ends up here with a Synology device and is using AirVPN, make sure to change the endpoint they provide with their generated config into an ip address (I used nslookup).

Thanks again for your attention!

I have used this docker for a long time now. But last weekend, I suddenly found out that the docker is downloading very slow. b/s to kb/s where I used to have mb/s

I haven't changed anything.

I installed deluge (which I have used earlier) and here the download is full speed (or at leass doesnt have problems)

I use PIA and I have tried with both openvpn and wireguard, and also four different torrent sites.

 

If anyone could help me with problem solving, it would be nice. If I need to upload any log or similar just let me know. I'm downloading to cache drive.

Is there way to create a torrent and add tracker, this seems to be missing or am I being blind?

is mullvadvpn a good option still? I saw they removed port forwarding. 

Hello,

 

would it be possible to add the functionality to use a dedicated IP bought from PIA for this container?

Apparently someone posted a way to get the dedicated IP working with custom Wireguard config in a relevant issue on the PIA GitHub: https://github.com/pia-foss/manual-connections/issues/84#issuecomment-1055106327

Any possibility this could be integrated? And also, would you accept a pull request integrating this?

I have two isntances of the same binex qbittorrrentvpn instances running. Today one of them does not let me get to the webui (connection timeout). I know it's working because there is a valid vpn connection. logs look flawless. what could be the issue?

On 11/9/2023 at 1:45 AM, vulu said:

I have two isntances of the same binex qbittorrrentvpn instances running. Today one of them does not let me get to the webui (connection timeout). I know it's working because there is a valid vpn connection. logs look flawless. what could be the issue?

no idea without a log file, do this:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

I am trying to use this docker with a VPN/tracker combo that requires you to run a short script that passes a cookie value to the tracker to identify you when the IP changes. Not gonna name the tracker, but the ID is called the MAM. The site has produced a rough outline of how to do this by storing the value in a cookie in a docker persistent volume, but this has kinda defeated my google-fu. Has anyone done anything similar? 

 

The guide outlines how to run a short script that looks like this:

 

/path/docker/persists/tun_up.sh

#!/bin/bash
curl -c /path/docker/persists/mam.cookies -b /path/docker/persists/mam.cookies https://asite.com/dynamic.php

 

Can anyone translate that into what I need to do with qBitTorrentVPN?

 

I'm familiar with the shell, etc, but this Docker stuff with different file paths, persistant and non-persistant volumes is making my brain hurt.

Hello!

I'm having a similar issue to others in this thread. Qbittorrentvpn worked fine until a few days ago and hangs on webui login when VPN is enabled, using mullvad as a provider. Haven't changed anything since it last worked except making sure nameservers were set to default and changing VPN points.

supervisord.log

2 hours ago, Kaguyan said:

Hello!

I'm having a similar issue to others in this thread. Qbittorrentvpn worked fine until a few days ago and hangs on webui login when VPN is enabled, using mullvad as a provider. Haven't changed anything since it last worked except making sure nameservers were set to default and changing VPN points.

supervisord.log 183.35 kB · 1 download

Looks like a network issue. You have DNS errors repeating in your log.

Quote

2023-11-10 15:36:33,461 DEBG 'start-script' stdout output: [debug] Having issues resolving name 'www.google.com' [debug] Retrying in 5 secs... [debug] 11 retries left 2023-11-10 15:36:44,568 DEBG 'watchdog-script' stdout output: [debug] Having issues resolving name 'www.google.com' [debug] Retrying in 5 secs... [debug] 9 retries left

 

did you ever get it to work? I might try it this weekend @wgstarks

 

Edited November 11, 20232 yr by fiscal-master5592

6 hours ago, fiscal-master5592 said:

did you ever get it to work? I might try it this weekend @wgstarks

 

Did I ever get what to work? If you’re referring to this docker then yes. It’s been working for me for several years.

Hello!

 

I tried using this container as a network for another however it appears the it blocks the LAN network (can ping items but not get to them). For example I put Lidarr  to use the container as it's network (which works) but now Lidarr cannot access the local clients. I tried "curl http://LAN_address:port" and it times out - is this normal?

 

Thanks!