qbittorrentvpn ERR_EMPTY_RESPONSE

Currently reading
qbittorrentvpn ERR_EMPTY_RESPONSE

13
2
NAS
DS1019+
Operating system
  1. Windows
Hi, I have been running the qbittorrentvpn docker container successfully for some time.

The image used is the markusmcnugen version.

Recently there have been two power cuts while the container was running on a synology NAS 1019+ DSM 6.2.4-25556

After the first power cut it was no longer possible to log into the QB webui for approximately 24 hours, eventually functionality came back.

After the second power cut despite waiting several days for functionality to return the webui remained inaccessible with the following error:

"synologynasip" didn’t send any data.
ERR_EMPTY_RESPONSE.

I began the process of trying to build a fresh docker container to see if this would fix the issue, however when it came to querying the NAS for the PGID and PUID using the following command:

ssh "username"/"synologynasip" -p2299 (I have substituted the real username and ip)

I received the following error message:

ssh: Could not resolve hostname "username"/"synologynasip": No such host is known

What is strange is that the NAS is functioning perfectly fine and is accessible over the local network so it should be connectable. I am unsure why this specific issue exists and would be grateful for any help to get back to a working set up.
 
Solution
Things are starting to happen which may help diagnose the root issue.

Installing and running the container on docker version 18.09.0-0519 results in no attempt by the container to contact the VPN and no active session registered on airvpn.

Installing and running the container on docker version 18.09.0-0513 results in an attempt to establish connection with the VPN and an active session being verified by airvpn.

With the VPN enabled, when trying to access the webui the same error occurs ERR_EMPTY_RESPONSE.

It appears an error occurs because the container is successfully preventing access to qb as it performs its function as a killswitch.

Here is a copy of the final stages of the log generated with the VPN enabled on...
What went with the power cut?
Just the router or the NAS as well? I ask as I had similar responses when trying to connect to that container when the VPN had failed and couldn't come back up.
Have you tried restarting the container?
What do the logs look like for the container?
 
Upvote 0
Last edited:
@Akira Both the router and the NAS were powered off by the power cut.

I also am starting to think it is related to the VPN not being connected.

I have tried restarting the container as well as moving the webui to a different port but that didn't solve the issue.

The logs aren't showing anything significant only "start container" "stop container". Unless there is a more in depth log stored elsewhere?

@Telos The container is running with "high privilege".

@fredbert Thanks I was able to retrieve the PGID and PUID with your help, I will try building a new container and see if it solves the issue.
 
Upvote 0
Last edited:
@Telos Yes, When I start the original container that worked before the power cut the VPN registers it as an active session.

This indicates the container is in fact connecting to the VPN.

I am now receiving this error message consistantly when attempting to connect to the webui:

ERR_CONNECTION_RESET

I believe I successfully created a duplicate of the original container and attempted to connect using a different port that was specificed in the container settings, but I get the same error as above.

These are the only variables and values that have been input into the environment section of the container.

PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DEBIAN_FRONTEND noninteractive
PGID xxxx
PUID xxxx
NAME_SERVERS 8.8.8.8,8.8.4.4
LAN_NETWORK 192.168.1.0/254
VPN_ENABLED Yes

They worked fine previously and I can see no reason why a power cut should change anything but perhaps they need modifying or new variables with values need adding?

If I run the command: ssh "username"@"synologynasip" -p "webuiport"

It returns: kex_exchange_identification: Connection closed by remote host
 
Upvote 0
Have you checked the firewall on the NAS? The docker subnet may have changed and your access may be being blocked by that.
 
Upvote 0
I have managed to resolve the issue but it required even uninstalling docker from the NAS and reinstalling before rebuilding the container and VPN from scratch.

The netshoot option might have been interesting to troubleshoot and reveal the root case of the issue but in the interest of just solving the problem quickly the above steps worked for me.
 
Upvote 0
I have managed to resolve the issue but it required even uninstalling docker from the NAS and reinstalling before rebuilding the container and VPN from scratch.
Coincidentally, I recently went through this experience when I "lost" inter-container connectivity. QbittorrentVPN was one of the victims. Glad to hear you are back up.
 
Upvote 0
@Telos Unfortunately I was too optimistic, now when I run the newly built container it doesn't connect to the VPN and I cannot figure out why.

Before when running the container airvpn would detect it as an active session but running the container no longer does this.

I have used the config generator to generate the necessary files for the /config/openvpn folder but this doesn't result in a VPN connection.

Have you had to set up port forwarding on airvpn to get the container to connect to the VPN? If so how did you configure this.

Did you have to forward any ports on your router to get the container to connect to the VPN?
 
Upvote 0
I completely redid QBTvpn. Including the AirVPN certs download. I am not using portforwarding with AirVPN.

Did you try downloading without VPN? Try a popular Linux distro.

VPN_ENABLED=no

Double-check that "high privilege" is checked. I forgot to add that initially when I was re-doing the container.
 
Upvote 0
Last edited:
@Telos "high privilege" is checked.

I'm confident it would work without the vpn but doileak.com reveals the wan ip is being leaked. This combined with the fact airvpn doesn't detect an active session indicates no vpn connection is being formed. Previously when the wan ip wasn't being leaked airvpn also detected an active session.

It doesn't appear to even attempt to form the connection according to the logs.

@Rusty The error log doesn't appear to reveal much,

This is the log from the container details log when the container is started:

2021-06-03 19:03:40.865431 [info] VPN_ENABLED defined as 'Yes'stdout
19:03:402021-06-03 19:03:40.933889 [info] Adding 8.8.8.8 to resolv.confstdout
19:03:402021-06-03 19:03:40.994085 [info] Adding 8.8.4.4 to resolv.confstdout
19:03:41Adding xxxx groupstdout
19:03:41groupadd: GID 'xxxx' already existsstdout
19:03:41Adding xxxx userstdout
19:03:41useradd: user 'qbittorent' already existsstdout
19:03:412021-06-03 19:03:41.077843 [warn] UMASK not defined (via -e UMASK), defaulting to '002'stdout
19:03:412021-06-03 19:03:41.135576 [info] Starting qBittorrent daemon...stdout
19:03:41Logging to /config/qBittorrent/data/logs/qbittorrent-daemon.log.stdout
19:03:422021-06-03 19:03:42.224924 [info] qBittorrent PID: xxstdout
19:03:422021-06-03 19:03:42.243311 [info] Started qBittorrent daemon successfully...

This log is from qbittorrent.log when the container is started:

(N) 2021-06-03T19:03:41 - qBittorrent v4.3.4.1 started
(N) 2021-06-03T19:03:41 - Using config directory: /config/qBittorrent/config/
(I) 2021-06-03T19:03:41 - Trying to listen on: 0.0.0.0:10856,[::]:10856
(N) 2021-06-03T19:03:41 - Peer ID: -qB4341-
(N) 2021-06-03T19:03:41 - HTTP User-Agent is 'qBittorrent/4.3.4.1'
(I) 2021-06-03T19:03:41 - DHT support [ON]
(I) 2021-06-03T19:03:41 - Local Peer Discovery support [ON]
(I) 2021-06-03T19:03:41 - PeX support [ON]
(I) 2021-06-03T19:03:41 - Anonymous mode [OFF]
(I) 2021-06-03T19:03:41 - Encryption support [FORCED]
(I) 2021-06-03T19:03:41 - IP geolocation database loaded. Type: DBIP-Country-Lite. Build time: Tue Jun 1 00:03:56 2021.
(N) 2021-06-03T19:03:41 - Using built-in Web UI.
(N) 2021-06-03T19:03:41 - Web UI translation for selected locale (en) has been successfully loaded.
(N) 2021-06-03T19:03:41 - Web UI: Now listening on IP: *, port: 8080
(I) 2021-06-03T19:03:41 - Successfully listening on IP: 127.0.0.1, port: TCP/10856
(I) 2021-06-03T19:03:41 - Successfully listening on IP: 127.0.0.1, port: UDP/10856
(I) 2021-06-03T19:03:41 - Successfully listening on IP: 172.17.0.2, port: TCP/10856
(I) 2021-06-03T19:03:41 - Successfully listening on IP: 172.17.0.2, port: UDP/10856
-- post merged: --

@Telos do you have anything other than LAN1 connected in Network>Control Panel> Network Interface ?
 
Upvote 0
Last edited:
@Telos do you have anything other than LAN1 connected in Network>Control Panel> Network Interface ?
No. Have you disabled NAS firewall?

EDIT: FWIW when I redid Docker, I manually cleaned out @docker (after uninstalling). I dropped back a version or so when I reinstalled docker
gr68Tlj.png
 
Upvote 0
Things are starting to happen which may help diagnose the root issue.

Installing and running the container on docker version 18.09.0-0519 results in no attempt by the container to contact the VPN and no active session registered on airvpn.

Installing and running the container on docker version 18.09.0-0513 results in an attempt to establish connection with the VPN and an active session being verified by airvpn.

With the VPN enabled, when trying to access the webui the same error occurs ERR_EMPTY_RESPONSE.

It appears an error occurs because the container is successfully preventing access to qb as it performs its function as a killswitch.

Here is a copy of the final stages of the log generated with the VPN enabled on 18.09.0-0513.

ROUTE_GATEWAY 172.17.0.1/255.255.0.0 IFACE=eth0 HWADDR="redacted"
ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Exiting due to fatal error

With the VPN disabled it is possible to access the webui.
 
Upvote 0
Things are starting to happen which may help diagnose the root issue.

Installing and running the container on docker version 18.09.0-0519 results in no attempt by the container to contact the VPN and no active session registered on airvpn.

Installing and running the container on docker version 18.09.0-0513 results in an attempt to establish connection with the VPN and an active session being verified by airvpn.

With the VPN enabled, when trying to access the webui the same error occurs ERR_EMPTY_RESPONSE.

It appears an error occurs because the container is successfully preventing access to qb as it performs its function as a killswitch.

Here is a copy of the final stages of the log generated with the VPN enabled on 18.09.0-0513.

ROUTE_GATEWAY 172.17.0.1/255.255.0.0 IFACE=eth0 HWADDR="redacted"
ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Exiting due to fatal error

With the VPN disabled it is possible to access the webui.
have a look here: qBittorrent via VPN docker container running on Synology NAS

there is a section on that specific error
 
Upvote 0
Solution

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top