[Support] binhex - qBittorrentVPN


Recommended Posts

On 6/3/2023 at 9:57 PM, VelcroBP said:

I need help with an upgrade path. I am running a container on unRaid v6.11.5.

 

For quite a while I was holding at QBT v4.3.9 due to an error with one of the early 4.4.x builds. I don't even recall what it was specifically. Today I read that a site I use will possibly be removing 4.3.x from their whitelist. So, having read that 4.5.2-x has resolved the webUI exploit, I went ahead and removed the version tag from the template's docker pull.

 

This was a mistake, as the resulting webUI was unreadable (see screenshot). I panicked, and tried rolled back to 4.4.5-2-02. This displays correctly, but many of my Categories were missing. All custom save paths for the remaining Categories are missing or wrong also. I replaced the categories.json from my original 4.3.9 install, but no change. Privoxy was also not accepting connections with this version running.

 

I have rolled back to v4.3.9-2-01 and everything seems to have reverted to the way I had it. All Categories and custom paths are restored.

 

So, is there a step-stone approach I need to take to safely upgrade to :latest from v3.3.9? What is the proper way to get current and not blow up my Category/Folder config?

 

below is the display problem when I tried :latest

qbt wonky.png

 

I'm bumping this looking for info on best practice upgrade path to :latest from v3.3.9

Edited by VelcroBP
removed tangent
Link to comment

Hi,

 

I've been using binhex-qbittorrentvpn for several years and it's been absolutely great but for the past couple of Unraid releases I randomly get lockups. All other Dockers continue to work fine but I can't login to Unraid via the Web GUI and ultimately I have to run the following command to stop qBittorrent so I can login to Unraid to reboot the machine.

 

docker ps | grep qBittorrentVPN
ps -ef | grep a1bcdefghi
sudo kill -9 123456

 

I've completely removed qBittorrent and reinstalled it several times. Lockups can occur at any time, ranging from as frequent as a couple of days to as infrequent as a month, making it hard to track down the issue.

 

I'm currently running Unraid Version 6.12.2 along with the latest version of qBittorrent released on Jul 6, 2023, but it seems that versions don't affect the problem.

 

The only errors I can find are in the system log, and I've listed the latest two errors below.

 

Does anyone have any ideas please?

 

 

Removed

 

 

Removed

 

Edited by jaminben
Link to comment
4 minutes ago, jaminben said:

ll other Dockers continue to work fine but I can't login to Unraid via the Web GUI and ultimately I have to run the following command to stop qBittorrent so I can login to Unraid to reboot the machine.

this sounds like it COULD be the libtorrentv2 bug hitting you, try switching to the tag name 'libtorrentv1' if you dont know how to do this then follow these instructions at Q5:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md

  • Like 1
Link to comment
23 minutes ago, binhex said:

this sounds like it COULD be the libtorrentv2 bug hitting you, try switching to the tag name 'libtorrentv1' if you dont know how to do this then follow these instructions at Q5:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md


Thanks for the very quick response :)

Ok, I've made the change and will see if this fixes the issue; hopefully no lockups for at least a month.

Link to comment
9 minutes ago, jaminben said:


Thanks for the very quick response :)

Ok, I've made the change and will see if this fixes the issue; hopefully no lockups for at least a month.

this is the github issue related to libtorrentv2, looks like kernel 6.5 MAY be the fix, but that will be a while off before thats included in unraid:- https://github.com/arvidn/libtorrent/issues/6952#issuecomment-1641991981

Link to comment
1 hour ago, binhex said:

this is the github issue related to libtorrentv2, looks like kernel 6.5 MAY be the fix, but that will be a while off before thats included in unraid:- https://github.com/arvidn/libtorrent/issues/6952#issuecomment-1641991981


That certainly sounds like my issue and from that link it also has a link to this topic where they also suggested changing the repro to libtorrentv1 so we'll see.

Edited by jaminben
Link to comment

Hi I've been using the rtorrent container for a while, but switched here since it got deprecated.

 

my default save path is /media/red, but it's pretty low on space, so I wanted to save some torrents to /media/blue.

I set the save location when adding the torrent, but it keeps on downloading to red and only moving to blue when it's finished. Is there a way to avoid this behavior? For this specific torrent, I only want to write to blue. I know you could definitely do that with rtorrent, but I can't seem to figure that out with qbit. Thanks!

Link to comment

Hi All,

 

Just migrated over from the deprecated rutorrent..... yes another 1. I have successfully migrated all my torrents and I'm now in the fine tuning phase.

 

I'm trouble-shooting a bash script that hard-links my downloaded files over to a post-processing folder (I prefer the blackhole way of doing things as it gives me more control). I found a bash script online https://gist.github.com/paul-chambers/71ef48e40449ec73eef95430b9e4e6c7 that runs upon completion of a torrent which was working perfectly on the Linuxserver version of qbittorrent but sadly the scripts is only partial working since changing to this version.

 

The problem is that if the destination "category" directory isn't already created the files never get hard-linked over, but if I manually create the folder prior, it works as desired, the relevant code is on "Line 56" so i believe. 

 

The 2nd problem (not a show stopper) is the script has a echo command "line 51" that writes to a torrent-complete.log that also is not being updated anymore - I suspect this is permissions issue but I'm so out of my depth I cannot work it out.

 

On a side note - I cannot for the life of me find any logs that details what is actually happening when the script is ran apart form qBittorent.log which just indicates the script has indeed executed "Running external program" but sadly with no extra details. 

 

I have enabled "debug" in the container settings but again no errors and very little detail. 

 

Any help is much appreciated

 

supervisord.log torrent-complete.sh

Edited by wacko37
Link to comment

What is the secret to getting other containers (like Sonarr) to be able to connect to this??  I had hotio's version running, then decided to switch to OpenVPN to avoid some logging issues.  Each of my *arrs and this container are on the same /24 subnet and I even just used the same IP and login credentials as the hotio container.  No dice, they won't connect.  They can ping this container, but not access it.  I'm using the default ports (except for the peer of course) and I've tried putting 8080 in vpn input ports, output ports, both, neither, and it fails every time.  

Link to comment
On 7/23/2023 at 4:48 PM, wacko37 said:

Hi All,

 

Just migrated over from the deprecated rutorrent..... yes another 1. I have successfully migrated all my torrents and I'm now in the fine tuning phase.

 

I'm trouble-shooting a bash script that hard-links my downloaded files over to a post-processing folder (I prefer the blackhole way of doing things as it gives me more control). I found a bash script online https://gist.github.com/paul-chambers/71ef48e40449ec73eef95430b9e4e6c7 that runs upon completion of a torrent which was working perfectly on the Linuxserver version of qbittorrent but sadly the scripts is only partial working since changing to this version.

 

The problem is that if the destination "category" directory isn't already created the files never get hard-linked over, but if I manually create the folder prior, it works as desired, the relevant code is on "Line 56" so i believe. 

 

The 2nd problem (not a show stopper) is the script has a echo command "line 51" that writes to a torrent-complete.log that also is not being updated anymore - I suspect this is permissions issue but I'm so out of my depth I cannot work it out.

 

On a side note - I cannot for the life of me find any logs that details what is actually happening when the script is ran apart form qBittorent.log which just indicates the script has indeed executed "Running external program" but sadly with no extra details. 

 

I have enabled "debug" in the container settings but again no errors and very little detail. 

 

Any help is much appreciated

 

 

All good, got this to work - 24hrs of messing lol but got there in the end..... no help needed

 

I have attached the .sh if anyone would like to hardlink their downloaded files to a post-processing folder where Sonarr / Radarr etc can grab the files without accessing the main download folder - the script will create the necessary folder/subfolder based on the main downloads folder, i.e "category's"

 

It requires some editing based on your mapped directory's etc

 

torrent-complete.sh

Edited by wacko37
Link to comment

Thanks a ton @binhex for the fantastic work on this image. I was a faithful Mullvad user until they killed off Port Forwarding, so I switched to ProtonVPN and was immediately inconvenienced by the dynamically changing port forward number, which you brilliantly solved! I have a question regarding the reliance on the wg0.conf file located in /config/wireguard/.


I used to use this container with an OpenVPN config that had a similar method using .ovpn files, but ultimately switched away because I got irritated at trying to login to the WebUI on my local network to find that I couldn't connect to it because the specific endpoint I was routed to was down, thus needing to take 20 minutes to obtain new config files and rebuild the container. It wasn't the worst thing ever but I didn't have any sort of watchdog notification system to alert me that my client was down for multiple days :(


Am I going to run into the same issue here? If so, any ideas on how to be proactive about this setup?


I'm not sure if ProtonVPN's website would allow me to try and write a program to curl to the downloads page and grab a different wireguard conf download, rename/replace the existing wg0.conf and restart the container. Would be uncharted (but interesting) territory for me.

Link to comment
28 minutes ago, neardeaf said:

I got irritated at trying to login to the WebUI on my local network to find that I couldn't connect to it because the specific endpoint I was routed to was down, thus needing to take 20 minutes to obtain new config files and rebuild the container.

Actually i personally find openvpn is much more resilient to this sort of thing because you can have multiple remote endpoints specified in an openvpn config file, you cannot do this with wireguard, or at least its not a function built into wireguard so its tricky!.

I have made some good headway into improving the resilience of all the *vpn images i produce by in effect creating my own internal noddy name server, i save all resolved name to ip addresses in a text file and then round robin rotate on a failure, this reduces the risk of getting stuck on a single ip address so things SHOULD be better for both openvpn and wireguard clients.

So my advise would be try it and let me know how it goes :-), its not bullet proof of course, as VPN providers can shutdown an entire server cluster for a geolocation, but that is less likely to happen.

To give you some hope, i eat my own dogfood and run this image and i currently have an uptime of 2 weeks for this container and its still going strong - vpn provider is PIA and im using wireguard.

  • Like 1
Link to comment
1 hour ago, binhex said:

Actually i personally find openvpn is much more resilient to this sort of thing because you can have multiple remote endpoints specified in an openvpn config file, you cannot do this with wireguard, or at least its not a function built into wireguard so its tricky!.

I have made some good headway into improving the resilience of all the *vpn images i produce by in effect creating my own internal noddy name server, i save all resolved name to ip addresses in a text file and then round robin rotate on a failure, this reduces the risk of getting stuck on a single ip address so things SHOULD be better for both openvpn and wireguard clients.

So my advise would be try it and let me know how it goes :-), its not bullet proof of course, as VPN providers can shutdown an entire server cluster for a geolocation, but that is less likely to happen.

To give you some hope, i eat my own dogfood and run this image and i currently have an uptime of 2 weeks for this container and its still going strong - vpn provider is PIA and im using wireguard.

 

Ahh okay that might me the solution I need then, but I'd like to try and give it a shot to see if I can get something working and maybe submit my first PR or something!

Link to comment
On 7/24/2023 at 1:12 AM, binhex said:

do you mean the arrs are sharing the qbittorrentvpn containers network?, if so check out Q25:-  https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

So weird....I'm on vacation and thought I'd pop it to check for an update and it seems I somehow didn't post the reply I'd typed out somewhere.  Anyway, I'm not routing any containers through another container.  I have a quad NIC with each port having one or two VLANs and each of those with their on /24 subnet.  The *arrs and this container are on the same VLAN and each has a static IP assigned in the same subnet.  It is working for over 20 other containers, but I can't get them to be able to connect to this one for some reason.

Link to comment

I'm trying to set up a second instance of qbittorrent, I found this link and followed A4.  Now I can get the webui to work, but only briefly.  When IO open settings successfully, I can't save, chrome says: "Unable to save program preferences, qBittorrent is probably unreachable."  Or, It doesn't load and I see: "Error: n".  Then I have to log back in. I was able to add a torrent from a plugin on firefox, and see it in the webui.  What can I do to fix this? Thanks

 

 

EDIT: I deleted and restarted on the second container, had the same issue.  Currently both containers seem to be functioning after stopping the 1st container, restarting the 2nd, which at this point started working, I could save settings, and then start the 1st container. I don't know if they are fixed or the order the start in might have top be like this?  I'd still like to get the webui button to have the right port.

Edited by bobobeastie
Link to comment
17 hours ago, binhex said:

To give you some hope, i eat my own dogfood and run this image and i currently have an uptime of 2 weeks for this container and its still going strong - vpn provider is PIA and im using wireguard.

 

Do what you want of course, but you're aware PIA has been bought by a company with a less than stellar reputation?

 

E:

  

On 7/11/2023 at 10:16 AM, binhex said:

if you get dns failure then the vpn tunnel is down (dns blocked on lan), once the tunnel is down natpmp will also fail as it requires a working vpn tunnel to get assigned an incoming port. so the question is, why is the tunnel going down, well there are a number of possibilities, as you mentioned it could be protonvpn getting overloaded, try and choose an endpoint with low utilisation (noticed protonvpn show this in their endpoint selection webpage).

 

one other thing to mention is that i have code in place to recover from a vpn connectivity failure, so you should see an attempt to re-establish the vpn tunnel and subsequent natpmp calls to get a new incoming port, have you tried simply leaving the container running to see if it recovers?.

 

Sorry, never got back to you on this one. The connection tends to be spotty at times, but the tunnel and port forwarding also recover on their own. With this being a service that's on 24/7 but not actively used 24/7, I don't mind there being some downtime here and there. I'm sure the fault is with Proton and them being overloaded at times.

Edited by thatsthefrickenlightning
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.