11 minutes ago, KinkyBanjo said:

I did consider spending the time bringing it up to VPNUnlimited. But if deluge's vpn docker and the OpenVpn client connect without issue using this exact same configuration file it makes it harder to convince them its something on their end.

the latest qbittorrent image no doubt has a later version of openvpn as the image been built more recently, this new version is now flagging the cert provided by your vpn provider as insecure, you can either ignore the error and use an earlier version of this image (not what i would do), or get your vpn provider to provide a cert that isnt insecure (the right thing to do), i will leave it up to you to decide.

 

p.s. delugevpn and sabnzbdvpn will be showing the same error once they get updated with the later version of openvpn (common base).

 

https://forums.openvpn.net/viewtopic.php?t=34656

5 hours ago, reporrted said:

Good day.

 

wg0.conf is losing it's permissions every time it starts, is unable to be read, and thus fails to start the container citing unable to connect to wg0. I am using a new conf downloaded from the provider but it does the same thing. Even if I set permissions using chmod, it just reverts upon starting the docker.

Am I missing something simple here?

 

Fixed it. I changed the owner of the file to root and now it retains permissions. If this is bad, please let me know?

 

Cheers.

7 hours ago, KinkyBanjo said:

I did consider spending the time bringing it up to VPNUnlimited. But if deluge's vpn docker and the OpenVpn client connect without issue using this exact same configuration file it makes it harder to convince them its something on their end.

I am also having this issue with VPNUnlimited using openvpn. I have attempted to migrate to wireguard, but now I am having dns failure issues instead. Keep me posted on anything you find, and I will do the same! (I would be very happy if I can get wireguard to work. It's a much more efficient protocol) 

Having an issue on server reset where all settings are reset to default, seemingly the entire .conf file is being overwritten like a new install every time I need to reboot the server. Ideas?

Good Day,

 

I switched over to Mullvad VPN and got two questions.

 

1) The Container is running and working except for port forwarding. The wireguard config contains the port which is supposed to be forwarded and I have entered the same port in qbt settings. Qbt is also bound to wg0 and the IP address set in the wireguard config. However, I am not connectable.

Am I missing something? Are the following variables to be used with Mullvad? -e VPN_INPUT_PORTS=<port number(s)> \ -e VPN_OUTPUT_PORTS=<port number(s)> \

 

2) DNS Leaks: When browsing over privoxy, the Mullvad checking site detects DNS Leaks. There are no DNS leaks when using the Mullvad App with Privoxy disabled. So, I assume it has to do with the DNS servers in the container config. By default, I use Binhex recommended servers (-e NAME_SERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1 \). However, even removing these does not stop the leaks. Any advice?

 

Thanks!

 

Edit: Alright, 1)  is no longer a problem. The port forwarding setup with Mullvad is kind of confusing as the forwarded port is NOT the port you can choose when creating the config file but a random port that you get assigned at a later step. Anyway, port forwarding seems to be working now. You also do not need to put the port in the docker compose but only add it in qbt.

 

@binhex Do you have any idea regarding the 2) DNS leaks?

Edited November 23, 20223 yr by TombRaider
progress

I was also experiencing issues with Wireguard (Mullvad) on the latest version since updating, speeds were stuck at 1MiB/s maximum, a far cry from the 60 I usually get.

 

I rolled back to 4.4.5-1-01 using the exact same configs and now speeds are back to normal. Happy to provide more details if that helps in diagnosis.

 

EDIT: Also interesting to note is that it only seemed to be download speeds which were restricted, seeding speeds seemed okay. I did also try fresh openvpn configs from Mullvad on the latest version and it just wouldn't connect. I've just tried mullvad openvpn on the older build and I'm getting issues as well, but I prefer using Wireguard. Happy to provide logs on that as well if it will be helpful.

Edited November 22, 20223 yr by Fromnack
More info

22 hours ago, TombRaider said:

2) DNS Leaks: When browsing over privoxy, the Mullvad checking site detects DNS Leaks. There are no DNS leaks when using the Mullvad App with Privoxy disabled. So, I assume it has to do with the DNS servers in the container config. By default, I use Binhex recommended servers (-e NAME_SERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1 \). However, even removing these does not stop the leaks. Any advice?

this is expected, privoxy is a http(s) proxy only it will not proxy dns requests so dns requests will go over your ISP not via the VPN tunnel, this is NOT the case for torrent clients as they do not use privoxy, they simply use the VPN tunnel directly setup inside of the container.

26 minutes ago, binhex said:

this is expected, privoxy is a http(s) proxy only it will not proxy dns requests so dns requests will go over your ISP not via the VPN tunnel, this is NOT the case for torrent clients as they do not use privoxy, they simply use the VPN tunnel directly setup inside of the container.

Thanks for the explanation. It makes sense.

To make sure I understand, do torrent clients use DNS servers and this would be the reason why we should use the name server list you provided? If not, I assume we could leave this variable empty.

59 minutes ago, TombRaider said:

do torrent clients use DNS servers and this would be the reason why we should use the name server list you provided

correct, and without dns you would also be unable to resolve any vpn endpoint hostname and thus unable to connect to your vpn provider.

On 4/27/2022 at 5:46 AM, J05u said:

Hello, when i am trying to open this container all the time i am getting unauthorized message

What can be done about this, can you please advice?

 

Have you found the issue? I'm having the same thing...

On 11/24/2022 at 10:07 PM, Narvath said:

Have you found the issue? I'm having the same thing...

Something is totally broken with the image (Edit: or not, see below), all settings reset to default (including password which is `adminadmin`). I hope none of you have it exposed to the internet.

 

Edit: Could be a qb issue, due to power loss on the server.

Edited November 28, 20223 yr by another_one

Something is totally broken with the image, all settings reset to default (including password which is `adminadmin`). I hope none of you have it exposed to the internet.

Going from qbit 4.3.x to 4.4.x does lead to loss of some settings (qbit issue), other than that I've seen no loss of settings myself.

Sent from my 22021211RG using Tapatalk

Haven't had it happen recently but I do think the settings resetting is an issue with this container.  I personally only ever saw it after my unraid system crashed/unexpectedly shutdown, but have seen a few people post about it in this thread.  I never moved from 4.3 so it's unrelated to any 4.3->4.4 issues.  

 

When it happened it was a complete loss of the settings, as if the conf file was deleted and regenerated to a default state.  From just having the qBittorrent.conf file open in Notepad++ it seems like its constantly being saved every ~minute or so, maybe if the system or container becomes unresponsive this can sometimes cause it to overwrite it with an empty file?

21 minutes ago, THF13 said:

Haven't had it happen recently but I do think the settings resetting is an issue with this container.  I personally only ever saw it after my unraid system crashed/unexpectedly shutdown, but have seen a few people post about it in this thread.  I never moved from 4.3 so it's unrelated to any 4.3->4.4 issues.  

 

When it happened it was a complete loss of the settings, as if the conf file was deleted and regenerated to a default state.  From just having the qBittorrent.conf file open in Notepad++ it seems like its constantly being saved every ~minute or so, maybe if the system or container becomes unresponsive this can sometimes cause it to overwrite it with an empty file?

Alright, then it's probably what happened to me. I had a power loss the other day. Could be corruption that qb does on its own.

 

Edit: For now I just rolled back to 4.4.5, considering 4.5 is not supported in few places.

Edited November 28, 20223 yr by another_one

13 hours ago, THF13 said:

I personally only ever saw it after my unraid system crashed/unexpectedly shutdown

data loss due to unexpected shutdown/crash can happen for any application, if the file is open and being written to at the time the crash occurs then you may end up with either a corrupt file (half written) or an empty file, the trick is to try and minimise this from happening by employing a UPS for browouts/blackouts and decent quality hardware that is verified as good (mem checks for instance), and of course make sure you have backups - install plugin 'Appdata Backup/Restore v2'.

Maybe this has already been asked, but is there a correct way to downgrade the qBittorrent-VPN to a pervious version?

I accidentally updated my docker to 4.5, however my trackers have not whitelisted this version yet.

4 minutes ago, owzo said:

Maybe this has already been asked, but is there a correct way to downgrade the qBittorrent-VPN to a pervious version?

I accidentally updated my docker to 4.5, however my trackers have not whitelisted this version yet.

Open the docker configuration (click the docker name) and in the repository field type a colon and tag number (no spaces). Click “apply” at the bottom of the page. You can get the tag number from dockerhub. See the link in the first post.

1 hour ago, wgstarks said:

Open the docker configuration (click the docker name) and in the repository field type a colon and tag number (no spaces). Click “apply” at the bottom of the page. You can get the tag number from dockerhub. See the link in the first post.

Thank you so much, worked like a charm. 

Had an issue with 4.5 where memory ballooned to about 4GB, best I can tell.

 

My system should have been able to handle it but I couldn't investigate – GUI was non-responsive and even simple bash commands would throw "resource fork" errors (maybe nproc limits?) I managed to restart the server and downgrade cleanly, no problems since.

Had an issue with 4.5 where memory ballooned to about 4GB, best I can tell.
 
My system should have been able to handle it but I couldn't investigate – GUI was non-responsive and even simple bash commands would throw "resource fork" errors (maybe nproc limits?) I managed to restart the server and downgrade cleanly, no problems since.

Interesting, not seen this problem myself....yet

Sent from my 22021211RG using Tapatalk

Hi, I updated to the v4.5.0 qbittorrent and I've found that the queue icon does not seem to not load in the table.

 

Seems like the queue.svg file did not download as /images/queue.svg does not exist. Other icons like /images/download.svg do exist, which show fine as seen in screenshot below;

 

I also was having weird issues with the latest version and downgraded but was still getting an issue with the wireguard interface starting. Replaced with a new wg0.conf from Mullvad but now the only way the container works is to start it privileged. I clearly have some kind of permission issue somewhere. Any ideas? wg0.conf is already root owned.

I did consider spending the time bringing it up to VPNUnlimited. But if deluge's vpn docker and the OpenVpn client connect without issue using this exact same configuration file it makes it harder to convince them its something on their end.

I spoke to VPNUnlimited about this issue (depreciated cipher AES-256-CBC), and they said that they are aware of the problem and are issuing new certificates to the servers, but in the meantime add this to your openvpn.conf

tls-cipher DEFAULT:@SECLEVEL=0

It's not optimal, but it works for now,

Sent from my SM-G965W using Tapatalk

14 hours ago, SeeGee said:

It's not optimal, but it works for now,

its also not secure, but the choice is yours.

Is there any way to test that all the trafic is running though the VPN and not my normal IP ?