EDIT:

Fixed this for now by changing the repo to: dyonr/qbittorrentvpn:alpha

 

Just updated today, and the GUI isn't coming up. 

 

Docker log shows below.  Note that PID is not displayed.
 

2021-11-01 13:58:10.792792 [INFO] A group with PGID 100 already exists in /etc/group, nothing to do.
2021-11-01 13:58:10.812855 [INFO] An user with PUID 99 already exists in /etc/passwd, nothing to do.
2021-11-01 13:58:10.831970 [INFO] UMASK defined as '002'
2021-11-01 13:58:10.853118 [INFO] Starting qBittorrent daemon...
Logging to /config/qBittorrent/data/logs/qbittorrent.log.
2021-11-01 13:58:11.880629 [INFO] Started qBittorrent daemon successfully...
2021-11-01 13:58:11.902356 [INFO] qBittorrent PID:
2021-11-01 13:58:12.179287 [INFO] Network is up

 

The qbittorrent.log shows this on the end, which might be the issue:

 

/usr/local/bin/qbittorrent-nox: error while loading shared libraries: libQt5Sql.so.5: cannot open shared object file: No such file or directory
/usr/local/bin/qbittorrent-nox: error while loading shared libraries: libQt5Sql.so.5: cannot open shared object file: No such file or directory

 

Edited November 1, 20214 yr by guythnick

I have the same exact issue as guythnick is there an issue with the update that is causing this?

Edited my post above.  Was able to get it running again by changing the repository to use the alpha image:

 

dyonr/qbittorrentvpn:alpha

That worked for me too, thanks!

This worked for me too.. Thank you!

On 10/26/2021 at 11:39 PM, Klench said:

I have issues with disabling SSL encryption. I have tried to set the environment variable ENABLE_SSL to "no" to no effect as it is being overwritten when the container is stared. No extra paramters regarding SSL are being set. How can this problem me mitigated?

Please see screenshot below for configuration.

 

 

 

EDIT: More environment variables were found when I expanded "Show more settings". Deleting redundant environment variables solved the problem.

 

Has anyone managed to disable SSL encryption?

Edited December 23, 20214 yr by Klench
Add some more information about how I solved the problem

General question-
Is it absolutely overkill to setup the PROXY in the app in addition to this docker using VPN? I have always followed the guide below to "harden" the app to IP leakage. Is that not a concern with this implementation? 
https://torguard.net/knowledgebase.php?action=displayarticle&id=241

Thanks so much for this image. Is there a way to automate port forwarding with PIA in this container? My upload rate is near zero and I need to maintain a seed ratio.

On 11/14/2021 at 3:17 PM, Klench said:

 

EDIT: More environment variables were found when I expanded "Show more settings". Deleting redundant environment variables solved the problem.

 

Has anyone managed to disable SSL encryption?

I wasn’t able to disable SSL - I can access via HTTPS which throws certificate errors.

 

Also the default admin/adminadmin credentials aren’t working… anyone find a workaround for this?

11 minutes ago, bearattack said:

I wasn’t able to disable SSL - I can access via HTTPS which throws certificate errors.

 

Also the default admin/adminadmin credentials aren’t working… anyone find a workaround for this?

 

Disabling SSL is indeed bugged at the moment. I will fix this in a future update.

For now, if you want to disable SSL:

- Stop the container

- Set the environment variable ENABLE_SSL to 'no'

- Go to the Unraid Appdata of this Docker container, appdata/qBittorrent/config/qBittorrent.conf

  Set 'WebUI\HTTPS\Enabled=true' to 'WebUI\HTTPS\Enabled=false'

 

Want to reset the password?

In the same config file set 'WebUI\Username' as 'WebUI\Username=admin'

Remove the line 'WebUI\Password_PBKDF2' and replace it with this line:

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

 

After that, stop and start the container.

 

Note that having SSL disabled COULD cause login issues.

Edited January 30, 20224 yr by Dyon

I've had this container running for months no problems. Downloads went in one cache pool, and the config in separate drive in another pool. All the sudden, it starts putting downloads in the config folder even though the template specifies a different path (it was the first thing I checked). Did something change in a recent update?

18 minutes ago, howyoulikethat said:

I've had this container running for months no problems. Downloads went in one cache pool, and the config in separate drive in another pool. All the sudden, it starts putting downloads in the config folder even though the template specifies a different path (it was the first thing I checked). Did something change in a recent update?

 

 

It seems like qBittorrent changed something that made the config different.

I'll see if I can pushg a new update soon to fix this for everyone using this container. For now;

1. Open qBittorrent

2. Go to settings

3. In the first default tab (Downloads) change the 'Default Save Path' to '/downloads'.

 

I've worked on a fix for the problem mentioned by @howyoulikethat, but while working on it, I've decided not to release this.

I do not want to mess with the config file of users.

 

The code below was intended to be a new section of the qBittorrent/start.sh file, to fix the config.

Problems;

1a. It doesn't check if the user already fixed it themselves.

1b. It doesn't check the [BitTorrent] section in the config file to see if the new Session\DefaultSavePath etc already exist, so it keeps adding it on every reboot.

2. Moving the files is a dirty fix.

3. Messing with the .fastresume files is tricky. What if someone has a rule to automatically move it to a sub-directory? In that case the .fastresume file would be different than the default savePath29 / save_path29.

 

Quote

export CORRECT_SAVEPATH=$(echo "${CORRECT_SAVEPATH,,}")
if [[ ! -z "${CORRECT_SAVEPATH}" ]]; then
    echo "[WARNING] CORRECT_SAVEPATH is not set. Switching this to 'yes' to fix the config. Set to 'no' if you do not want this Docker to mess with your SavePath config." | ts '%Y-%m-%d %H:%M:%.S'
    export CORRECT_SAVEPATH="yes"
fi

if [[ ${CORRECT_SAVEPATH} == 'yes' ]]; then
    # Getting the current TempPathValue value
    TEMPPATHVALUE=$(sed -n '/\[Preferences]/,$p' '/config/qBittorrent/config/qBittorrent.conf' | grep -i "TempPathEnabled" | sed 's/^.*=//')
    # Removing the old lines
    sed -i '/Downloads\\SavePath=\/downloads\/\|Downloads\\TempPath=\/downloads\/temp\/\|Downloads\\TempPathEnabled=*/d' "/config/qBittorrent/config/qBittorrent.conf"
    # Insert the new lines at the correct section
    sed -i "/^\[BitTorrent]/a Session\\DefaultSavePath=\/downloads\nSession\\TempPath=\/downloads\/temp\nSession\\TempPathEnabled=${TEMPPATHVALUE}" "/config/qBittorrent/config/qBittorrent.conf"
    cp -r /config/qBittorrent/downloads/* /downloads -vvvv && rm -rf /config/qBittorrent/downloads -vvvv
    for fastresumefile in /config/qBittorrent/data/BT_backup/*.fastresume
    do
        echo "Processing fastrume file $fastresumefile"
        sed -i 's/savePath29\:\/config\/qBittorrent\/downloads/savePath10\:\/downloads/g' "$fastresumefile"
        sed -i 's/savePath29\:\/config\/qBittorrent\/downloads/savePath10\:\/downloads/g' "$fastresumefile"
    done
else
    echo "[WARNING] You have set CORRECT_SAVEPATH as: '${CORRECT_SAVEPATH}'. Please check the qBittorrent settings to make sure your save paths are corrent!" | ts '%Y-%m-%d %H:%M:%.S'
fi

 

I get an issue where the container will reboot in a loop on Unraid 6.10.0 rc2 (also happened on 6.9) and this gets spammed in my logs for the container
2022-03-22 18:34:30 write UDP: Operation not permitted (code=1)
2022-03-22 18:34:31 write UDP: Operation not permitted (code=1)
2022-03-22 18:34:32.071446 [ERROR] Network is possibly down.
2022-03-22 18:34:32 write UDP: Operation not permitted (code=1)
2022-03-22 18:34:32.071446 [ERROR] Network is possibly down.
2022-03-22 18:34:32 write UDP: Operation not permitted (code=1)
2022-03-22 18:34:32 write UDP: Operation not permitted (code=1)

Been racking my brain on this for a day or so... Can someone lend me a hand and help me understand in simple terms how to set this up to be able to access the WebUI via a port other than 8080?

8 minutes ago, syphant said:

Been racking my brain on this for a day or so... Can someone lend me a hand and help me understand in simple terms how to set this up to be able to access the WebUI via a port other than 8080?

 

Edit this Docker Container in Unraid, set the WEBUI_PORT environment variable to something else.

Start the container. You should now be able to access it to the port you did set.

After a host reboot, I can't access the WebUI of Qbittorentvpn when the VPN is enabled. If I disable the VPN I can access no issues, when I enable the VPN nothing loads in the browser and I get: 

 

This site can’t be reached

192.168.1.245 refused to connect

 

Is there something quick to check? I have been digging through the forum threads, docker support, github support and not having much luck I don't understand why it is suddenly not working. Attached Log of the docker

qbittorrentVPN_Log.docx

23 minutes ago, coachflip said:

Attached Log of the docker

please attach a plain text, not docx, of the supervisord log, be sure to redact credentials.

On 5/10/2022 at 8:19 PM, JonathanM said:

please attach a plain text, not docx, of the supervisord log, be sure to redact credentials.

I don't see it under AppData\qbittorrentvpn like I used to, where would that file be? Sorry, learning the linux/docker world.

 

On 5/11/2022 at 1:53 AM, coachflip said:

After a host reboot, I can't access the WebUI of Qbittorentvpn when the VPN is enabled. If I disable the VPN I can access no issues, when I enable the VPN nothing loads in the browser and I get: 

 

This site can’t be reached

192.168.1.245 refused to connect

 

Is there something quick to check? I have been digging through the forum threads, docker support, github support and not having much luck I don't understand why it is suddenly not working. Attached Log of the docker

qbittorrentVPN_Log.docx 13.55 kB · 2 downloads

EDIT: I had not set LAN_NETWORK correct.

 

I've started experiencing the same. WebUI works as soon as I disable VPN. I've attached "docker" logs and specific qbittorrent logs.

 

BR,

Jorgensen

 

Edited July 7, 20224 yr by Jorgensen
Solution

18 hours ago, Jorgensen said:

I've started experiencing the same. WebUI works as soon as I disable VPN. I've attached "docker" logs and specific qbittorrent logs.

 

BR,

Jorgensen

qbittorrent.log 3.46 kB · 2 downloads qbittorrent-docker.log 4.42 kB · 2 downloads

I never resolved this issue and no one ever responded, I hope you get some help on this!

 

3 hours ago, coachflip said:

I never resolved this issue and no one ever responded, I hope you get some help on this!

 

Ok, so I solved my problem, thanks to binhex

The IP of the computer I was attempting to access the WebUI was not part of the LAN_NETWORK. In the qBittorrentVPN edit page, set the proper LAN_NETWORK environment variable and it works for me.

Edited July 6, 20224 yr by Jorgensen
formatting

What's the purpose of the TCP and UDP listening port options that are defaulted to 8999? Do these correspond to the qbittorrent Settings > Connections > Listening Port? I'm trying to figure out if I need to change this for port forwarding from my VPN provider.

I have a wireguard server hosted and that's what I connect to for this. As far as I'm aware it's setup correctly, however, I still have the yellow flame icon, no direct connections. However, I don't appear to have any issues connecting to peers or them connecting to me when seeding.

 

Does that mean it's ok or do I still have a problem?

8 hours ago, Benji said:

I have a wireguard server hosted and that's what I connect to for this. As far as I'm aware it's setup correctly, however, I still have the yellow flame icon, no direct connections. However, I don't appear to have any issues connecting to peers or them connecting to me when seeding.

 

Does that mean it's ok or do I still have a problem?

 

Mine has always been orange and I never bothered to look into it hahahaha, never had problems downloading or connection issues