docker.io / ghcr.io
qBittorrent / Flood
What is this?
A docker image with qBittorrent and the Flood UI, also optional WireGuard VPN support.
A recent qBittorrent update (v4.4.4) has broken the Flood UI, you'll see a message that no connection could be established.
Starting the container¶
docker run --rm \ --name qflood \ -p 8080:8080 \ -p 3000:3000 \ -e PUID=1000 \ -e PGID=1000 \ -e UMASK=002 \ -e TZ="Etc/UTC" \ -e FLOOD_AUTH="false" \ -v /<host_folder_config>:/config \ cr.hotio.dev/hotio/qflood
version: "3.7" services: qflood: container_name: qflood image: cr.hotio.dev/hotio/qflood ports: - "8080:8080" - "3000:3000" environment: - PUID=1000 - PGID=1000 - UMASK=002 - TZ=Etc/UTC - FLOOD_AUTH=false volumes: - /<host_folder_config>:/config
docker run --rm \ --name qflood \ -p 8080:8080 \ -p 3000:3000 \ -p 8118:8118 \ -e PUID=1000 \ -e PGID=1000 \ -e UMASK=002 \ -e TZ="Etc/UTC" \ -e VPN_ENABLED="true" \ -e VPN_LAN_NETWORK="" \ -e VPN_CONF="wg0" \ -e VPN_ADDITIONAL_PORTS="" \ -e PRIVOXY_ENABLED="false" \ -e FLOOD_AUTH="false" \ -v /<host_folder_config>:/config \ --cap-add=NET_ADMIN \ --sysctl="net.ipv4.conf.all.src_valid_mark=1" \ --sysctl="net.ipv6.conf.all.disable_ipv6=0" \ cr.hotio.dev/hotio/qflood
version: "3.7" services: qflood: container_name: qflood image: cr.hotio.dev/hotio/qflood ports: - "8080:8080" - "3000:3000" - "8118:8118" environment: - PUID=1000 - PGID=1000 - UMASK=002 - TZ=Etc/UTC - VPN_ENABLED=true - VPN_LAN_NETWORK - VPN_CONF=wg0 - VPN_ADDITIONAL_PORTS - PRIVOXY_ENABLED=false - FLOOD_AUTH=false volumes: - /<host_folder_config>:/config cap_add: - NET_ADMIN sysctls: - net.ipv4.conf.all.src_valid_mark=1 - net.ipv6.conf.all.disable_ipv6=0
In most cases you'll need to add additional volumes, depending on your own personal preference, to get access to your files.
The default qBittorrent username is
admin and the default password is
adminadmin. If this doesn't work you're probably running Unraid and you'll most likely have to change the internal port on which the WebUI runs to match the external port.
|Tag||Description||Version||Commit SHA||Commit Message||Last Updated||Age|
The above table reflects the current state of the Git repository. The docker repository is mainly in sync, unless builds fail or commits are pushed for which no builds are started (usually indicated with
[skip ci] in the commit message). You can click on the tag's name to go to its corresponding branch on GitHub, clicking the commit sha brings you to the git diff of that commit.
Changing the WebUI port¶
Under certain circumstances it's required to run the WebUI on a different internal port, you can do that by modifying the environment variable
WEBUI_PORTS accordingly. It should be in the format
xxxx/tcp,xxxx/udp, take a look at the default with
docker logs (variable is printed at container start) or
WireGuard VPN support¶
There needs to be a file
wg0.conf located in
/config/wireguard and you need to set the variable
true for the VPN to start.
The part with
net.ipv6.conf.all.disable_ipv6=0 is optional or you can set it to
1 if there is no need for ipv6 and you want to disable ipv6, no attempt will be made in that case to set ip6tables rules and can prevent an error if the module
ip6table_filter isn't loaded on the host. The WireGuard configuration should not have any ipv6 related stuff when ipv6 is disabled, otherwise creating the interface will fail. If your vpn provider supports ipv6 and you keep it enabled, you'll have full ipv6 connectivity over the vpn connection (confirmed with Mullvad). If for any reason there's a failure trying to setup ip6tables rules, you'll probably need to do
sudo modprobe ip6table_filter on the host, this will mostly happen on systems that have ipv6 completely disabled.
The environment variable
VPN_LAN_NETWORK can be set to for example
192.168.1.33, so you can get access to the webui or other additional ports (see below).
If you need to expose additional ports you can use
VPN_ADDITIONAL_PORTS, for example
VPN_ADDITIONAL_PORTS=7878/tcp,9117/tcp. Every port in this list will be blocked on the vpn interface, so that there's no risk that they might be exposed to the world via the vpn (mostly there in case your vpn provider screws up and piece of mind). Why would you need this? Wanting to route traffic from other containers over the vpn is probably the most used scenario.
This is an example of how your
wg0.conf should look like. In case you have no need for ipv6 connectivity, make sure that you've got it disabled with
net.ipv6.conf.all.disable_ipv6=1 and your
wg0.conf does not contain any ipv6 stuff. Also make sure you remove any
PreUp, PostUp, PreDown, PostDown stuff that your provider might have added (unless you know what it does). When using Mullvad, this means that you shouldn't enable the Kill Switch option.
[Interface] PrivateKey = supersecretprivatekey Address = xx.xx.xxx.xxx/32 DNS = 188.8.131.52 [Peer] PublicKey = publickey AllowedIPs = 0.0.0.0/0 Endpoint = xxx.x.xxx.x:51820
This image includes
wireguard-go, the Go implementation of WireGuard which runs in userspace. Systems like Synology, Qnap or others with missing kernel modules can make use of this to establish a WireGuard VPN connection. It requires the following two changes.
A change to your
wg0.conf, due to a long lasting bug in WireGuard on these systems. You'll need to change the
AllowedIPs line to have WireGuard start up properly. Also an extra
PostUp might have to be added, play with them to see what works best for your particular system.
[Interface] ... PostUp = wg set wg0 fwmark 51820 && ip -4 rule add not fwmark 51820 table 51820 && ip -4 rule add table main suppress_prefixlength 0 && iptables-restore -n ... ... [Peer] ... AllowedIPs = 0.0.0.0/1,184.108.40.206/1 ...
Next, you'll also need to add a device mapping.
devices: - /dev/net/tun:/dev/net/tun