[Support] binhex - qBittorrentVPN


binhex

1310 posts in this topic Last Reply

Recommended Posts

  • Replies 1.3k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

@binhex Does the container only use a single .ovpn file from the appdata directory for configuration? Can I put all of the PIA port-forwarding capable server .ovpn files in there so that it can try th

Support for multi remote endpoints and PIA 'Next-Gen' networks now complete, see Q19 and Q20 for details:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Create a necessary folder in   \\yourservername\appdata\binhex-qbittorrentvpn\qBittorrent    Create a folder called ssl     Open up terminal and type,  

Posted Images

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.

Link to post

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 by Coolsaber57
Link to post
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 by Coolsaber57
Link to post

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 by H2O_King89
Link to post
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.

Link to post

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.

Link to post
  • 3 weeks later...

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

 

Link to post
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?).

Link to post

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?

Link to post
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.

Link to post
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 by HandofNod
update after messing around with settings
Link to post
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.

Link to post
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.

Link to post

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.

Link to post
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.

Link to post
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).

Link to post
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.

Link to post
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 :)

Link to post
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 by binhex
Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.