Constant issues getting qBittorrent working in OMV7

1. offizieller Beitrag

    When I try to access the qBittorrent web UI, I get the following (in edge and chrome), when using the default port of 8080:


    Code
    404 page not found

    If I change the webui port to literally anything else not in use, I get:


    Edge:

    Chrome:

    Code
    This site can’t be reached

omv7 refused to connect.

Try:
Checking the connection
Checking the proxy and the firewall

ERR_CONNECTION_REFUSED


    These results have been the same no matter how I deployed, whether I used VPN or not, and no matter how I used VPN.

    I have deployed with the built in Docker Compose plugin.

    I have deployed using Portainer.

    I have deployed using Gluetun as the VPN container

    I have deployed the official qBittorrent container with no vpn settings at all

    I have deployed the markusmcnugen/qbittorrentvpn image (this is what I used on OMV5 and it worked flawlessly) with Gluetun still installed (but not reference by the container)

    I have deployed the markusmcnugen/qbittorrentvpn image without Gluetun installed

    I have deployed in the stack with all the other media containers (will see in the compose file below)

    I have deployed by itself with no other containers installed

    I have deployed in a self stack (only container in the stack in portainer)


    Nothing seems to work. I cannot get the webui of qBittorrent to load. Other webui's for the other containers worked fine.


    Other issues I ran into was docker not liking my environment file for directories, so I had put them all in the yaml.


    My last effort was the container I was using in OMV5 and said to hell with gluetun. But it still didn't work.

    Here's my current yaml:

    My current env file:

    Code
    TIME_ZONE=America/New_York
VPN_SERVICE=Private Internet Access
VPN_USER=(redacted)
VPN_PASSWORD=(redacted)
VPN_REGION="CA Montreal,CA Ontario,CA Toronto,US Atlanta,US East,US Florida,US Houston,US Texas"
PUID=1002
PGID=100
MEDIA_DIRECTORY=/srv/dev-disk-by-uuid-c3affa24-cb7a-4e6c-b37f-7f625a468ca2/Media
INSTALL_DIRECTORY=/Docker_Data/config
DOWNLOAD_DIRECTORY=/srv/dev-disk-by-uuid-c3affa24-cb7a-4e6c-b37f-7f625a468ca2/Downloads/

    The last three lines aren't currently being used because the Docker-Compose plugin was too stupid to decipher it and I kept getting an error about being unable to map it - is this a file or directory, or some BS like that. Portainer had no issue with the volume env variables. The VPN variables were originally put in for Gluetun.


    Please help me getting qBittorrent work again! Thank you!!

  • ryecoaaron

    Hat das Thema freigeschaltet.

    What does the container log say?


    There is an error in the documentation for the markusmcnugen/qbittorrentvpn image. The environment variable - WEBUI_PORT_ENV=8080 is incorrect. The correct variable to use is - WEBUI_PORT=8080


    Also, that image is very touchy with certain settings, especially the port number for this variable. Changing it to something other than 8080 is likely to not work. Also having a host side port other than 8080 is also likely to not work.


    Try changing the variable name and redeploy the container. If it still doesn't work, I suggest not using things like - PUID=${PUID}, etc. Put the actual values in instead.


    If you can't get it working, you may want to try another image:


    https://github.com/DyonR/docker-qbittorrentvpn This image has been deprecated but still works and the documentation is good. It uses the last current version of Qbittorrent that was available at the time of freezing (I don't recall the version). Give it a try.


    If you can get the DyonR image working, you will want to change to my image which is a fork of the DyonR image that keeps Qbittorrent current, as of now, v4.6.4.


    image: gderf/qbittorrentvpn:latest


    Good luck.


    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    Einmal editiert, zuletzt von gderf ()

    Current logs for markusmcnugen/qbittorrentvpn


    I change that line, and there was no change. Tried using port 8080 and using port 8081 and got the same results I've been getting.

    I've tried like 3 or 4 different qBittorrent images, with and without VPN, and I couldn't get none of them to load the webui. They all say they are running. Everything looks like it should work but can't get to the webui.

    Redeployed the official with gluetun - same result. Tried 8080 and 8081



    qbittorent log:

    Gluetun log:


    No tunnel device. Add this to your qbittorrent section.


    Code
    services:
  qbittorrent:
    devices:
      - /dev/net/tun:/dev/net/tun

    With docker run (not compose) it's --device=/dev/net/tun


    You can also add it inside the image if you're rebuilding the image with Dockerfile:


    Code
      if [ ! -c /dev/net/tun ]; then
    mkdir -p /dev/net;
    mknod /dev/net/tun c 10 200
    chmod 600 /dev/net/tun
  fi

    Not recommended but, you can also run as "privileged", with docker run that is --privileged (not sure what it is in compose).

    You are missing NET_ADMIN from your markusmcnugen


    Add it like so:


    Code
    services:
  qbittorrent:
    image: markusmcnugen/qbittorrentvpn:latest
    container_name: qbittorrent
    cap_add:
      - NET_ADMIN

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    Einmal editiert, zuletzt von gderf ()

    Add those, redeployed both, same issue.

    Currently in the "markusmcnugen/qbittorrentvpn" image (no gluetun) and this is the qbittorent log:


    I'm out of suggestions other than to abandon the markusmcnugen image and switch to dyonr, or gderf, or a fork of gderf https://github.com/coldsilk/docker-qbittorrentvpn


    I would also suggest getting a naked docker of linuxserver.io qbittorrent working first before complication things with VPN.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    Zitat von gderf

    I'm out of suggestions other than to abandon the markusmcnugen image and switch to dyonr, or gderf, or a fork of gderf https://github.com/coldsilk/docker-qbittorrentvpn


    I would also suggest getting a naked docker of linuxserver.io qbittorrent working first before complication things with VPN.

    But that's just it, I couldn't get a vanilla qbittorrent client to work. I'll try a few more, but this is driving me insane. It seems like Linux is stuck listening on port 8080, because even with zero containers, 8080 still responds with that 404 error. But then, no other port will work on qbittorrent either. All the other containers seem to be working find, it's just qbittorrent. I think the actual issue lies with either OMV7 or Debian 12

    Zitat von gderf

    It all works here on OMV 7 and Debian 12.

    Not for me it wasn't


    So, I got qbittorrent working by doing something I did not want to do. I bypassed the docker networks and assigned it its own ip on my local network. That way, whatever on the host is grabbing port 8080 won't affect it, and whatever is causing it to refuse to work on any other port won't affect it.

    • Neu

    Why don't you just change the left 8080 to say 18180?


    I also use binhex qbittorrentvpn using wireguard, but used to use openvpn with no problems.


    Can you post your compose file that you are using now? So I can compare it to mine.


    Code
    MEDIA_DIRECTORY=/srv/dev-disk-by-uuid-c3affa24-cb7a-4e6c-b37f-7f625a468ca2/Media

I would have this in my .env

MEDIA_DIRECTORY="/srv/dev-disk-by-uuid-c3affa24-cb7a-4e6c-b37f-7f625a468ca2/Media"


    And then in my compose file I use

    Code
    $MEDIA_DIRECTORY:/media

or

$MEDIA_DIRECTORY/Movies:/media/movies
    • Neu

    I've just looked at MarkusMcNugen qBittorrentvpn github page and see that it the same as other vpn containers, in that you need to the below. But I don't see that you did this in your notes in the 1st message.

    Zitat
    The container will fail to boot if VPN_ENABLED is set to yes or empty and a .ovpn is not present in the /config/openvpn directory. Drop a .ovpn file from your VPN provider into /config/openvpn and start the container again. You may need to edit the ovpn configuration file to load your VPN credentials from a file by setting auth-user-pass.
    • Neu

    Hello, I seeem to be having a similar issue as putergod, specifically what he mentiones in post #9 of this thread, that I cannot get the "vanilla" version of qBittorent docker container from linuxserver working on OMV7. The container is up as ususal, but I am only seeing "404 page not found". It was working some days ago, while still on OMV6, but I am unfortunately not sure when exactly it stopped working.


    The exact compose file I am using is


    My other containers (Syncthing and PhotoPrism) are working fine. Could anyone please suggest how can I diagnose such an issue? I am not sure what to do here and would be glad for any recommandations what I can try?


    I tried looking at the logs, but did not really see anything there:

    The backstory, which might or might not be relevant, is that I updated to OMV 7 over the weekend by running `omv-release-upgrade` (aside from the qBittorent issue, everything else works great. The goal was to try and get PhotoPrism running using the openmediavault-k8s, after the PhotoPrism OMV plugin failed to work on OMV 6. The k8s recipe did work, but I found Kubernetes to be a little overwhelming for me, I was not really sure how to modify things, even getting rid of the deployed PhotoPrism took a lot of googling. I therefore decided to try again with docker compose from PhotoPrism docs, which works just as fine, but in a much more understandable and manageable way for me.


    Just before I discovered the issue, I started to properly set-up backups of my containers according to this guide. I spun the qBittorrent container down to add the # BAKUP/SKIP_BACKUP comments to the volumes. While doing that I noticed that I was getting a warning about the version statement being obsolete in the original compose YAML I was using, so I pulled a new image, and updated the compose to the one above. When I spun the container back up, I noticed qBittorrent web interface was not accessible. Original compose file for completeness (almost the same, the issue is not fixed by going back to it):

    Another thing I am not sure is related is, that I seem to have a lot more network interfaces than I used to, but maybe I am imagining things:

    • Neu
    Zitat von JirkaValtr

    While doing that I noticed that I was getting a warning about the version statement being obsolete in the original compose YAML I was using, so I pulled a new image, and updated the compose to the one above.

    On this one, I can help by explaining what's the error:

    Newest versions on docker / docker-compose don't require the version ident on the YML, hence the "error".

    To clear it, bringo down the container on the compose GUI and edit the YML.

    Remove that line and save.

    Deploy again the container:


    Showing:

    From this:

    Code
    ---
version: "2.1"
services:
  qbittorrent:


    To this:

    Code
    ---
services:
  qbittorrent:


    On a side note, you have your config folder pointing to ./config.

    I don't know if the folder is being set with the proper permissions, namely owned by PUID:PGID that is on the YML because it lives on the compose PATH.

    Maybe chente can give better pointers.



    As for the amount of network's with veth0, it corresponds to the amount of individual services you have running: 1 per service.

    This is normal.
    As an example, I have 8 services running, so I have 8 veth0 networks:


       


    • Neu
    Zitat von olduser

    Doesn't matter, it is expanded to the the full path like $PWD.

    What I wanted to see is how the permissions are created on that specific folder on the HOST and it's full path.


    I trust by using the PATH that way that config folder will be made on :

    /<THE PATH FOR THE COMPOSE FOLDER PLUGIN>/<FILE NAME>/config


    What I don't see is WHERE is that.


    Since I only use full PATH (it's symlinked but still, full path), I can always check if the folder (and its subfolders and files under) is created with the correct permissions.


    In case of any deviation, permissions can be rectified on the spot.

    • Neu
    • Offizieller Beitrag
    Zitat von Soma

    I trust by using the PATH that way that config folder will be made on :

    /<THE PATH FOR THE COMPOSE FOLDER PLUGIN>/<FILE NAME>/config

    That's right. https://wiki.omv-extras.org/do…ker_compose#compose_files

    Zitat von Soma

    What I wanted to see is how the permissions are created on that specific folder on the HOST and it's full path.

    The permissions for that folder are created by the docker container using the user defined in the compose file.

    • Neu
    Zitat von chente

    That's right. https://wiki.omv-extras.org/do…ker_compose#compose_files

    The permissions for that folder are created by the docker container using the user defined in the compose file.

    In that case, JirkaValtr can you show the permissions on the folder?

    You need the full path used on the Compose folder and run the following:


    Replace <PATH TO COMPOSE FOLDER> with the correct PATH

    ls -al /<PATH TO COMPOSE FOLDER>/qbittorrent/config


    And, while we're at it:

    ls -al /disk_links/data2/jirka/Downloads

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden