OMV6 docker

  • HTTPS seems to be required if you want to register the client to use magnet links. Click on the Tools menu.


    I can't answer any questions about this though.

    I just copy and paste magnet links when I need to.


    Since qbittorrent is not actually running on the same system as my browser, there is no local client to register in the browser, so I never even thought to pursue it.

    Asrock B450M, AMD 5600G, 64GB RAM, 6 x 4TB RAID 5 array, 2 x 10TB RAID 1 array, 100GB SSD for OS, 1TB SSD for docker and VMs, 1TB external SSD for fsarchiver OS and docker data daily backups

  • I just copy and paste magnet links when I need to.


    Since qbittorrent is not actually running on the same system as my browser, there is no local client to register in the browser, so I never even thought to pursue it.

    I don't copy and paste magnet links. The Remote Torrent Adder browser extension allows me to "send" them to Qbt running on the server and/or the foreign seedbox I use.

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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • Did OMV 7 add a firewall? omv.local:9090 is timing out to the NAS.


    Admittedly, I haven't tested with OMV 7 before, I've been using OMV 6 for a while at work for testing. The container is up and running correctly on the NAS, I just can't connect to the webui, the connection times out.


    I haven't changed this script in a long time and it works on the host machine's Docker using localhost:9090, but it times out connecting to the NAS with omv.local:9090 (also using the ip 192.168...)


    What am I overlooking?


    EDIT: Nevermind, it is definitely something to do with this qbittorrentvpn container. linuxserver's works fine and so does gluetun and so does gluetun+qbittorrent.

    Edited 3 times, last by olduser ().

  • It's container issue. The file "iptables.sh" effectively hardwires port 8080 for the WebUI, so QBT_WEBUI_PORT isn't observed.

  • It's container issue. The file "iptables.sh" effectively hardwires port 8080 for the WebUI, so QBT_WEBUI_PORT isn't observed.


    What image are you using here?

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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • Your image or any image with that exact "iptables.sh" file. Here's yours: https://github.com/gderf/docke…ittorrent/iptables.sh#L85 Every rule with a port uses 8080...


    Sample:


    Code
    # accept input to qBittorrent webui port
    iptables -A INPUT -i "${docker_interface}" -p tcp --dport 8080 -j ACCEPT
    iptables -A INPUT -i "${docker_interface}" -p tcp --sport 8080 -j ACCEPT

    Well, I am running on 7070 but don't use a QBT_WEBUI_PORT= statement. Is that even supported?


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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • Is that even supported?

    Yeh, it's one of the few... https://github.com/qbittorrent/docker-qbittorrent-nox


    Sadly, there isn't one for the torrent port :-/.


    These are the few I see listed:


    EDIT: actually this isn't the official doc :-/, sorry just noticed. It does work however.

    Code
      QBT_EULA=<put_accept_here> \
      QBT_VERSION=latest \
      QBT_WEBUI_PORT=8080 \
      QBT_CONFIG_PATH="<your_path>/config" \
      QBT_DOWNLOADS_PATH="<your_path>/downloads"
  • But QBT_WEBUI_PORT isn't listed as an available option or environment variable in Dyonr's image.

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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • isn't listed as an available option ... in Dyonr's image.

    I don't know how to convince you of this but... Dyonr .... didn't .... care!!! Please believe me on this. I don't blame him either, I really don't, not when you can use compose with Gluetun and qBittorrent and be done with it. I only started modifying it to add a conf switcher, I should have stopped there :-/.


    Actually I'm wrong again, QBT_TORRENTING_PORT=xxxx is apparently supported. Here's the --help print for qbittorrent-nox:


  • I don't know how to convince you of this but... Dyonr .... didn't .... care!!! Please believe me on this. I don't blame him either, I really don't, not when you can use compose with Gluetun and qBittorrent and be done with it. I only started modifying it to add a conf switcher, I should have stopped there :-/.


    Actually I'm wrong again, QBT_TORRENTING_PORT=xxxx is apparently supported. Here's the --help print for qbittorrent-nox:

    qbittorrent-nox is not dyonr/qbittorrentvpn.

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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • Login into your running container, run: ps -e.

    I didn't say anything about the binary. I said that the images are not the same, and that's where big differences in options can come in.

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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • QBT_WEBUI_PORT= statement. Is that even supported?

    QBT_WEBUI_PORT isn't listed as an available option

    qbittorrent-nox is not dyonr/qbittorrentvpn.

    I didn't say anything about the binary

    QBT_WEBUI_PORT is supported and so is QBT_TORRENTING_PORT and other variables. The scripts in this "qbittorrentvpn" container do not use any variables that start with "QBT_", so you can add those to your compose/run script.


    The SSL option isn't needed to send magnets/files. The SSL option kind of promotes bad usage and since nobody seems to use it, I'm going to remove it from my next image (after qBittorrent v5.0 is final).


    I've posted this script before for magnets and *.torrent files. If you set "Bypass authentication for clients in whitelisted IP subnets" to 192.168.1.0/24 (or whatever) you won't need the username and password. If you're using a browser in Ubuntu's Snap or similar, it won't work since curl is not package with it, you'll have to RTFM on how to get curl working.


  • QBT_WEBUI_PORT is supported and so is QBT_TORRENTING_PORT and other variables. The scripts in this "qbittorrentvpn" container do not use any variables that start with "QBT_", so you can add those to your compose/run script.

    What is the purpose of these two variables? What does using them offer? What is the penalty for not using them?

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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • What does using them offer?

    As usual, conflicting ports. If you put all of your downloaders on 1 docker network you might have a problem using port 8080 with qBittorrent if you're also using Sabnzbd's default of 8080 with this image https://docs.linuxserver.io/images/docker-sabnzbd/


    linuxserver.io also mentions potential CSRF if all the ports don't match but, I don't understand how that would be a factor unless you run it internet facing.

  • My instance runs the WebUI on port 7070 and I have no variables that specify that. All I have is this port statement.


    Code
    ports:
          - 7070:8080/tcp

    So, again I ask what does QBT_WEBUI_PORT do that isn't already happening by not using it?

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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • QBT_WEBUI_PORT is the internal port used by the Docker network, _NOT_ the host machine, which is 7070 in your example. 7070 is irrelevant here, the focus is 8080. You don't want 2 containers listening on the same port.

  • QBT_WEBUI_PORT is the internal port used by the Docker network, _NOT_ the host machine, which is 7070 in your example. 7070 is irrelevant here, the focus is 8080. You don't want 2 containers listening on the same port.

    If the container is on a docker network, the internal port is irrelevant. It’s the mapped host port that matters, as that is where the containers and/or host can overlap.


    I have several containers that have the same internal port, and they are even on the same docker network, but the mapped host port is different or else the containers will not even start, let alone try to listen on the same port.

    Asrock B450M, AMD 5600G, 64GB RAM, 6 x 4TB RAID 5 array, 2 x 10TB RAID 1 array, 100GB SSD for OS, 1TB SSD for docker and VMs, 1TB external SSD for fsarchiver OS and docker data daily backups

  • I don't use compose but I know it has some great convenience features, but I'm not sure if it's magic runs deep enough to fix this. Remember, both web UI ports are on 8080.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!