[Support] binhex - qBittorrentVPN

[binhex]

8 hours ago, asherbig said:

 

I ran the command you asked, and this is the result from my end. I am also experiencing this issue now (it started yesterday)

sh-5.2# grep -P -o 'crl-verify' < /root/start.sh
crl-verify
crl-verify
crl-verify
crl-verify

 

Do a 'force update' I think you are not running the latest image

[r2range]

2 hours ago, binhex said:

Do a 'force update' I think you are not running the latest image

Thanks solved the issue

[JaegerStriker]

Sorry to post again. I've done a force update and it still doesn't work. Should I do a fresh install?

[binhex]

11 minutes ago, JaegerStriker said:

Sorry to post again. I've done a force update and it still doesn't work. Should I do a fresh install?

then your issue is most probably something else, I will need to see a log to help further, please see the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md#unraid-users

[Meatball Flag]

Hello, I am unable to log in to the container UI. Are the old work-arounds from November still needed?

Edit: Just for clarity, I am able to access the login page and do not seem to have the vpn problems that seem to be affecting others recently

 

I went through the work-arounds shared a few months back when the default adminadmin password was killed and had everything working. My server was shutdown for a week+ for a move and I updated the container when I got back up and running and could no longer login with my previously set password or the old default.

I can access the temp password under the supervisord.log file but am unable to login with that either; I seem to remember not being able to access that previously thus the stickied work-arounds but maybe I am mistaken on that.

 

Is the stickied work-around post still necessary or is there something else I am missing?

The work around I am referring to:

Adding this line under [Preferences], in the config file, works, for setting the default password manually to: adminadmin

WebUI\Password_PBKDF2="@ByteArray(ARQ77eY1NUZaQsuDHbIMCA==:0WMRkYTUWVT9wVvdDtHAjU9b3b7uB8NR1Gur2hmQCvCDpm39Q+PsJRJPaCU51dEiz+dTzh8qbPsL8WkFljQYFQ==)"

qbit-supervisord.log

Edited June 5 by Meatball Flag
Adding aditional info

[wgstarks]

From your log-

Quote

The WebUI administrator username is: admin
The WebUI administrator password was not set. A temporary password is provided for this session: 8hArkPeny
You should set your own password in program preferences.

Are you saying that these credentials don’t work for login?

[Meatball Flag]

Correct, Username: admin and the temp password do not work.

 

If i stop and restart the container I get a new temp password in the logs each time. I have attempted multiple times with no success

[wgstarks]

24 minutes ago, Meatball Flag said:

Correct, Username: admin and the temp password do not work.

 

If i stop and restart the container I get a new temp password in the logs each time. I have attempted multiple times with no success

Do you still have the extra line in the Preferences file?

[Meatball Flag]

7 minutes ago, wgstarks said:

Do you still have the extra line in the Preferences file?

No, I removed it based on this https://github.com/qbittorrent/qBittorrent/wiki/Web-UI-password-locked-on-qBittorrent-NO-X-(qbittorrent-nox)

So it is still required then? When it was there my previously set password would not work anymore

[wgstarks]

12 minutes ago, Meatball Flag said:

When it was there my previously set password would not work anymore

Im just going by what I have in my pref file which is working. It has that line. Might be worth trying adding that line back and then see if the temp credentials will work.

[Meatball Flag]

I added it back in again. The original default 'adminadmin' does not work, my previously set password still stored in my pw manager does not work, and the supervisord log no longer shows a temp password on startup for me to try.

[wgstarks]

27 minutes ago, Meatball Flag said:

I added it back in again. The original default 'adminadmin' does not work, my previously set password still stored in my pw manager does not work, and the supervisord log no longer shows a temp password on startup for me to try.

Im afraid I’m out of ideas though I also seem to have locked myself out of my own webui.😆 

[wgstarks]

Another idea, rename the qbit prefs file to something like old_preferences (you don’t want to delete it) and then restart the container. This will cause a download of a new default prefs file which may allow you to set a new password. If it doesn’t work you can just delete the new prefs file and restore the proper name to the old one.

 

Also, I would suggest posting in the qbittorrent forum if you haven’t already. Lots more users with a much deeper knowledge under-the-hood. Might get this resolved faster.

[JaegerStriker]

7 hours ago, binhex said:

then your issue is most probably something else, I will need to see a log to help further, please see the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md#unraid-users

 

command execution.txt supervisord.log

[binhex]

54 minutes ago, JaegerStriker said:

 

command execution.txt 1.39 kB · 1 download supervisord.log 68.95 kB · 1 download

from your log:-
AUTH: Received control message: AUTH_FAILED

 

Please see Q16 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

[Meatball Flag]

3 hours ago, wgstarks said:

Another idea, rename the qbit prefs file to something like old_preferences (you don’t want to delete it) and then restart the container. This will cause a download of a new default prefs file which may allow you to set a new password.

This did the trick. After renaming the qbittorrent.conf file and restarting the container a new version of the file was created. A new temp password appeared in the supervisord log and I was able to log in with the new temp password and reset the password in the UI.

 

Now the question is what to do about my prefs?

Simply changing the new .conf name to something else and my existing .conf to the proper name made me unable to log in again with any password.

There are many entries in my existing .conf that do not exist in the fresh one so I do not know which parts I actually need or which part is the source of the issue.

I'll keep noodling at it but I would appreciate if anyone has further advice

 

Edited June 5 by Meatball Flag

[wgstarks]

3 hours ago, Meatball Flag said:

There are many entries in my existing .conf that do not exist in the fresh one so I do not know which parts I actually need or which part is the source of the issue.

I'll keep noodling at it but I would appreciate if anyone has further advice

Just a guess really but I imagine you can copy most of your old pref file to the new one. Just avoid the lines related to password. I would probably do it one section at a time and test. The Dynamix File Manager plugin can probably handle this.

[wgstarks]

Another option you may not have tried, copy the new password hash to the old pref file.

[Meatball Flag]

16 hours ago, wgstarks said:

Another option you may not have tried, copy the new password hash to the old pref file.

This was my first thought as well but unfortunately didn't work.

 

I copied over from the old .conf to the new file section by section, keeping any lines from the new file that did not exist in the old,  testing along the way. I now have it working and narrowed down to just one line that makes the difference.
WebUI\CSRFProtection=false

 

My old conf file has WebUI\CSRFProtection=true, with everything else in the new file being the same I can not log in with this setting enabled. When I change it to false I can log in normally

 

Idk what CSRFProtection is and if its important, I haven't looked into yet but at least i can log in now. I'll see what I can learn from the qbit forum and/or github page

[wgstarks]

1 hour ago, Meatball Flag said:

what CSRFProtection is and if its important, I haven't looked into yet

 https://www.barracuda.com/support/glossary/csrf#:~:text=CSRF attacks are%2C on the,knowledge of the target user.

[wgstarks]

Unless you are exposing this page to the internet at large I doubt you need to worry unless your local network is hacked.

[xrichnj]

On 6/4/2024 at 1:41 PM, Sak said:

I am using ProtonVPN and port forwarding port not automatically assigned after the previous update. It was working previously.

current log shows

2024-06-05 00:33:18,014 DEBG 'watchdog-script' stdout output:
[info] qBittorrent listening interface IP 0.0.0.0 and VPN provider IP 10.2.0.2 different, marking for reconfigure

2024-06-05 00:33:18,021 DEBG 'watchdog-script' stdout output:
[info] qBittorrent not running

2024-06-05 00:33:18,021 DEBG 'watchdog-script' stdout output:
[info] qBittorrent incoming port 6881 and VPN incoming port 52584 different, marking for reconfigure

2024-06-05 00:33:18,021 DEBG 'watchdog-script' stdout output:
[info] qBittorrent config file already exists, skipping copy
[info] Removing session lock file (if it exists)...

2024-06-05 00:33:18,029 DEBG 'watchdog-script' stdout output:
[info] Attempting to start qBittorrent...

2024-06-05 00:33:18,031 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process started

2024-06-05 00:33:18,031 DEBG 'watchdog-script' stdout output:
[info] Waiting for qBittorrent process to start listening on port 8082...

2024-06-05 00:33:18,138 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process listening on port 8082

 

it say marking for reconfigure, but it never does. I have to manually change it in webui

previously the "start-script" shows that the automatic port forward works:

2024-06-04 07:37:38,955 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '58741'

 

 

On 6/4/2024 at 1:49 PM, binhex said:

wireguard or openvpn? also which country endpoint are you using?

 

On 6/4/2024 at 1:58 PM, binhex said:

ok thanks for the info, leave it with me, i did do extensive testing with protonvpn and i have a 1month subscription so i can test it, but unless something has changed this WAS working with the current image.

 

On 6/4/2024 at 2:06 PM, binhex said:

can be ignored.

 

ok so i have just tested it connecting to cambodia via wireguard protonvpn and the port is correctly assigned and qbittorrent is correctly configured and once i add in a torrent then the orange flame turns into a green globe to indicate port forwarding is operational, so i cannot reproduce it at present 😞

@binhex, i have experienced similar on proton using wireguard since one of the last updates. the port does set right, but i no longer get the "successfully assigned and bound incoming port XXXXX" message, or the 45 second watchdog update in log to make sure its working properly. i like to check it every so often to make sure its still operational and injecting the port, should it change. my log stops any showing anything new past "[info]qbittorrent process listening on port" as @Sak mentioned above. the last time i saw these message properly was 06-03-2024 according to supervisord.log. did an update change this? or did i mess something up? thanks!

[K18LDP]

supervisord.txtCommand Execution.docx

 

Hi, Random issue just happened this morning. I was logged into qbit via webui. I had cross-seed also running at the same time. 

 

Qbit webUI started playing up in that I could browse - but the injected torrents from cross-seed weren't showing up.

 

I stopped cross-seed and restarted the Qbit container. The container is showing as started in the docker dashboard.

 

But when I now navigate to ipaddress:port for qbit it doesn't load the login screen and times out. I have stopped and restarted the container a few times. I've also removed the container and reinstalled.

 

I know that application is running as, it's showing that I'm still seeding the torrents  on various sites. I just can't get the webUI to load??

 

Any help would be highly appreciated

 

[Matrix]

 

Do I need to be concerned about this? I was reviewing my network activity and noticed my qbittorrentvpn docker (labelled as BitTorrent application) correctly showed the port used for incoming connections in Qbittorent (44203). As you can see it was only for 1 second and then switched to port 443 through the vpn configuration.

 

Docker log (VPN IP xxx)

-A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A INPUT -s xxx.xxx.xxx.xx/32 -i eth0 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8091 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 8091 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A OUTPUT -d xxx.xxx.xxx.xx/32 -o eth0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -d xxx.xxx.xxx.xx/32 -o eth0 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8091 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8091 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

2024-06-10 16:00:05,544 DEBG 'start-script' stdout output:
--------------------

2024-06-10 16:00:05,545 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2024-06-10 16:00:05,565 DEBG 'start-script' stdout output:
2024-06-10 16:00:05 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 

2024-06-10 16:00:05,566 DEBG 'start-script' stdout output:
2024-06-10 16:00:05 WARNING: file 'credentials.conf' is group or others accessible
2024-06-10 16:00:05 OpenVPN 2.6.10 [git:makepkg/ba0f62fb950c56a0+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Mar 20 2024
2024-06-10 16:00:05 library versions: OpenSSL 3.3.0 9 Apr 2024, LZO 2.10

2024-06-10 16:00:05,566 DEBG 'start-script' stdout output:
2024-06-10 16:00:05 DCO version: N/A

2024-06-10 16:00:05,567 DEBG 'start-script' stdout output:
2024-06-10 16:00:05 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2024-06-10 16:00:05,567 DEBG 'start-script' stdout output:
2024-06-10 16:00:05 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xx:443

2024-06-10 16:00:05,567 DEBG 'start-script' stdout output:
2024-06-10 16:00:05 UDPv4 link local: (not bound)
2024-06-10 16:00:05 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xx:443

2024-06-10 16:00:05,743 DEBG 'start-script' stdout output:
2024-06-10 16:00:05 [server] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xx:443

2024-06-10 16:00:06,936 DEBG 'start-script' stdout output:
2024-06-10 16:00:06 TUN/TAP device tun0 opened
2024-06-10 16:00:06 net_iface_mtu_set: mtu 1500 for tun0
2024-06-10 16:00:06 net_iface_up: set tun0 up

2024-06-10 16:00:06,937 DEBG 'start-script' stdout output:
2024-06-10 16:00:06 net_addr_ptp_v4_add: 10.9.0.89 peer 10.9.0.90 dev tun0
2024-06-10 16:00:06 /root/openvpnup.sh tun0 1500 0 10.9.0.89 10.9.0.90 init

2024-06-10 16:00:06,938 DEBG 'start-script' stdout output:
2024-06-10 16:00:06 Initialization Sequence Completed

2024-06-10 16:00:23,119 DEBG 'start-script' stdout output:
[info] Attempting to get external IP using 'http://checkip.amazonaws.com'...

2024-06-10 16:00:41,231 DEBG 'start-script' stdout output:
[info] Failed on last attempt, attempting to get external IP using 'http://whatismyip.akamai.com'...

2024-06-10 16:00:41,691 DEBG 'start-script' stdout output:
[info] Successfully retrieved external IP address xxx.xxx.xxx.xx

2024-06-10 16:00:41,692 DEBG 'start-script' stdout output:
[info] VPN provider 'custom' not supported for automatic port forwarding, skipping incoming port assignment

2024-06-10 16:00:41,720 DEBG 'watchdog-script' stdout output:
[info] qBittorrent listening interface IP 0.0.0.0 and VPN provider IP 10.9.0.89 different, marking for reconfigure

2024-06-10 16:00:41,723 DEBG 'watchdog-script' stdout output:
[info] qBittorrent not running

2024-06-10 16:00:41,724 DEBG 'watchdog-script' stdout output:
[info] qBittorrent config file already exists, skipping copy
[info] Removing session lock file (if it exists)...

2024-06-10 16:00:41,736 DEBG 'watchdog-script' stdout output:
[info] Attempting to start qBittorrent...

2024-06-10 16:00:41,739 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process started
[info] Waiting for qBittorrent process to start listening on port 8091...

2024-06-10 16:00:42,058 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process listening on port 8091

 

Edited June 11 by Matrix

[binhex]

7 hours ago, Matrix said:

Do I need to be concerned about this? I was reviewing my network activity and noticed my qbittorrentvpn docker (labelled as BitTorrent application) correctly showed the port used for incoming connections in Qbittorent (44203). As you can see it was only for 1 second and then switched to port 443 through the vpn configuration.

How are you using this docker image?, are you simply using the built in vpn or are you sharing networking with another container?, any use of socks4/5 proxy or similar?.