Posts by AustinML

YES! Success! Here's what I did/learned:

AT gderf 's suggestion I tried the trigus42/qbittorrentvpn image. The git page had some example yaml files so I decided to go the wireguard route instead based on BernH 's suggestion. The container started with no errors but I was still getting the super informative "Unauthorized" message. I went down that google path again and found this comment deep in this reddit thread:

Kommentar von SoftwareCreatorzu „qbittorrent web ui running on docker says unauthorized“

Entdecke dieses Gespräch und mehr aus der Community docker

www.reddit.com

So spun the container down, added 'WebUI\HostHeaderValidation=false' to the config file (this disables CSRF which apparently causes some of the webui port not matching issues) and I was finally able to get to the qbittorrent login screen and logged in.

I then checked the ip address of my router and verified that it was different than inside the container using:

docker exec qbittorrentvpn curl ifconfig.me/ip

and they were different. Success!

Thank you both for your help! I will probably still go down the gluetun route at some point though as I'd like to separate the qbittorrent and vpn images and possible route a few other things through it.

Cool - I'll try that one next. Arch was a failure but not sure I nailed all those options around the VPN. Maybe it's time to finally go down the gluetun route. I keep hear it's simple but I watched a couple YT videos on it and it didn't seem that simple to me. But I'm pretty much a caveman with a chainsaw over here...

Yeah I tried both of those and that makes sense - thank you. I am now trying this image:

binhex/arch-qbittorrentvpn

which has similar options to the base non-vpn image I tried. Fingers crossed.

Quote from gderf

And what are these line items you have tried?

If you are editing the qbittorrent.conf file while the container is running that will not work.

I'd have to go back and find the but I've since removed them. Something along the lines of webauthenabled=true/false or similar. I was keeping relatively decent track of changes initially but then started throwing everything against the wall to see if I could get anything to stick. And I did spin down the containers before editing the conf file thanfully.

But now that I can get the non-vpn base image running I at least know that part is possible. So I'm happy to start from scratch again with a vpn image.

OK, I did now get the base linuxserver/qbittorrent image to work. Yay! I read on that docker hub page:

Quote

WEBUI_PORT variable

Due to issues with CSRF and port mapping, should you require to alter the port for the web UI you need to change both sides of the -p 8080 switch AND set the WEBUI_PORT variable to the new port.

For example, to set the port to 8123 you need to set -p 8123:8123 and -e WEBUI_PORT=8123

So once I changed all the ports to 8990, I could get it running on omv:8990 and was able to log in with the temp password I found in the container logs.

But of course, at least so far, non of the qbittorrentvpn images seem to work that way. I'd be happy to move my other service to another port though if I have to. And it seems I can use either a wireguard config or openvpn config with my VPN. So what is my best path forward now?

Yeah I can't even get a login screen without VPN so I think I have simpler issues. Even if I shut down my service on 8080 and don't try to change the qbittorrent webui ports (leaving them at 8080), the best I get is that single word "Unauthorized". I've tried adding some line items to the config to supposedly get round the login check but that hasn't helped.

My VPN is IPVanish so I use their openvpn files. Basically I spin up the container to create the folder structure, spin it down, add the ovpn files/certs, then spin it back up.

I think that makes sense but I can't even get to a login screen where I would even enter a password - on either a plain qbittorrent install or any that I've tried with vpn. I'm not sure I get how to use my VPN with the hotio link you have there but happy to try if I can.

In looking through the logs on my latest attempt I got this error around my opvenvpn setup (I use IPVanish for VPN):

2026-01-30 19:02:32 [INFO] Choosen VPN config: 'ipvanish-US-Dallas-dal-b69.ovpn'
2026-01-30 19:02:32 [INFO] Using credentials from /config/openvpn/ipvanish-US-Dallas-dal-b69_credentials.conf
2026-01-30 19:02:32 [INFO] VPN_REMOTE defined as 'dal-b69.ipvanish.com'
2026-01-30 19:02:32 [INFO] VPN_PORT defined as '443'
2026-01-30 19:02:32 [INFO] VPN_PROTOCOL defined as 'udp'
2026-01-30 19:02:32 [INFO] VPN_DEVICE_TYPE defined as 'tun0'
2026-01-30 19:02:32 [INFO] Starting OpenVPN...
--------------------
2026-01-30 19:02:32 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Options error: Unrecognized option or missing or extra parameter(s) in /config/openvpn/ipvanish-US-Dallas-dal-b69.ovpn:24: keysize (2.6.16)
Use --help for more information.
--------------------
2026-01-30 19:02:32 [ERROR] Failed to start OpenVPN
s6-rc: warning: unable to start service init-vpn: command exited 1
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.

No idea what to do with that - I got that opvn file directly from their site.

Long story short - my drive I ran all my docker stuff on failed and I've been rebuilding it mostly easily and quickly. However I am now trying to get my qbittorrentvpn docker back and up and running and have been beating my head against the wall for ~4 hours now. I remember this being a huge pain when I originally set it up as well and of course have completely forgotten exactly how I did that. I vaguely remember the webui port being pain point but not sure - I do have a container already running on 8080 but I suppose I could adjust that if needed.

So far I've tried buidling files off of the following on dockerhub:

• markusmcnugen/qbittorrentvpn
• dyonr/qbittorrentvpn
• trigus42/qbittorrentvpn

I also tried just the vanile bittorrent (without vpn):

• linuxserver/qbittorrent

using the following

---
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=100
      - TZ=America/Chicago
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    volumes:
      - /srv/dev-disk-by-uuid-92401814-b838-4ee6-b2e8-98b7bc281a29/appdata2/qbittorrent:/config
      - /srv/dev-disk-by-label-data2/download:/downloads
    ports:
      - 8990:8080
      - 6881:6881
      - 6881:6881/udp
    restart: unless-stopped

I've messed with the webui port defined here as well but the closest I've gotten to anything actually running is a simple 'Unauthorized' message when the container is running. This happened whether the "external" port was set to 8990 as shown above or left as 8080. If the webui port is defined as anything other than 8080 I just get the basic "This site can't be reached" error message.

I dug through several threads on this forum as well but none of what was tried in those got me any further. I'd be happy to try routing through wireguard if that is somehow easier as I have that up and running through the plugin. I just know I had it working through my vpn previously.

I'd also be happy to provide any logs/etc. Here is the main docker log from the container when it is running:

[migrations] started
[migrations] no migrations found
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1000
User GID:    100
───────────────────────────────────────
Linuxserver.io version: 5.1.4-r1-ls438
Build-date: 2026-01-25T07:04:04+00:00
───────────────────────────────────────
    
[custom-init] No custom files found, skipping...
WebUI will be started shortly after internal preparations. Please wait...

******** Information ********
To control qBittorrent, access the WebUI at: http://localhost:8080
The WebUI administrator username is: admin
The WebUI administrator password was not set. A temporary password is provided for this session: HQPBdXyhf
You should set your own password in program preferences.
Connection to localhost (::1) 8080 port [tcp/http-alt] succeeded!
[ls.io-init] done.

Thank you in advance for any help you can give!

YES! That fixed it. So either the first image I pulled was borked somehow or maybe there was an error with that release as it seems to have pulled a slightly newer image this time. Either way, thank you all for your help!

Sorry, was out of town for a few days. But unfortunately, none of that fixed it. Here is my current file:

---
services:
  sabnzbd:
    image: lscr.io/linuxserver/sabnzbd:latest
    container_name: sabnzbd
    environment:
      - PUID=1000
      - PGID=100
      - TZ=America/Chicago
    volumes:
      - /srv/dev-disk-by-uuid-92401814-b838-4ee6-b2e8-98b7bc281a29/appdata2/sabnzbd/config:/config
      - /srv/dev-disk-by-uuid-92401814-b838-4ee6-b2e8-98b7bc281a29/appdata2/sabnzbd/incomplete:/incomplete-downloads 
      - /srv/dev-disk-by-label-data2/download:/downloads 
    ports:
      - 8080:8080
    restart: unless-stopped

It did create the /sabnzb/confg directory but the result was the same error and same log (this one for the service but same error):

sabnzbd  | s6-rc-compile: fatal: invalid /etc/s6-overlay/s6-rc.d/init-sabnzbd-config/type: must be oneshot, longrun, or bundle

I wonder if the unpacking of the download from dockerhub is bad? I can't seem to force it to redownload, unpack, etc. It just keeps recreating the container from the current one.

Since losing my config share folder which ran all my docker containers, I've decided to rebuild them all in the built in GUI (they were all previously built in Portainer). I have had zero issues with any of them so far except for sabnzb. For some reason, I can not get this one to work at all. Here is my docker compose file:

services:
  sabnzbd:
    image: lscr.io/linuxserver/sabnzbd:latest
    container_name: sabnzbd
    environment:
      - PUID=1000
      - PGID=100
      - TZ=America/Chicago
    volumes:
      - /srv/dev-disk-by-uuid-92401814-b838-4ee6-b2e8-98b7bc281a29/appdata2/sabnzbd/:/config
      - /srv/dev-disk-by-uuid-92401814-b838-4ee6-b2e8-98b7bc281a29/appdata2/sabnzbd/incomplete/:/incomplete-downloads 
      - /srv/dev-disk-by-label-data2/download/:/downloads 
    ports:
      - 8080:8080
    restart: unless-stopped

This is just the listed example file on docker hub with my edits for env and vol stuff. I also tried NZBGet and that worked fine with almost the exact same variables (I just prefer Sabnzb). The file creates the container but when I try to go to the GUI, it just times out and says the site can't be reached. It also doesn't create any config files in the linked share folder. It DOES create the folders listed above, it just doesn't populate them with anything. It's possible nothing will be created until I go through a setup script?

The only log created when I try to create the container is:

s6-rc-compile: fatal: invalid /etc/s6-overlay/s6-rc.d/init-sabnzbd-config/type: must be oneshot, longrun, or bundle

I googled all over the place for this error and tried things like re-pulling the image, deleting all created folders, etc. etc. but I get the same result every time.

Thank you in advance for any help!

I had a feeling this would not be simple, but not for the actual reason(s) it won't be. Thank you both for your help. It's not the worst thing to rebuild my handful of containers and it's an excuse to finally move it all into the compose GUI vs. Portainer. And I can probably pull a few config files here and there to try to speed the process of tweaking it back to where I had it. I'll probably use it as an excuse to upgrade my drive pool as well as I'm actually running out of space there.

Thank you both for your help!

Ahhh, got it, I see what you're getting at.

    volumes:
      - /srv/dev-disk-by-label-work/appdata/radarr:/config
      - /srv/dev-disk-by-label-data1/movies:/movies
      - /srv/dev-disk-by-label-data2/download:/download

So for this one since :/config is app data I'd change that to the new drive but since the other 2 are mapped to my drive pool (which is fine for now), those stay the same. Does that label for the new SSD drive hold however if I move it from the usb enclosure to the internal?

Quote from BernH

I would also recommend that once you get things back in order, you should have a look at the usb drive, and perhaps change the filesystem to something a little more linux native, like ext4 or xfs to ensure it is properly mountable in the future and will carry correct ownership and permissions.

Good call - my guess is it was pre-formatted fat32 or something and I just didn't change it. I'll definitely do that.

Quote from metalman1972

One option:

Initialize the new app data drive and make sure the docker compose files all point to the new drive. It would be useful to know how you went about mapping this, ie in the env file, or differently for each docker compose files. Ideally it would be just updating a single line. This is where I would personally start before doing anything else, identify the mechanism in place that links the containers to the data.

From there, you’ll want to gain access to the backup data. The usb drive is connected but you can’t see it via GUI? Are you able to see it via ssh? If so, the cp command can copy the backup directory fairly easily.

If you have another machine capable of mounting the backup drive, you could use it to copy the backup files to the newly initialized app data disk. it could be a simple drag and drop if the new drive is reachable via network share. You could even set this network share up just for a temporary use.

Once your backups are copied and the docker compose files are correctly pointing to the data, bringing the containers online should restore their configurations to whatever point they were backed up.

Let’s start with the first step, how do your compose files map to the app data?

Display More

Great question - I'm not entirely sure to be honest and without portainer, apparently I can't even see any of them. Once compose was built into the GUI I switched over to using that (actually much easier) but I only have one "file" I built out in that interface. That just simply points ':/config' volumes to individual folders on my 'appdata' share. In Compose-->Settings I point to my 'compose' share and Docker config points to my 'docker' share. All 3 shares are actually on this SSD. And then of course I map whatever other volumes I'm using to their respective shared folders, normally on my large drive pool.

I pulled the USB backup drive and am pulling the appdata folders off of that now. I'll then try to format the new SSD, create the 3 shares, and then move all the files over to the new drive. I'm guessing I can't just point the existing shares to the new locations as the new drive will still be connected by a USB enclosure. I'm confused about how I will be able to open up the server, pull the old drive, install the new one, and get everything running again.

I know OMV has a File Viewer built in but it's pretty limited. I normally use Cloud Commander for moving everything around but that is, of course, in a currently non-working docker container. I suppose it's time to dust off my CLI skills to move these files now?

Well I thought I could figure this out but I'm having some trouble. Long story short, my containers all "disappeared" this morning. After much help from chente over in the Docker forum, I was able to determine my ssd that contains all my docker folders was failing. Specifically, my docker and compose share folders are still fine but my appdata share folder is no longer available, I assume from the SMART error I'm seeing on that drive.

The good news is I back up my 3 docker share folders to a usb drive attached to the server. I honestly don't remember setting it up long ago but I sure am glad I did. However, the file system on that drive is VFAT which for some reason I can't mount or see within the OMV GUI. I'm at best a CLI amateur but I have a general understanding and can follow basic directions. So what is my best path to move the 2 good share folders (docker and compose) plus the backup of the bad share folder (appdata) to a new SSD. Not sure if this matters but the failing SSD is 250Gb and I have a 2Tb drive collecting dust I can use to replace it.

Please let me know if there is further context or info I can provide. I can absolutely set up all my docker containers again on a new drive but I've done TONS of tweaking to some of them that would be hard to replicate. So I'm really hoping it is relatively simple to move the 2 good folders to the new drive and restore the appdata folder from backup.

Thank you in advance for your help!

I think so - never have before but good time to learn it seems.

Thank you for your help!

I have appdata being backed up to a usb drive so hopefully this is a relatively simple fix but not sure what the best process is to replace the drive. I also have a USB SSD enclosure so should be able to do it all on the server?

I think we've hit the issue. Docker storage is in:

/srv/dev-disk-by-label-work/docker

which is on an SSD that is throwing up occasional SMART errors about bad sectors. My "docker" and "compose" shares are showing fine and available but my "appdata" share is showing unavailable.

Starting to smell a lot like a failing SSD or at least enough bad sectors to bork appdata. I know this is not docker related but any advice on capturing as much as possible off that drive before I replace it?

The system showed uptime of several weeks and we haven't had any power outages thankfully. Honestly the system has been working perfectly for months if not years at this point.

Outputs (sorry, not sure how to format):

systemctl status docker -

● docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/docker.service.d
             └─waitAllMounts.conf
     Active: active (running) since Sat 2026-01-24 12:12:04 CST; 45min ago
 Invocation: f0407c2f38af4ad693708e1ebe86737a
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
   Main PID: 9142 (dockerd)
      Tasks: 10
     Memory: 25M (peak: 27.3M)
        CPU: 818ms
     CGroup: /system.slice/docker.service
             └─9142 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

Jan 24 12:12:03 omv dockerd[9142]: time="2026-01-24T12:12:03.384323724-06:00" level=info msg="Restoring containers: start."
Jan 24 12:12:03 omv dockerd[9142]: time="2026-01-24T12:12:03.422570991-06:00" level=info msg="Deleting nftables IPv4 rules" error="exit status 1"
Jan 24 12:12:03 omv dockerd[9142]: time="2026-01-24T12:12:03.454855052-06:00" level=info msg="Deleting nftables IPv6 rules" error="exit status 1"
Jan 24 12:12:04 omv dockerd[9142]: time="2026-01-24T12:12:04.049820227-06:00" level=info msg="Loading containers: done."
Jan 24 12:12:04 omv dockerd[9142]: time="2026-01-24T12:12:04.066319387-06:00" level=info msg="Docker daemon" commit=3b01d64 containerd-snapshotter=false storage-driver=overlay2 version=29.1.5
Jan 24 12:12:04 omv dockerd[9142]: time="2026-01-24T12:12:04.066393676-06:00" level=info msg="Initializing buildkit"
Jan 24 12:12:04 omv dockerd[9142]: time="2026-01-24T12:12:04.101824570-06:00" level=info msg="Completed buildkit initialization"
Jan 24 12:12:04 omv dockerd[9142]: time="2026-01-24T12:12:04.111675780-06:00" level=info msg="Daemon has completed initialization"
Jan 24 12:12:04 omv dockerd[9142]: time="2026-01-24T12:12:04.111816133-06:00" level=info msg="API listen on /run/docker.sock"
Jan 24 12:12:04 omv systemd[1]: Started docker.service - Docker Application Container Engine.

systemctl status compose -

Unit compose.service could not be found.

Seems like a problem

docker ps -a -

CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

There should be 10ish containers listed there