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

I've been having authentication issues sending requests via Remote Torrent Adder since the update as well.

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 December 5, 20196 yr by dodgypast

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 

 

This fixed it for me.

Edited December 5, 20196 yr by Hendo

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.

Right, but copy your conf file to some other place first and afterwards compare the old and the new one.

Transfer all the missing lines (with the exepction of the PW line) to the new one, else you lose all your changed settings.

You can just go into the configuration file and delete WebUI\Password_ha1 and login with your username:adminadmin and then reset your password.

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 December 6, 20196 yr by kesm

It seems that there a lot issues with the latest update. Have they been resolved, so is it OK to update? Or should one wait for a new update? Thank you!

 

From the official changelog:

Quote

WEBUI: Use PBKDF2 for the WebUI password. You will need to set your password again.

I'm not sure any future versions will include a "fix" for this.

1 hour ago, dknaack said:

From the official changelog:

I'm not sure any future versions will include a "fix" for this.

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

 

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
  

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.

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 December 7, 20196 yr by a_n_d_y
spelling errors and more descriptive

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!

Thanks for the instructions on rolling back to 4.1.9. 4.2.0 has not been whitelisted on several private trackers and probably wont be for a least a month for some.

Edited December 7, 20196 yr by DazedAndConfused

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.

 

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

 

 

 

 

1) Why did this happen?

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

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.

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! 

 

 

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 December 7, 20196 yr by binhex

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?

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 December 7, 20196 yr by binhex

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.

2 minutes ago, Squid said:

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.

im fairly ok with apps deleting their own temp files as this generally does happen without issue afaik, i also use /tmp to store temporary created files that store data that i need to share between users, for instance root and user nobody, for technical reasons in bash this gets difficult and thus i resort to use /tmp as a way of transferring critical information between acconts, its this temporary data that needs to be cleaned up and thus the historic cleaning of /tmp.

Turns out that even after changing the password in qbt 4.2.0 - with following container restart - and also in radarr and sonarr to the new one, both containers still cannot connect to qbt (Authentication failure). And I'd wager a guess that this is also the reason why Transdroid can't connect to my qbt container (even though its error message is "internal error building request").

I am clearly missing something here, but Ihonestly have absolutely no clue, what.

Has anyone already solved this problem?