Also having issues with the latest update, getting the error below:

/usr/sbin/init.sh: line 295: /usr/local/bin/dos2unix.sh: No such file or directory

Automatic moves

Currently, qBittorrent is moving my completed files. I've been trying to set this up so that the ARR apps move the files and then delete the torrents themselves once the copy operation is complete, also using hard links.

Can y'all share with me some of your troubleshooting you used to get the ARR apps to remove the completed torrent files and not qBittorent?

I'm also having issues with the latest update.

___. .__ .__

\_ |__ |__| ____ | |__ ____ ___ ___

| __ \| |/ \| | \_/ __ \\ \/ /

| \_\ \ | | \ Y \ ___/ > <

|___ /__|___| /___| /\___ >__/\_ \

\/ \/ \/ \/ \/

https://hub.docker.com/u/binhex/

2025-07-14 15:40:59.227426 [info] Host is running unRAID

2025-07-14 15:40:59.251250 [info] System information: Linux 1fd6c8402678 6.12.24-Unraid #1 SMP PREEMPT_DYNAMIC Sat May 3 00:12:52 PDT 2025 x86_64 GNU/Linux

2025-07-14 15:40:59.274991 [info] Image tags: BASE_RELEASE_TAG=2025071102,INT_RELEASE_TAG=2025071102,IMAGE_RELEASE_TAG=5.1.2-1-04

2025-07-14 15:40:59.301651 [info] PUID defined as '99'

2025-07-14 15:40:59.329299 [info] PGID defined as '100'

2025-07-14 15:40:59.373379 [info] UMASK defined as '000'

2025-07-14 15:40:59.400370 [info] Permissions already set for '/config'

2025-07-14 15:40:59.427806 [info] Deleting files in /tmp (non recursive)...

2025-07-14 15:40:59.458799 [info] VPN_ENABLED defined as 'yes'

2025-07-14 15:40:59.486718 [info] VPN_CLIENT defined as 'wireguard'

2025-07-14 15:40:59.512649 [info] VPN_PROV defined as 'pia'

2025-07-14 15:40:59.547879 [info] WireGuard config file (conf extension) is located at /config/wireguard/wg0.conf

/usr/sbin/init.sh: line 212: /usr/local/bin/dos2unix.sh: No such file or directory

Press ANY KEY to close this window

Fix is in for the dos2unix.sh path issue:

1. Go to unraid web ui/docker tab

2. Toggle to 'advaned view (tp right)

3. Click on 'force update' for qbittorrentvpn container and close window once downloaded

4. Check logs and try accessing web ui.

34 minutes ago, binhex said:

Fix is in for the dos2unix.sh path issue:

1. Go to unraid web ui/docker tab

2. Toggle to 'advaned view (tp right)

3. Click on 'force update' for qbittorrentvpn container and close window once downloaded

4. Check logs and try accessing web ui.

Awesome has been fixed in the latest build, thanks, binhex, you legend!

1 hour ago, binhex said:

Fix is in for the dos2unix.sh path issue:

1. Go to unraid web ui/docker tab

2. Toggle to 'advaned view (tp right)

3. Click on 'force update' for qbittorrentvpn container and close window once downloaded

4. Check logs and try accessing web ui.

I love you.

logfile.txtI woke up this morning and I noticed two things:

1.) I cannot get into the WebUI

2.) My end point is no longer the Netherlands, even though that's what's set in my wgo,conf file.

I've upgraded to the latest version, and I've downgraded to 5.1.1-1-01. Any thoughts on why I can no longer access the web UI?

I've since reupgraded to todays latest image

Edited July 14, 2025Jul 14 by Optimus Prime
context

16 minutes ago, Optimus Prime said:

I've since reupgraded to todays latest image

and that fixed the issue right?, if not follow my previous post, if that still fails then 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

3 hours ago, binhex said:

and that fixed the issue right?, if not follow my previous post, if that still fails then 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

Thank you. Neither downgrading nor upgrading resolved my inability to access the web UI. Attached are the log files. Thank you for having a look.

Update: I was able to log in after disabling the VPN...but now I'm stuck wondering what happened between last night and when I woke up this morning. Thanks again for having a look

supervisord.log command_execution.txt

Edited July 14, 2025Jul 14 by Optimus Prime
More context

7 hours ago, Optimus Prime said:

Thank you. Neither downgrading nor upgrading resolved my inability to access the web UI. Attached are the log files. Thank you for having a look.

Update: I was able to log in after disabling the VPN...but now I'm stuck wondering what happened between last night and when I woke up this morning. Thanks again for having a look

supervisord.log command_execution.txt

Update #2: I sat down at my computer and the Web UI was working...dunno why. Maybe there was an issue with PIA?

Would anyone know why if I'm using the default Netherlands endpoint in the conf file, its always an endpoint other than the Netherlands? Currently, I'm in an asian pacific IP address when I use IP Leak test.

10 hours ago, Optimus Prime said:

Update #2: I sat down at my computer and the Web UI was working...dunno why. Maybe there was an issue with PIA?

Would anyone know why if I'm using the default Netherlands endpoint in the conf file, its always an endpoint other than the Netherlands? Currently, I'm in an asian pacific IP address when I use IP Leak test.

Good morning all. Last night I could resolve the WebUI. Woke up this morning and I can no longer access it. Is anyone else having an intermittent issue with the WebUI?

47 minutes ago, Optimus Prime said:

Good morning all. Last night I could resolve the WebUI. Woke up this morning and I can no longer access it. Is anyone else having an intermittent issue with the WebUI?

This is often caused by connectivity issues but you’ll really need to post the current supervisord log and docker run command for anyone to be able to see what’s happening with your system. Be sure to redact any users/passwords.

1 hour ago, wgstarks said:

This is often caused by connectivity issues but you’ll really need to post the current supervisord log and docker run command for anyone to be able to see what’s happening with your system. Be sure to redact any users/passwords.

Thanks for mentioning this...files attached for whoever could have a look.

docker_run.txt supervisord.log command execution log.txt

Edited July 15, 2025Jul 15 by Optimus Prime

22 minutes ago, Optimus Prime said:

Thanks for mentioning this...files attached for whoever could have a look.

docker_run.txt supervisord.log command execution log.txt

Here's an interesting observation. When I am accessing the WebUI directly via my personal laptop, I seem to have no issue connecting. However, when I switch over to my work laptop and RDP into the personal laptop, the WebUI will not resolve.

I have no issue with any of my other services or dockers. It's just the binhex-qbitorrentvpn

So I just tested...the issue is when my laptop is connected via the WiFi...or any device in the house trying to resolve the WebUI via Wifi. It just doesn't work. Only hardwired devices, my work laptop included, can resolve the WebUI. If I switch either the personal laptop or work laptop to WiFi, they can no longer load the WebUI.

53 minutes ago, Optimus Prime said:

Thanks for mentioning this...files attached for whoever could have a look.

docker_run.txt supervisord.log command execution log.txt

This shows a successful start-

2025-07-15 00:10:00,395 DEBG 'watchdog-script' stdout output:

[info] qBittorrent process listening on port 8080

Are you attempting to connect from the defined LAN?

8 minutes ago, Optimus Prime said:

So I just tested...the issue is when my laptop is connected via the WiFi...or any device in the house trying to resolve the WebUI via Wifi.

Is the WiFi network in the same range as your defined LAN_NETWORK (192.168.4.0/24)?

binhex/arch-qbittorrentvpn:5.1.2-1-03

Fixed the UI save settings issue and also the Wireguard issue.

1 hour ago, wgstarks said:

Is the WiFi network in the same range as your defined LAN_NETWORK (192.168.4.0/24)?

Yes it is...but I just noticed that my Eero has started also handing out 192.168.5.0 range as well...is there a setting on the unraid server or in the container I should use to allow it to accept the .5 addresses as well?

Edit: I just added the .5 range to the Variable Lan variable and it seems to be working now

Edited July 15, 2025Jul 15 by Optimus Prime

13 minutes ago, Optimus Prime said:

Yes it is...but I just noticed that my Eero has started also handing out 192.168.5.0 range as well...is there a setting on the unraid server or in the container I should use to allow it to accept the .5 addresses as well?

Edit: I just added the .5 range to the Variable Lan variable and it seems to be working now

Glad you got it working.👍

Just now, wgstarks said:

Glad you got it working.👍

Thanks for talking it through...

Moving on to DNS leaks

Home IP: xx.xxx.xxx.xxx

curl ifconfig.io: 62.93.178.175 (VPN IP)

dig @resolver1.opendns.com 208.69.35.169 (External DNS resolver IP)

Neither of these is my home IP address. Since the binnex-qbitorrentvpn container is reporting back that OpenDNS sees a different address than one provided by PIA, does this indicate a leak to be concerned about?

1 minute ago, Optimus Prime said:

Moving on to DNS leaks

Home IP: xx.xxx.xxx.xxx

curl ifconfig.io: 62.93.178.175 (VPN IP)

dig @resolver1.opendns.com 208.69.35.169 (External DNS resolver IP)

Neither of these is my home IP address. Since the binnex-qbitorrentvpn container is reporting back that OpenDNS sees a different address than one provided by PIA, does this indicate a leak to be concerned about?

Probably a question for @binhex .

1 hour ago, Optimus Prime said:

Moving on to DNS leaks

Home IP: xx.xxx.xxx.xxx

curl ifconfig.io: 62.93.178.175 (VPN IP)

dig @resolver1.opendns.com 208.69.35.169 (External DNS resolver IP)

Neither of these is my home IP address. Since the binnex-qbitorrentvpn container is reporting back that OpenDNS sees a different address than one provided by PIA, does this indicate a leak to be concerned about?

in a word, no, a DNS leak would be your ISP allocated IP address is seen as the source ip when performing name resolution, as port 53 is not open for your LAN this is not possible, all DNS queries must be performed over the VPN tunnel and thus is leak proof.

5 hours ago, binhex said:

in a word, no, a DNS leak would be your ISP allocated IP address is seen as the source ip when performing name resolution, as port 53 is not open for your LAN this is not possible, all DNS queries must be performed over the VPN tunnel and thus is leak proof.

Thank you for the feedback. Sent you a beer...headed over to Readarr...but just saw the note it's being retired...let us know if you invest time in another ebook app...

15 hours ago, backs1de said:

binhex/arch-qbittorrentvpn:5.1.2-1-03

Fixed the UI save settings issue and also the Wireguard issue.

Thanks so much. This downgrade worked for me. All the other "fixes" didn't (including forcing a latest version update). Using PIA via simple openvpn connection here.