OMV6 With qbittorrent and wireguard?

  • Nor I. Honestly did not even realize it was an option until this more recent responses on this thread.

    I knew it was an option, just never saw a need for it if I am only accessing it from my lan, and I wouldn’t want it exposed to the internet, so to me there is absolutely no need.

  • 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.

    --
    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.

  • 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.

  • 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!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB 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!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB 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!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB 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!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB 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!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB 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!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB 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!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB 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.

Participate now!

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