[Support] binhex - qBittorrentVPN


Recommended Posts

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 comment

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 comment
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 comment

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 comment
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 comment
  • 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 comment
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 comment

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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
9 minutes ago, privateer said:

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?

The integrity of torrents requires the application to know the files haven't changed. 

Link to comment

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.