Opening qbittorrent WebUI via Dashboard app is unauthorized, mismatched ip's

LSIO Discussion Container Support
1

So I am running qbittorrent and fenrus for my dashboard. adding qbittorrent to my dashboard and clicking it yields a webpage simply stating “unauthorized”. clicking the web address, and hitting enter will then open the WebUI as normal.

When checking the logs for qbittorrent I have this

(W) 2023-03-18T01:51:07 - WebUI: Referer header & Target origin mismatch! Source IP: '::ffff:192.168.86.157'. Referer header: 'http://192.168.86.27:8111/'. Target origin: '192.168.86.27:8080'

for everytime I try to open the link from the dashboard.

Seems like its getting ipv6 from somewhere? ip 157 is my desktop, 27:8111 is Fenrus, and 27:8080 is qbittorrent.

I tried editing qbittorrent.conf

WebUI\HostHeaderValidation=true

to

WebUI\HostHeaderValidation=false

to no avail. anyway i can clear this up? My containers are running on a synology for now, and i am accessing via windows, but intend to switch to linux as soon as I have all my containers setup properly on the synology.

2

If you’re changing the qbittorrent port, you need to read our documentation on how that works, specifically the WEB_UI port variable. Qbit has CSRF protection which is easy to trigger.

3

I am not changing the port, atleast I don’t think I am, sorry I am still new to docker. But I set up qbittorrent on “host” and fenrus on “bridge”. qbittorrent is still using port 8080. I tried running Fenrus on host to no avail, I think it needs to be on bridge? and pretty sure qbittorrent has to be on host?

4

Nope none of our containers -need- to be host. Post your docker-compose or screenshots of how you deployed the container on your Syno.

5

hmm ok. First time making using docker autocompose, so lets see if i got this right.

QBittorrent (I know my download directory is fucked yielding errors, I am working on fixing that now, I think its a permissions issue somehow someway).

version: "3.6"
services:
  QBitTorrent:
    cap_drop:
      - "AUDIT_CONTROL"
      - "BLOCK_SUSPEND"
      - "DAC_READ_SEARCH"
      - "IPC_LOCK"
      - "IPC_OWNER"
      - "LEASE"
      - "LINUX_IMMUTABLE"
      - "MAC_ADMIN"
      - "MAC_OVERRIDE"
      - "NET_ADMIN"
      - "NET_BROADCAST"
      - "SYSLOG"
      - "SYS_ADMIN"
      - "SYS_BOOT"
      - "SYS_MODULE"
      - "SYS_NICE"
      - "SYS_PACCT"
      - "SYS_PTRACE"
      - "SYS_RAWIO"
      - "SYS_RESOURCE"
      - "SYS_TIME"
      - "SYS_TTY_CONFIG"
      - "WAKE_ALARM"
    container_name: "QBitTorrent"
    entrypoint:
      - "/init"
    environment:
      - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      - "PS1=$(whoami)@$(hostname):$(pwd)\\$ "
      - "HOME=/config"
      - "TERM=xterm"
      - "S6_CMD_WAIT_FOR_SERVICES_MAXTIME=0"
      - "S6_VERBOSITY=1"
      - "S6_STAGE2_HOOK=/docker-mods"
      - "LSIO_FIRST_PARTY=true"
      - "XDG_CONFIG_HOME=/config"
      - "XDG_DATA_HOME=/config"
      - "PUID=1026"
      - "PGID=100"
    hostname: "QBitTorrent"
    image: "linuxserver/qbittorrent:latest"
    ipc: "private"
    labels:
      build_version: "Linuxserver.io version:- 4.5.2-r0-ls251 Build-date:- 2023-03-12T22:48:28-05:00"
      maintainer: "thespad"
      org.opencontainers.image.authors: "linuxserver.io"
      org.opencontainers.image.created: "2023-03-12T22:48:28-05:00"
      org.opencontainers.image.description: "The [Qbittorrent](https://www.qbittorrent.org/)\
        \ project aims to provide an open-source software alternative to µTorrent.\
        \ qBittorrent is based on the Qt toolkit and libtorrent-rasterbar library."
      org.opencontainers.image.documentation: "https://docs.linuxserver.io/images/docker-qbittorrent"
      org.opencontainers.image.licenses: "GPL-3.0-only"
      org.opencontainers.image.ref.name: "d9ad5913456c2fe977381ac73a1db3a1ba13cff2"
      org.opencontainers.image.revision: "d9ad5913456c2fe977381ac73a1db3a1ba13cff2"
      org.opencontainers.image.source: "https://github.com/linuxserver/docker-qbittorrent"
      org.opencontainers.image.title: "Qbittorrent"
      org.opencontainers.image.url: "https://github.com/linuxserver/docker-qbittorrent/packages"
      org.opencontainers.image.vendor: "linuxserver.io"
      org.opencontainers.image.version: "4.5.2-r0-ls251"
    logging:
      driver: "db"
      options: {}
    network_mode: "host"
    restart: "always"
    stdin_open: true
    tty: true
    volumes:
      - "/volume1/docker/QBittorrent/config:/config"
      - "/volume1/Primary/data/torrents:/data/torrents"
    working_dir: "/"

Here is my primary Fenrus, using bridge network (functional)

version: "3.6"
services:
  Fenrus:
    command:
      - "node"
      - "app.js"
    container_name: "Fenrus"
    environment:
      - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    hostname: "Fenrus"
    image: "revenz/fenrus:latest"
    ipc: "private"
    logging:
      driver: "db"
      options: {}
    mac_address: "removed"
    network_mode: "bridge"
    ports:
      - "8111:3000/tcp"
    restart: "always"
    stdin_open: true
    tty: true
    volumes:
      - "/volume1/docker/Fenrus:/config"
    working_dir: "/app"

Fenrus2.0 using host network, not functional. no logs either.


version: "3.6"
services:
  Fenrus2.0:
    cap_drop:
      - "AUDIT_CONTROL"
      - "BLOCK_SUSPEND"
      - "DAC_READ_SEARCH"
      - "IPC_LOCK"
      - "IPC_OWNER"
      - "LEASE"
      - "LINUX_IMMUTABLE"
      - "MAC_ADMIN"
      - "MAC_OVERRIDE"
      - "NET_ADMIN"
      - "NET_BROADCAST"
      - "SYSLOG"
      - "SYS_ADMIN"
      - "SYS_BOOT"
      - "SYS_MODULE"
      - "SYS_NICE"
      - "SYS_PACCT"
      - "SYS_PTRACE"
      - "SYS_RAWIO"
      - "SYS_RESOURCE"
      - "SYS_TIME"
      - "SYS_TTY_CONFIG"
      - "WAKE_ALARM"
    command:
      - "node"
      - "app.js"
    container_name: "Fenrus2.0"
    environment:
      - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    hostname: "Fenrus"
    image: "revenz/fenrus:latest"
    ipc: "private"
    logging:
      driver: "db"
      options: {}
    network_mode: "host"
    ports:
      - "8111:3000/tcp"
    restart: "always"
    stdin_open: true
    tty: true
    volumes:
      - "/volume1/docker/Fenrus:/config"
    working_dir: "/app"

edit: I setup a openVPN network on Synology, and directed qbittorrents “network interface” to the open VPN, and it appears to be working, sending all torrent data through the VPN, I am trying to retain this function, unless there is a easy/better way, but this seems to be pretty efficient. idk if moving to bridge would break this feature?

edit2: moving qbittorrent to bridge network yielded the same exact result, except I lose direct access to the openvpn via network interface, thus requiring either a new/altered method of accessing VPN for torrent data. Bridge qbittorrent was just a duplicate of the host qbittorrent.

here is the error in the log when running via bridge.

(W) 2023-03-18T18:28:25 - WebUI: Referer header & Target origin mismatch! Source IP: '::ffff:172.17.0.1'. Referer header: 'http://192.168.86.27:8111/'. Target origin: '192.168.86.27:8080'
6

We won’t assist you with putting a container (or anything) through a vpn. Remove the vpn from the picture and get everything working, which we will assist with. Once you have it working, introduce your vpn and get that working, we won’t help with this.

7

So I found the solution. its 2 fold.

First. Go to your qbittorrent.conf file, this is located in /config/qbittorrent/ location. Change the following from

WebUI\HostHeaderValidation=true

to

WebUI\HostHeaderValidation=false

this will allow you to bypass unauthorized issue that might happen in general, not through a home dash board application.

the 2nd fix is to solve the issue of ‘unauthorized’ when opening through a dashboard app, such as homarr, heimdall, & fenrus. Line 59, change from true to false

WebUI\CSRFProtection=true

WebUI\CSRFProtection=false

I’ve seen reports on various posts/forums scattered across the interwebs that the error can be reproduced with a reverse proxy as well. can’t confirm myself… but regardless, when editing this file, i’d first stop the container, edit the file, then restart the container.

2 Likes
8

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.