[Support] binhex - qBittorrentVPN

[whauk 4]

Thanks again, got it.

But then, just out of curiosity, since I have to remap both qBT paths to host paths (which do not come out of the box) - what is th "data" path for?

[binhex 974]

17 hours ago, whauk said:

Thanks again, got it.

But then, just out of curiosity, since I have to remap both qBT paths to host paths (which do not come out of the box) - what is th "data" path for?

you dont have to have separate container paths for incomplete and completed, you simply have incomplete and completed as sub folder under /data e.g.:-

 

/data/incomplete

/data/completed

 

simplez.

[Coolsaber57 7]

New Unraid/QbitVPN docker user here, I believe I have everything setup correctly (I am using a Windscribe VPN), but had a few questions:

 

How can I verify that VPN is running and that Qbit is connecting through it? (i.e. does Qbit need more configuration, or if OpenVPN is running and connected, is that sufficient)

 

Is there a way to change the link on the Docker page for "WebGUI" in the menu? It seems that's hard coded to 8080 (I use this port for Unraid's GUI).  EDIT: Figured this one out - had to change to Advanced to see the option to changes it.

 

In Qbit, it's set to save files to: "/config/qBittorrent/downloads/".  Do I need to manually change this to my Downloads folder?

 

Sorry for the dumb questions, I just haven't used this before and want to make sure I understand what I'm running before potentially exposing myself without the cover of a VPN for my Linux ISOs.

Edited December 11, 2018 by Coolsaber57

[trurl 1698]

19 minutes ago, Coolsaber57 said:

8080 (I use this port for Unraid's GUI)

Why?

[Coolsaber57 7]

3 minutes ago, trurl said:

Why?

2 reasons:

 

1. Habit. I'm used to using 8080 for admin GUI on other machines and wanted to remain consistent.

 

2. I plan on running an NGINX reverse proxy docker container as well, and I'd rather make the configuration of that docker less complicated (i know I can map port 80/443 to something else)

Edited December 11, 2018 by Coolsaber57

[H2O_King89 6]

Is there extraction for rar?

 

Also I got this working as a subdomain with nginx

 

        proxy_pass http://ip:port;
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
		proxy_hide_header   Referer;
		proxy_hide_header   Origin;
		proxy_set_header    Referer                 '';
		proxy_set_header    Origin                  '';
    }
}

 

Edited December 12, 2018 by H2O_King89

[binhex 974]

15 hours ago, Coolsaber57 said:

How can I verify that VPN is running and that Qbit is connecting through it?

see here Q2. under the delugevpn heading:-

https://forums.unraid.net/topic/44108-support-binhex-general/?tab=comments#comment-433613

 

15 hours ago, Coolsaber57 said:

Is there a way to change the link on the Docker page for "WebGUI" in the menu?

yes i think if you click on advanced view then from memory (no access to my server right now) you can edit the url.

 

15 hours ago, Coolsaber57 said:

In Qbit, it's set to save files to: "/config/qBittorrent/downloads/".  Do I need to manually change this to my Downloads folder?

only if you dont want it to save to that location.the choice is yours.

[ZataH 10]

8 hours ago, H2O_King89 said:

Is there extraction for rar?

Yes it is in the docker

I use this to extract to current folder:

/sbin/unrar x -r "%F/." "%F/"

 

[Chaos_Therum 0]

It's definitely something to do with the Deluge container that causes my issues. I can run Deluge on my desktop no problem something about the container my network doesn't like. But this is the wrong page for this. As I said I was misremembering it definitely wasn't the qbittorrent docker that was causing me issues.

[DarkKnight 6]

Updated the container, and when I restarted it, QB isn't running any more. Can't tell from the log what's wrong. After the initial startup, this just loops endlessly every couple minutes.

 

2018-12-29 12:05:14,449 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:14 2018 [UNDEF] Inactivity timeout (--ping-restart), restarting

2018-12-29 12:05:14,450 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:14 2018 SIGHUP[soft,ping-restart] received, process restarting

2018-12-29 12:05:14,450 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:14 2018 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6

Sat Dec 29 12:05:14 2018 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6


2018-12-29 12:05:14,451 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:14 2018 WARNING: file 'credentials.conf' is group or others accessible

Sat Dec 29 12:05:14 2018 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
Sat Dec 29 12:05:14 2018 library versions: OpenSSL 1.1.1a 20 Nov 2018, LZO 2.10
Sat Dec 29 12:05:14 2018 Restart pause, 5 second(s)

2018-12-29 12:05:19,451 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:19 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2018-12-29 12:05:19,452 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:19 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:443
Sat Dec 29 12:05:19 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Dec 29 12:05:19 2018 UDP link local: (not bound)
Sat Dec 29 12:05:19 2018 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:443

 

[binhex 974]

On 12/29/2018 at 5:07 PM, DarkKnight said:

Updated the container, and when I restarted it, QB isn't running any more. Can't tell from the log what's wrong. After the initial startup, this just loops endlessly every couple minutes.

 

2018-12-29 12:05:14,449 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:14 2018 [UNDEF] Inactivity timeout (--ping-restart), restarting

2018-12-29 12:05:14,450 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:14 2018 SIGHUP[soft,ping-restart] received, process restarting

2018-12-29 12:05:14,450 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:14 2018 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6

Sat Dec 29 12:05:14 2018 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6


2018-12-29 12:05:14,451 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:14 2018 WARNING: file 'credentials.conf' is group or others accessible

Sat Dec 29 12:05:14 2018 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
Sat Dec 29 12:05:14 2018 library versions: OpenSSL 1.1.1a 20 Nov 2018, LZO 2.10
Sat Dec 29 12:05:14 2018 Restart pause, 5 second(s)

2018-12-29 12:05:19,451 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:19 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2018-12-29 12:05:19,452 DEBG 'start-script' stdout output:
Sat Dec 29 12:05:19 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:443
Sat Dec 29 12:05:19 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Dec 29 12:05:19 2018 UDP link local: (not bound)
Sat Dec 29 12:05:19 2018 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:443

 

from the above snipet i would guess the endpoint you are connecting to doesnt exist, or is having issues, or is blocked in some manner on your lan (firewall?).

[Chaos_Therum 0]

So I'm running into the issue that everytime I restart the docker my savepaths for all of my torrents resets to /config/qbittorrent. And automatic torrent management is being disabled. I think this might be down to qbittorrent not handling improper shutdown very gracefully. I'm assuming that qbit is just killed when you restart the docker. Is there any solution to this?

[DarkKnight 6]

On 12/30/2018 at 5:32 PM, binhex said:

from the above snipet i would guess the endpoint you are connecting to doesnt exist, or is having issues, or is blocked in some manner on your lan (firewall?).

Yeah, that was it. I made some changes to my firewall, and it's pretty sensitive about port 443. Swapped to another port in ovpn conf and it worked immediately. Really impressed you spotted that with so little info. Thanks man.

[HandofNod 0]

On 1/1/2019 at 9:21 AM, Chaos_Therum said:

So I'm running into the issue that everytime I restart the docker my savepaths for all of my torrents resets to /config/qbittorrent. And automatic torrent management is being disabled. I think this might be down to qbittorrent not handling improper shutdown very gracefully. I'm assuming that qbit is just killed when you restart the docker. Is there any solution to this?

I was able to reproduce this after updating to the release with auto save management. I need help with this also. The only way to stop the move is to pause the docker, then move all move files from the appdata/binhex-qbittorrentvpn/qBittorrent back into the incomplete folder. Once the move is stopped, unpause the docker. Set all locations to the incomplete folder. Unpause all torrents. Then recheck all of them. I have had to fix this twice now. The docker is now unusable as I cannot stop my array or power down the server without a massive torrent recheck. I am sure this is a qbittorrent problem and not a binhex docker issue. If you set default torrent management to manual you can restart the docker just fine. You lose filing torrents by label but the docker behaves as how it was before the updates.

Edited January 8, 2019 by HandofNod
update after messing around with settings

[Chaos_Therum 0]

17 hours ago, HandofNod said:

I was able to reproduce this after updating to the release with auto save management. I need help with this also. The only way to stop the move is to pause the docker, then move all move files from the appdata/binhex-qbittorrentvpn/qBittorrent back into the incomplete folder. Once the move is stopped, unpause the docker. Set all locations to the incomplete folder. Unpause all torrents. Then recheck all of them. I have had to fix this twice now. The docker is now unusable as I cannot stop my array or power down the server without a massive torrent recheck. I am sure this is a qbittorrent problem and not a binhex docker issue. If you set default torrent management to manual you can restart the docker just fine. You lose filing torrents by label but the docker behaves as how it was before the updates.

Well an update just came through let's hope it solves this issue. I'm thinking it has something to do with the way the docker shuts down I think it's an unclean exit which qbittorrent isn't handling gracefully. Though it could just be down to the massive refactoring the webui is going through right now. Without automatic torrent management it kind of defeats the entire purpose of using qbittorrent for me at least.

[binhex 974]

1 minute ago, Chaos_Therum said:

Well an update just came through let's hope it solves this issue

this will be incorporated when the next release is out, whenever that is.

 

1 minute ago, Chaos_Therum said:

l'm thinking it has something to do with the way the docker shuts down I think it's an unclean exit which qbittorrent isn't handling gracefully

as far as docker goes, the shutdown should be clean, as in qbittorrent is sent a sigterm from tini, not a sigkill, so as long as qbittorrent correctly shuts down on a sigterm then that shouldn't be the issue, obviously if qbittorrent ignores sigterm then docker will kill all processes after a pre determined amount of time.

[Chaos_Therum 0]

Hrm that makes sense. I guess it's just something wrong with qbittorrent itself then. When I said new update I meant for the docker not qbittorrent. Thanks for all the hardwork half of the dockers I have running are yours and I couldn't get a docker with a vpn working to save my life.

[HandofNod 0]

41 minutes ago, Chaos_Therum said:

Well an update just came through let's hope it solves this issue. I'm thinking it has something to do with the way the docker shuts down I think it's an unclean exit which qbittorrent isn't handling gracefully. Though it could just be down to the massive refactoring the webui is going through right now. Without automatic torrent management it kind of defeats the entire purpose of using qbittorrent for me at least.

If the update you are talking about is 4.1.5. I am running that right now as it is the most recent update listed on the qbittorrent website. This release still has the problem with automatic torrent management. I don't think the docker is to blame due to if you use the exit qbittorrent button in the menus it shutdowns the program from inside the docker. It automatically restarts and all torrents that have downloaded media that was not stalled does an auto recheck. I am not willing to enable the automatic torrent management function and test with the exit qbittorrent menu item as it takes 6 hours to recheck all my torrents, but I think the same thing will happen due to the automatic recheck that is happening.

[binhex 974]

28 minutes ago, Chaos_Therum said:

Hrm that makes sense. I guess it's just something wrong with qbittorrent itself then. When I said new update I meant for the docker not qbittorrent. Thanks for all the hardwork half of the dockers I have running are yours and I couldn't get a docker with a vpn working to save my life.

if you can replicate the issue with steps then i would encourage you to post this as an 'issue' on the qbittorrent repo (see first post in this thread for link).

[guillaumedsde 0]

17 hours ago, binhex said:

if you can replicate the issue with steps then i would encourage you to post this as an 'issue' on the qbittorrent repo (see first post in this thread for link).

Hi, I opened and documented an issue here: https://github.com/binhex/arch-qbittorrentvpn/issues/2

[binhex 974]

20 minutes ago, guillaumedsde said:

Hi, I opened and documented an issue here: https://github.com/binhex/arch-qbittorrentvpn/issues/2

yeah i didnt really mean my repo, i only package qbittorrent as a docker image, i am not a qbittorrent developer, so if this is a qbittorrent bug then your best bet is to post it on the qbittorrent github repo.

[guillaumedsde 0]

1 minute ago, binhex said:

yeah i didnt really mean my repo, i only package qbittorrent as a docker image, i am not a qbittorrent developer, so if this is a qbittorrent bug then your best bet is to post it on the qbittorrent github repo. 

sry, misunderstood which repo to post in, I'll try to reproduce the issue with the qbittorrent-nox package on my arch machine, so that we know if the problem is docker image or qbittorrent related.

In any case, I've documented what I've tried on the issue in your docker image repo

[binhex 974]

On 1/1/2019 at 2:21 PM, Chaos_Therum said:

So I'm running into the issue that everytime I restart the docker my savepaths for all of my torrents resets to /config/qbittorrent. And automatic torrent management is being disabled. I think this might be down to qbittorrent not handling improper shutdown very gracefully. I'm assuming that qbit is just killed when you restart the docker. Is there any solution to this?

resolved in latest image, please pull down, same goes for you @HandofNod 

Edited January 11, 2019 by binhex

[HandofNod 0]

13 hours ago, binhex said:

resolved in latest image, please pull down, same goes for you @HandofNod 

Tested and working properly with restarts with automatic torrent management. Thank you binhex. You always have the best dockers!

[privateer 2]

Every time I restart the container while files are actively downloading it goes through and checks every one of them. Is this supposed to happen? Is there any way to disable this?