OMV6 With qbittorrent and wireguard?

    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!


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

    Quote from olduser

    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.

    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.

    Quote from olduser

    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.

    That may be, but the container internals are isolated from each other. It doesn't matter if they are started by compose or run, the internal isolation is the same. Having the port definition in the containers keeps them from overlapping on the host "listening" ports.


    You can convert between the two with something composerize and decomposerize, or just rewrite them yourself.

    Composerize

    Decomposerize


    The only time that it would matter is if you are rebuilding a container from scratch to hold more than the one application. Then the applications are not isolated from each other.

    Quote from olduser

    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.

    I think you may be wrong here. The QBT_WEBUI_PORT is the port used by the web server used in the container and is exposed to the docker network. It is not used by the docker network. That is a very important distinction.


    Each container on the docker network gets a docker network ip address as if it was a computer on a normal network, and just like a normal network you can have the same port in use by multiple containers (or computers on a network).


    The ip address or host name determines where the traffic gets sent to (or docker container name with docker).


    The port mapping and network bridge mode in compose and/or run, act sort of like like a router, allowing you to bridge networks (docker network to host in this case). Just like a router there is a single ip address that the traffic has to funnel through (the host) and just like a router (without a reverse proxy in line which would change the route based hostname allowing the ports to be kept in the private side of the route), the ports have to be exposed on the "public side" (the host) so ports need to be remapped so that they don't overlap.

    I've created 1 final image before qBittorent v5.0 (final).

    GitHub - coldsilk/docker-qbittorrentvpn: Docker container which runs a qBittorent-nox client with an optional WireGuard or OpenVPN connection
    Docker container which runs a qBittorent-nox client with an optional WireGuard or OpenVPN connection - coldsilk/docker-qbittorrentvpn
    github.com

    Pull with docker pull ... coldsilk/docker-qbittorrent:latest


    Very, VERY notably is the ability to use qBittorrent's API to issue a shutdown via ip:port/api/v2/app/shutdown I learned a bit about private trackers as well because without that shutdown command, there's seemingly no way to shutdown qbittorrent-nox cleanly. It's _SUPPOSED_ to shutdown cleanly on SIGABRT, but it most certainly doesn't. Without a clean shutdown, apparently private trackers can't collect usage, which is seemingly a big deal in the private tracker world. Also without it you loose a little download data :-/


    I've posted some of the changes before, but here is all of them in totality (I think).


    • Option of a VPN conf switcher incase you have a free/unstable VPN
    • Shutdown of qBittorrent with cURL to save downloaded torrent data. This is also apparently important for trackers that you want to collect your usage such as quota based private trackers
    • Option to set the "Network Interface:" inside qBittorrent to the VPN adapter, ie. wg0 or tun0 or tap0
    • Option to use OpenVPN without having a "credentials.conf" file
    • Option to change qBittorrent's Web UI port and Torrenting port
    • Health check can now go N ping failures to N servers before restarting
    • Default username and password is back to admin/adminadmin
    • Option to auto-strip ipv6 addresses in wg0.conf
    • Option to write a file to /config while the internet is seemingly down
    • Option to run a script when the health check succeeds and/or fails
    • Added a simple .bash script to send .torrents and magnets (it's copied to /config)
    • Added a reaper to restart the container if not connected by N seconds (default: 30).
    • Option to move the VPN config files into the container
    • Option to pass VPN options to OpenVPN
    • Option to set timezone
    Quote from Soma

    New Release from linuxserver/qbittorrent (don't know if it comes from upstream qbittorrent) now creates a random Password that is mentioned in the log:

    Code
    The web UI is at `<your-ip>:8080` and a temporary password for the `admin` user will be printed to the container log on startup.

You must then change username/password in the web UI section of settings. If you do not change the password a new one will be generated every time the container starts.

    nothing is showing in my log jsut started over from new and there is nothing in the log about a password.


    Quote from BlueCoffee

    nothing is showing in my log jsut started over from new and there is nothing in the log about a password.

    Which image are you using?

    This is showing VPN so, not the "normal" version.

    If it's gderf image, I don't think he based it on the linuxserver one.

    The log is in the qBittorrent directory, not the dicker log. If you don't see it there try:


    admin

    adminadmin

    Quote from Soma

    Which image are you using?

    This is showing VPN so, not the "normal" version.

    If it's gderf image, I don't think he based it on the linuxserver one.

    gderf image.



    Quote from olduser

    The log is in the qBittorrent directory, not the dicker log. If you don't see it there try:


    admin

    adminadmin

    Nope its not default anymore.

    P.S your photo is disgusting why do you have someone licking shit?

    Quote from BlueCoffee

    its a new setup ive not changed it at all.

    Like gderf pointed, you should follow the instructions there to reset the WebGUI password for that specific image:
    Web UI password locked on qBittorrent NO X (qbittorrent nox) · qbittorrent/qBittorrent Wiki (github.com)


    It's well instructed there.

    Quote from Soma

    Like gderf pointed, you should follow the instructions there to reset the WebGUI password for that specific image:
    Web UI password locked on qBittorrent NO X (qbittorrent nox) · qbittorrent/qBittorrent Wiki (github.com)


    It's well instructed there.

    still does not work


    I just had to change my $3/month vpn provider that I have been using for about 10 years (frootvpn) to another one as the old one seems to have disappeared 2 days ago.


    While setting up the new $3/month provider (purevpn) in the qbittorrent-vpn container I figured it might be prudent to check the vpn speed, ip address and check for DNS leaks, just to be 100% comfortable.


    So I bashed into the container and ran a speedtest and a curl ifconfig.co to confirm the ip address, and grabbed this to check for DNS leaks. While easy to install and run, it might be a good script to include in the image build.

    GitHub - macvk/dnsleaktest: An open source script tests VPN connection for DNS Leak.
    An open source script tests VPN connection for DNS Leak. - macvk/dnsleaktest
    github.com

    I am no longer maintaining my gderf/qbittorrentvpn image because one of the tools used in building the image is broken.


    I have switched to this image instead, but I do not build it myself, I just take what the author offers.


    GitHub - Trigus42/alpine-qbittorrentvpn: Multiarch docker image with the latest qBittorrent-nox client (WEB UI) and WireGuard/OpenVPN tunnel
    Multiarch docker image with the latest qBittorrent-nox client (WEB UI) and WireGuard/OpenVPN tunnel - Trigus42/alpine-qbittorrentvpn
    github.com



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

    That's too bad. That dyonr one that you took over and modified was tried and true.


    Now i might have to get nervous for a little while again. ;)

Participate now!

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

Register Yourself Login