[Support] binhex - qBittorrentVPN


binhex

1327 posts in this topic Last Reply

Recommended Posts

On 11/25/2019 at 11:56 AM, binhex said:

you dont install and run that from qbittorrent, you install python on a machine, then install that python module and then start coding away to get it to do what you want, and that module interacts with the existing qbittorrent api.

 

Thanks for the tip! I totally misunderstood what this was. I got it setup on my main PC and I was able to make a python script to remove the dead torrents :) 

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

55 minutes ago, Hendo said:

Since the latest update I keep getting "Authentication Failure" error in Sonarr and Radarr when trying to add it as a download client.

Yeah, I checked the logs for sonarr and the authentication failures seemed to start around the same time the docker updated.

 

It's made me think it's a docker problem rather than I've been hacked.

 

Anyway to temporarily downgrade to the prior version?

 

Edit:

Deleted my .conf file and manged to log in with the default password, but now realised that the version change hasn't been whiletlisted so I definitely need to revert back to the old version.

 

Edit2:

Figured out how to revert to the old version ( 4.19 ). Copied the old .conf file in and it worked, so something about the upgrade to 4.20 seems to be breaking the webUI login, though that can be fixed by deleting your .conf and starting again.

Edited by dodgypast
Link to post
27 minutes ago, dodgypast said:

Yeah, I checked the logs for sonarr and the authentication failures seemed to start around the same time the docker updated.

 

It's made me think it's a docker problem rather than I've been hacked.

 

Anyway to temporarily downgrade to the prior version?

I had to go searching for how to downgrade and figured it out, You gotta add the version number to the Repository section in the docker config, so it would be "binhex/arch-qbittorrentvpn:4.1.9-1-01"  without the quotes.

 

It should look like this cpkWFXi.png

 

This fixed it for me.

Edited by Hendo
Link to post

Login with default admin account (admin:adminadmin), go to options, Web UI tab, and put your desired password in the Authentication section of the tab. Restart the docker and its done.

 

You can also use the option "Bypass authentication for clients in whitelisted IP subnets" adding the IP of your Sonarr docker to unban sonarr from qbittorrent.

Link to post

Hi, 

I also have a problem since last update. I cannot access WebUI from outside my network.

 

I have privoxy disabled, LAN_Network configured with 192.168.1.0/24, webui ports changed to 8090, I'm able to access qbt locally on address 192.168.1.xx:8090, port 8090 is opened in my firewall but I cannot access qbt from outside my network on address myunraiddns:8090 or myunraidip:8090 (other apps works well).

I tried to rollback to binhex/arch-qbittorrentvpn:4.1.9-1-01 but I still cannot reach qbt webui


Error message is 
 

This site can’t be reached

myunraiddns took too long to respond.

Edited by kesm
Link to post
35 minutes ago, ptr78 said:

OK. Has it been figured out how to do the password change with the least amount of hassle?

 

you could either:

  • Remove WebUI\Password_SHA1 from your config temporarily so you can log in without a password and set it again
  • Get another clean qBittorent (Dektop, new container), generate a Password with it and copy WebUI\Password_PBKDF2 from its config. Not sure if you need to remove WebUI\Password_SHA1.
  • Hash you password like qBittorrent does and insert it into your config
Link to post
2 hours ago, thatsthefrickenlightning said:

Pardon my noobiness, but is there a way to downgrade to the previous version? I'm not connectable since 4.2. I downloaded through CA.

Edit the docker container and put this into the repository field:

binhex/arch-qbittorrentvpn:4.1.9-1-01

 

You can roll back to any release. Go to the Github page for the docker container and replace the text after the colon with the release number:

binhex/arch-qbittorrentvpn:[release_number]

 

If you want the latest release once an update that resolves these issues is available, change to:

binhex/arch-qbittorrentvpn:latest

Edited by a_n_d_y
spelling errors and more descriptive
Link to post
1 hour ago, a_n_d_y said:

Edit the docker container and put this into the repository field:

binhex/arch-qbittorrentvpn:4.1.9-1-01

 

You can roll back to any release. Go to the Github page for the docker container and replace after the colon with the release number.

 

If you want the latest release once an update that resolves these issues change to:

binhex/arch-qbittorrentvpn:latest

That is awesome. Thank you for the speedy reply!

Link to post

I had a major issue with this docker container just now. I could not get the rest of my shares visible from the docker container, so I added a folder configuration like this.

image.thumb.png.8e699329c31688e88e261de821cdac4e.png

 

For some reason upon starting the docker container, most of the folders were wiped, leaving only 3 shares...

 

image.png.b2665d99f4a7f4f2f7679222353bb60b.png

 

 

 

1) Why did this happen?

2) Any chance of recovery the close to 7 TB of data that were wiped? 

Link to post
1 hour ago, bobo89 said:

1) Why did this happen?

2) Any chance of recovery the close to 7 TB of data that were wiped? 

1) the reason it happened is because you mapped the root of your user shares (/mnt/user) to the /tmp directory in the container, mapping anything to /tmp is a VERY bad idea as youve found out, reason being that /tmp is used to store temporary files created during initialisation and creation of the vpn tunnel, and thus must be clear of all previous temporary files on startup and is duly wiped.

 

2) im assuming you have no backups right?, if not then you are into possible data recovery from either a 3rd party company or possibly a utility, im not the guy to speak about this so you are best off posting in the general section of the forum, whatever you do do NOT write anything to any of your disks, as this wil reduce your chances of recovery.

Link to post
15 minutes ago, binhex said:

1) the reason it happened is because you mapped the root of your user shares (/mnt/user) to the /tmp directory in the container, mapping anything to /tmp is a VERY bad idea as youve found out, reason being that /tmp is used to store temporary files created during initialisation and creation of the vpn tunnel, and thus must be clear of all previous temporary files on startup and is duly wiped.

 

2) im assuming you have no backups right?, if not then you are into possible data recovery from either a 3rd party company or possibly a utility, im not the guy to speak about this so you are best off posting in the general section of the forum, whatever you do do NOT write anything to any of your disks, as this wil reduce your chances of recovery.

So the only problem was that I mapped to /tmp. Otherwise had I mapped to anything else, that is the proper way to make a share accessible to to a docker container?

 

I have backups that are a month or two old for containers/vms, and anything important is backed up properly. Guess it's a good time to test my restore process as well! 

 

 

Link to post
36 minutes ago, bobo89 said:

So the only problem was that I mapped to /tmp. Otherwise had I mapped to anything else, that is the proper way to make a share accessible to to a docker container?

if you had chosen any other folder other than /tmp for the container path then it wouldnt of happened, no. typically people create a folder in the container that doesnt normally exist, for example /media. so in that case you would have a host path of /mnt/user and a container path of /media and then you could use the application in the container to drill down through /media.

 

i think as this has happened once, thats one too many times for my liking so i will alter the code to not be recursive, it will be a bit more tricky to ensure a clean folder but will stop this from accidentally happening again!

Edited by binhex
Link to post
7 minutes ago, binhex said:

it will be a bit more tricky to ensure a clean folder

Can't you just delete the offending files by name before starting the operation and after finishing? Or create a subfolder in /tmp first and then use the subfolder?

Link to post
25 minutes ago, jonathanm said:

Can't you just delete the offending files by name before starting the operation and after finishing?

the difficulty is the cleanup code is in a general init script so no way of knowing what files are generated by any particular container and thus cleanup by name is...tricky, but not impossible i guess i could pass in the list of files to delete and inject that into the init script.

 

25 minutes ago, jonathanm said:

Or create a subfolder in /tmp first and then use the subfolder?

yes that is possible, it would mean touching a fair chunk of code across multiple files in multiple repos to do this.

 

i think for now i will go for a non recursive delete of /tmp and monitor for any rogue folders that might need to be included in the cleanup and add them in when necessary, its the least intrusive approach whilst preventing the issue from re-occurring.

Edited by binhex
Link to post

Realistically, anything written to /tmp should be discardable, and able to be deleted at any given point in time.  It sucks that this happened to a user but I really don't see a way around it.  But to cleanup the tmp folder and keep what "belongs" to the user would mean having to know the filename(s) of any given temp file written by the app itself at any given point in time which is going to be impossible to discern.

 

The only way around it is to not delete anything at all on startup and rely upon the app to delete it's own temp files.

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.