I don't think this is the issue for any of the other people in the thread right now, but I wanted to make another post with an issue I had/have and tentatively solved.

I've noticed PIA has been quite flakey over the past few weeks, and posts on the PIA subreddit indicate I'm not the only one. The problems seem to be related (but possibly not limited) to some API change to port forwarding. Their support staff is being really evasive about this and it's unclear what they're doing.

I was using the ca-toronto .ovpn file, which up until recently was working fine. Following the suspected API change the Toronto endpoint was for some reason no longer supported. The confusing part is that Toronto is the list that the script produces (under ca-toronto.pvt.site). I imagine this would be rather confusing to anyone trying to understand the problem from logs, but not technical enough to inspect the container or understand why it broke.

One of the trackers I use requires port forwarding so this was the source of considerable frustration. However, I think I was able to resolve it by switching to Wireguard and changing the wg0.conf endpoint to ca-toronto.pvt.site. I did this earlier today and actually gave up on it because it didn't seem to be working on that tracker, but was still functional for normal trackers (and I didn't have any more time to devote to it). But a few hours later I checked the tracker and surprisingly it was connectable and seeding. The delay was probably due to the site not updating frequently, but it's worth pointing out for others who might be actively debugging as I was.

For anyone else with a similar issue, switching to Wireguard is an easy thing to try before you spend too much time getting OpenVPN to work.

Edited October 16Oct 16 by nft2
Removed an erroneous conclusion about the ovpn file being broken.

47 minutes ago, nft2 said:

I'm not sure why PIA made this change without updating the configs they let you download,

The ovpn file doesn’t get any sort of automated update. It would have to be updated manually by you to change the endpoint. PIA has changed the names of a fair number of their port forwarding sites over the past couple of months and will probably continue to do so.

FYI- this problem can also happen with the wg0 config file.

Hello all, I'm having trouble trying to save the mover.Py file to the appropriate location. I simply cannot find it. I know this should be relatively easy but it's driving me nuts. My diagnostics is below if anyone can help me.

/mnt/user/appdata/scripts

nas-diagnostics-20261016-0050.zip

I tried to post to diagnostics area but they suggested post here...

Edited October 16Oct 16 by WanderingGander.87
Add location.

On 10/15/2026 at 12:28 PM, binhex said:

You didnt answer this question directly, what is the ip address of the machine?, i want to ensure LAN_NETWORK is defined correctly (a very common trip up), keep in mind if your machine is on a different VLAN it will be blocked irresepective of your VLAN ruleset.

Can you also tell me is the network for the container is set to bridge?, i have a feeling its not, if not please switch it to bridge then try again.

Thank you! The LAN_NETWORK suggestion let me in the right direction.
Even though I've put the docker on a separate VLAN 10.0.1.0/24, I had to enter 10.0.0.0/24 in the LAN_NETWORK for it to work :)

46 minutes ago, GnaXi said:

Thank you! The LAN_NETWORK suggestion let me in the right direction.
Even though I've put the docker on a separate VLAN 10.0.1.0/24, I had to enter 10.0.0.0/24 in the LAN_NETWORK for it to work :)

The LAN_NETWORK setting is for networks that you want to have access to the app, not necessarily the same as the network the docker is using. If you are using some other network to access the app remotely you may also need to enter it. Comma separated.

8 minutes ago, nft2 said:

I understand that. The configs that are currently downloadable on the site are what don't match the values on the server list. If you're talking about the configs zip on their site not getting an update when they change it, it should.

I see, your saying that if you download a new ovpn file the endpoints are wrong.👎

1 hour ago, wgstarks said:

I see, your saying that if you download a new ovpn file the endpoints are wrong.👎

Thinking about this I realized that this problem specifically might not be a PIA issue (though as I said there is some ongoing debacle involving port forwarding). Too much posting and too little sleep. During my debugging I changed the .ovpn config to have the ca-toronto.pvt.site endpoint, but that didn't work. Meaning the .ovpn file is still correct for its purpose.

Let me experiment with this for a bit and see what I can put together.

Update: I was able to fix this in the container. I guess previously the DNS endpoints matched the ones in the .ovpn consistently. Anyway I submitted a PR https://github.com/binhex/arch-int-vpn/pull/60.

Thanks again to @binhex for this project. If this helps out, I'm glad I could lend a hand.

Edited October 16Oct 16 by nft2

Brand new user to unraid here. Trying to set up my first unraid home server. Having some issues, and I'm sure there will be more, so I'm going to be asking for some help from the kind people here willing to lend a hand.

-

My qbittorrent wouldn't start after working perfectly yesterday, so I restarted my machine, but it still wouldn't work. Then I checked the logs and found this:

docker: Error response from daemon: exit status 2: "/sbin/zfs snapshot vms-appdata/87eb9f3b109c8cf3ad5f1064cb2275a67335cb50b2e94dec283cb9a00dcc8ec9@685562554" => cannot open 'vms-appdata/87eb9f3b109c8cf3ad5f1064cb2275a67335cb50b2e94dec283cb9a00dcc8ec9': dataset does not exist

"vms-appdata" is the pool on which "appdata" and "system" is located.

-

Then I activated debugging on the docker image, but it failed with this error:

Error response from daemon: No such container: binhex-qbittorrentvpn

The docker container was then gone, and can't be reinstalled due to the first error.

-

When the system and appdata shares were originally created, it was automatically created on pool "main-storage". I quickly moved them to "vms-appdata", but a single "system"-folder remained on "main-storage", and I can't delete it from the file manager. I don't know if this is related to this other issue. As long as this isn't causing problems, my OCD ass can live with it.

-

I don't know what has gone wrong, nor how to further troubleshoot this. I don't know what commands to give docker permission to read and write to "vms-appdata". If anyone has any guides I should read, I'm more than willing to do so. If anyone has any tips or ideas, I welcome it. I would prefer not to have to delete my "vms-appdata" pool, reconfigure it, and then restore from backups (I don't even know how to restore appdata backups yet, especially when it comes to likely having to use commands to set correct permissions, but I do already have appdata backups).

-

edit: Seems I might have slightly misunderstood the nature of the error. It might have access to vms-appdata to some extent, but it doesn't seem like this specific docker container gets access to at least read there there, unless I'm misunderstanding something. Other docker containers still seem to work.

-

edit 2: Everything in the "binhexqbittorrentvpn"-folder under "appdata" was gone. I deleted the folder too since I was going to try to delete everything and see if that made it possible to reinstall. Still impossible to reinstall.

This comment was originally published to the unraid subreddit on reddit.com

Edited October 24Oct 24 by Almo96

Script: move finished torrents into dated folders so same-named downloads don't overwrite each other

Hi all,

If you use qBittorrent's "Set location" / move-on-complete with a shared final folder, you may have been bitten by this: a newer torrent with the same file or folder name as an older one silently overwrites it.

I wrote a small bash script that runs inside binhex-qbittorrentvpn and avoids that. Each finished torrent whose save path is exactly one of your configured final folders gets moved through the WebUI API into a subfolder named after its completion date:

/data/a/linux.iso -> /data/a/20261015/linux.iso

If something with the same name is already in that folder (on disk, or claimed by another torrent in qB), it uses 20261015_1, 20261015_2 and so on instead. Dated folders that end up empty (e.g. after you delete torrents with their files) are removed at the end of each run.

Setup (binhex-qbittorrentvpn):

1. Put qb-dated-move.sh into /mnt/user/appdata/binhex-qbittorrentvpn/scripts/ (that's /config/scripts/ inside the container).

2. Copy qb-dated-move.conf.example to qb-dated-move.conf in the same folder and fill in your WebUI user/password and final folders. Use container paths, the way qB shows them. Then:

chown nobody:users qb-dated-move.conf
chmod 600 qb-dated-move.conf

3. In qB: Tools → Options → Downloads → Run external program → Run on torrent finished:

/bin/bash /config/scripts/qb-dated-move.sh

curl, jq and flock are already in the binhex image, so nothing else needs to be installed.

Try it first without moving anything:

docker exec -it binhex-qbittorrentvpn bash

to enter qB's container (assumes the container is still called binhex-qbittorrentvpn), or use qB's Console. Then:

DRY_RUN=1 /config/scripts/qb-dated-move.sh

The log is at /config/scripts/qb-dated-move.log. To sort an existing backlog, you can limit a manual run to older torrents with MIN_AGE_MONTHS=12.

Tested with qBittorrent 5.2.4. Torrents with Automatic Torrent Management enabled are untested. Before the first big run, best back up /config/qBittorrent/BT_backup.

Source, docs and license (GPL-3.0): https://github.com/kaedinger/qb-dated-move

Feedback and bug reports are welcome, here or as GitHub issues.

On 10/24/2026 at 1:20 PM, Almo96 said:

Brand new user to unraid here. Trying to set up my first unraid home server. Having some issues, and I'm sure there will be more, so I'm going to be asking for some help from the kind people here willing to lend a hand.

-

My qbittorrent wouldn't start after working perfectly yesterday, so I restarted my machine, but it still wouldn't work. Then I checked the logs and found this:

docker: Error response from daemon: exit status 2: "/sbin/zfs snapshot vms-appdata/87eb9f3b109c8cf3ad5f1064cb2275a67335cb50b2e94dec283cb9a00dcc8ec9@685562554" => cannot open 'vms-appdata/87eb9f3b109c8cf3ad5f1064cb2275a67335cb50b2e94dec283cb9a00dcc8ec9': dataset does not exist

"vms-appdata" is the pool on which "appdata" and "system" is located.

-

Then I activated debugging on the docker image, but it failed with this error:

Error response from daemon: No such container: binhex-qbittorrentvpn

The docker container was then gone, and can't be reinstalled due to the first error.

-

When the system and appdata shares were originally created, it was automatically created on pool "main-storage". I quickly moved them to "vms-appdata", but a single "system"-folder remained on "main-storage", and I can't delete it from the file manager. I don't know if this is related to this other issue. As long as this isn't causing problems, my OCD ass can live with it.

-

I don't know what has gone wrong, nor how to further troubleshoot this. I don't know what commands to give docker permission to read and write to "vms-appdata". If anyone has any guides I should read, I'm more than willing to do so. If anyone has any tips or ideas, I welcome it. I would prefer not to have to delete my "vms-appdata" pool, reconfigure it, and then restore from backups (I don't even know how to restore appdata backups yet, especially when it comes to likely having to use commands to set correct permissions, but I do already have appdata backups).

-

edit: Seems I might have slightly misunderstood the nature of the error. It might have access to vms-appdata to some extent, but it doesn't seem like this specific docker container gets access to at least read there there, unless I'm misunderstanding something. Other docker containers still seem to work.

-

edit 2: Everything in the "binhexqbittorrentvpn"-folder under "appdata" was gone. I deleted the folder too since I was going to try to delete everything and see if that made it possible to reinstall. Still impossible to reinstall.

This comment was originally published to the unraid subreddit on reddit.com

Unfortunately I don't have a lot of advice to give you other than saying that this looks like more of an issue with your ZFS pool/config than any docker. Does anything else in that pool work?

I'm not sure if having different pools is a more common approach vs my somewhat older setup, but "don't go against the grain" is always good advice if you're new to it (meant with no offense). It can just be harder to debug and get help with a more exotic setup.

37 minutes ago, nft2 said:

Unfortunately I don't have a lot of advice to give you other than saying that this looks like more of an issue with your ZFS pool/config than any docker. Does anything else in that pool work?

I'm not sure if having different pools is a more common approach vs my somewhat older setup, but "don't go against the grain" is always good advice if you're new to it (meant with no offense). It can just be harder to debug and get help with a more exotic setup.

I'm having zero other issues with that pool. Everything else seems to work as it should. Not that I have gotten to the testing phase of my arr-stack yet, but I've followed the trash guides with zero issues so far. Web UI for docker apps works fine, except for binhex-qbittorrentvpn.

I'll try moving everything off the pool and re-creating it tomorrow. I don't want to nuke everything and have to deal with backups yet, and I'm not redoing all the profiles or whatever in sonarr and radarr. Hopefully just moving the shares won't break anything else.

15 hours ago, Almo96 said:

I'm having zero other issues with that pool. Everything else seems to work as it should. Not that I have gotten to the testing phase of my arr-stack yet, but I've followed the trash guides with zero issues so far. Web UI for docker apps works fine, except for binhex-qbittorrentvpn.

I'll try moving everything off the pool and re-creating it tomorrow. I don't want to nuke everything and have to deal with backups yet, and I'm not redoing all the profiles or whatever in sonarr and radarr. Hopefully just moving the shares won't break anything else.

This did not work. Everything else works, binhex-qbittorrentvpn won't even install or show up under "docker", despite working perfectly a few days ago.

If binhex ever reads this, can you help, or do I have to reinstall unRAID and redo everything in the hopes of that fixing it? I'd rather not redo everything.

Edit: I was a bit quick on the draw. It seemed like everything* was working, but after moving the shares I'm getting the same or a very similar issue on all the docker containers. I have opened a ticket with unRAID support, and I hope they will assist. Worst case scenario I'll have to reinstall unraid and redo all or at least most configuration.

Edited October 27Oct 27 by Almo96
Edit 1: I made a mistake. edit 2: typo

8 minutes ago, Almo96 said:

This did not work. Everything else works, binhex-qbittorrentvpn won't even install or show up under "docker", despite working perfectly a few days ago.

If binhex ever reads this, can you help, or do I have to reinstall unRAID and redo everything in the hopes of that fixing it? I'd rather not redo everything.

Try a fresh install and just put a hyphen at the end of the name. Like binhex-qbittorrentvpn- to force a new install.

22 hours ago, strike said:

Try a fresh install and just put a hyphen at the end of the name. Like binhex-qbittorrentvpn- to force a new install.

I will unless unRAID support can help me within the weekend. Hopefully I'll get to restore Sonarr and Radar configurations without having to redo all that, without creating other issues with permissions or something. The rest shouldn't take too long to do, given that I know how to do it now.

Edit: I misunderstood your comment. Due to new errors having shown up, I meant that I will reinstall unRAID if unRAID support doesn't help me by the weekend. See the edit in my previous comment.

Edited October 28Oct 28 by Almo96
Clarification

Apparently my newest issue seems to have been caused by running Docker data-root: as a directory while using ZFS filesystem. A guide that likely wasn't meant for ZFS suggested I use that setting, now I know not to do that. Limetech responded quickly and knew what the problem was. Qbittorrentvpn is also now installed, and webgui seems to work. Thanks to everyone who attempted to assist me.

I have binhex-qbittorrentvpn using PIA + WireGuard, with NZBGet normally sharing its network.

This worked fine until a couple of days ago. qBittorrent itself still works, but NZBGet now connects and authenticates to UsenetServer, then stalls. I also tested TweakNews with the same result.

Through the VPN:

200 Welcome

381 PASS required

281 Welcome

Then even a simple NNTP DATE command gets no response.

The same test directly from the Unraid host, outside the VPN, gives:

200 Welcome

381 PASS required

281 Welcome

111 <date>

205 Goodbye

I also tried different PIA UK endpoints, ports 563/443/119, and TLS 1.2/1.3. Same result through the VPN.

If I put NZBGet into normal Bridge mode, it immediately works again.

qBittorrent traffic through the VPN still works normally.

Has anyone seen this with PIA/WireGuard recently, or have any idea what I should check next? This is getting beyond my networking knowledge, so happy to run any tests/log commands suggested.

Edited October 29Oct 29 by TexasDave

qBittorrent 5.3.0 got released last week but if you're on private trackers, there is a chance they are NOT supported 5.3.0 yet. So if you upgraded the docker container (or it upgrades automatically) and you can't connect to the trackers, it's because you're using an unsupported 5.3.0 client.

You'll need to roll back to a previous version.

31 minutes ago, ryans100 said:

qBittorrent 5.3.0 got released last week but if you're on private trackers, there is a chance they are NOT supported 5.3.0 yet. So if you upgraded the docker container (or it upgrades automatically) and you can't connect to the trackers, it's because you're using an unsupported 5.3.0 client.

You'll need to roll back to a previous version.

What about public trackers? They don't work for me either.

Nothing would download. Left the computer for a while, and came back to one torrent being at 99.6 %, but it's stuck again, and nothing else will download. Fails to connect to most trackers.

I guess this isn't the place to get support for that. I'll head over to the qbittorrent subreddit tomorrow, with all the obligatory information they request for helping people (it's in the subreddit's rules).

I'm having permissions issues. Is this the right place to ask for assistance?

Qbittorrent logs has these errors in them:

(W) 2026-10-29T15:39:14 - File error alert. Torrent: "Whats New Scooby-Doo S02 1080p AMZN WEB-DL H 264-RCVR". File: "/torrents/torrents/temp/prowlarr/Whats New Scooby-Doo S02 1080p AMZN WEB-DL H 264-RCVR/Whats.New.Scooby-Doo.S02E02.Mummy.Scares.Best.1080p.AMZN.WEB-DL.DDP2.0.H.264-RCVR.mkv". Reason: "c16893 file_open (/torrents/torrents/temp/prowlarr/Whats New Scooby-Doo S02 1080p AMZN WEB-DL H 264-RCVR/Whats.New.Scooby-Doo.S02E02.Mummy.Scares.Best.1080p.AMZN.WEB-DL.DDP2.0.H.264-RCVR.mkv) error: Permission denied"

Qbittorrent creates some folders, but the folders for the torrents/download are created as read-only and are stuck at 0 bytes.

If anyone can help, but need more information, please tell me what to do.

Edit: Nevermind. I think this is another problem on the server. I think I will have to reach out to unraid support again.

Edited Saturday at 08:44 PM4 days by Almo96
Additional information

On 10/29/2026 at 11:44 AM, ryans100 said:

qBittorrent 5.3.0 got released last week but if you're on private trackers, there is a chance they are NOT supported 5.3.0 yet. So if you upgraded the docker container (or it upgrades automatically) and you can't connect to the trackers, it's because you're using an unsupported 5.3.0 client.

You'll need to roll back to a previous version.

On 10/29/2026 at 11:44 AM, ryans100 said:

qBittorrent 5.3.0 got released last week but if you're on private trackers, there is a chance they are NOT supported 5.3.0 yet. So if you upgraded the docker container (or it upgrades automatically) and you can't connect to the trackers, it's because you're using an unsupported 5.3.0 client.

You'll need to roll back to a previous version.

How to do this?

7 hours ago, Randyd718 said:

How to do this?

Go to the docker tab and find the binhex-qbittorrentvpn docker. When you click the name it’ll open the configuration page.

In the repository field you’ll need to edit it to append a colon and then the tag that you want to use. Valid tags can be found on the dockerhub page linked in the first post. Once the tag has been entered scroll to the bottom of the page and click “apply”.

On 10/29/2026 at 5:44 PM, ryans100 said:

qBittorrent 5.3.0 got released last week but if you're on private trackers, there is a chance they are NOT supported 5.3.0 yet. So if you upgraded the docker container (or it upgrades automatically) and you can't connect to the trackers, it's because you're using an unsupported 5.3.0 client.

You'll need to roll back to a previous version.

SOLVED: I had left my docker to upgrade automatically and have since rolled back. I'm now getting an issue where the former username and password combination fails to log me into the web ui and my laptop IP has been blocked. Any idea how I can recover access in the downgraded 5.2.4-1-02 branch?

Was stuck then found the wiki: https://github.com/qbittorrent/qBittorrent/wiki/Web-UI-password-locked-on-qBittorrent-NO-X-%28qbittorrent-nox%29

Deleting the line in conf file got me back to the login but still not able to log in until I found the temporary password using this grep line in the qbittorrrentvpn console: grep -i -E 'password|administrator username' /config/supervisord.log \ | tail -n 10

updating in case this helps others out - or more likely me in 6 months time when I make another hash of things...

Edited Tuesday at 09:06 PM1 day by DrBazUK
adding context for attempt to fix...