[Support] binhex - DelugeVPN

[brent3000]

29 minutes ago, binhex said:

you can assign a fixed ip to the container BUT the custom bridge must be assigned a different network to your LAN, for example:

if your docker container has an ip of 192.168.2.1 subnet 192.168.2.0/24 and your LAN_NETWORK is defined as 192.168.1.0/24 then it will work, 

 

if your docker container has an ip of 192.168.1.1 subnet 192.168.1.0/24 and your LAN_NETWORK is defined as 192.168.1.0/24 then you will not be able to access the web ui (your current configuration).

 

Switching to the default 'bridge' works, as this resets the docker network to 172.17.0.0/16 thus preventing the LAN_NETWORK clash and allowing iptables rules to work as designed.

 

Well that explains it well on why one works and one dosnt, is that a recent change? I swear this was working before at one stage.

 

The issue I oddly then get is when i have a docker using the dlugevpn as its network for some reason in this format I cant access the other docker when its being router via the bridge version (yet what its setup like before, Deluge wont load but all the other docker containers work fine via the IP)

 

(--net=container:binhex-delugevpn)

 

Would some of the network changes impact that from working while in bridge mode?

 

Thats following the guide above i posted from Space Invader 

[binhex]

Just now, brent3000 said:

Well that explains it well on why one works and one dosnt, is that a recent change? I swear this was working before at one stage.

nope, its been that way since day1, it was indeed designed that way as macvlan, ipvlan and custom bridges and all that guff wasn't even an option (in unraid) when this image was created.

 

5 minutes ago, brent3000 said:

I cant access the other docker

i am not quite clear on this, do you mean access the web ui of the other docker container from your lan or do you mean cross communication between docker containers in the same network? e.g. sonarr talking to deluge whilst both using delugevpn network?.

[brent3000]

3 minutes ago, binhex said:

i am not quite clear on this, do you mean access the web ui of the other docker container from your lan or do you mean cross communication between docker containers in the same network? e.g. sonarr talking to deluge whilst both using delugevpn network?.

 

I have all my dockers routed via the VPN container using '--net=container:binhex-delugevpn' in the Extra Parameters of each of the other containers as below

 

I have then added the container ports to the vpn docker as below

 

 

When running in bridged mode, deluge wont load but all the other containers work a treat. When bridge mode is enabled none of the docker ports seem to load and only deluge works at this point.

[binhex]

Just now, brent3000 said:

When bridge mode is enabled none of the docker ports seem to load and only deluge works at this point.

ok so you mean by 'load' you cannot access the web ui of the other containers running in the delugevpn network right?, if so see Q25:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md 

[brent3000]

52 minutes ago, binhex said:

ok so you mean by 'load' you cannot access the web ui of the other containers running in the delugevpn network right?, if so see Q25:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md 

Ok it seems the delete port and the vpn port is new (odd how its still working on my older system with no issues hahah) 

 

But it seems they are coming online and can be accessed.

 

Willl continue to test and advise if other issues arise, thanks @binhex

[joelstitch]

I'm havinf problems getting this to work right with PIA. Some of the torrents I add I get an error on the Status saying "Permission Denied". Some torrents download fine. Same torrents that give me the error work fine on my laptop and a different binhex-delugevpn running trough NordVPN. This is what I am getting on the logs:

 

[debug] iptables chain policies are in place



2023-09-29 17:30:05,170 DEBG 'watchdog-script' stdout output:

[debug] VPN incoming port is 47095

[debug] Deluge incoming port is 47095

[debug] VPN IP is 10.37.112.206

[debug] Deluge IP is 10.37.112.206



2023-09-29 17:30:35,174 DEBG 'watchdog-script' stdout output:

[debug] Checking we can resolve name 'www.google.com' to address...



2023-09-29 17:30:35,308 DEBG 'watchdog-script' stdout output:

[debug] DNS operational, we can resolve name 'www.google.com' to address '172.253.115.105 172.253.115.103 172.253.115.104 172.253.115.147 172.253.115.99 172.253.115.106'



2023-09-29 17:30:35,309 DEBG 'watchdog-script' stdout output:

[debug] Waiting for iptables chain policies to be in place...



2023-09-29 17:30:35,331 DEBG 'watchdog-script' stdout output:

[debug] iptables chain policies are in place



2023-09-29 17:30:35,362 DEBG 'watchdog-script' stdout output:

[debug] VPN incoming port is 47095

[debug] Deluge incoming port is 47095

[debug] VPN IP is 10.37.112.206

[debug] Deluge IP is 10.37.112.206



2023-09-29 17:31:05,366 DEBG 'watchdog-script' stdout output:

[debug] Checking we can resolve name 'www.google.com' to address...



2023-09-29 17:31:35,538 DEBG 'watchdog-script' stdout output:

[debug] DNS operational, we can resolve name 'www.google.com' to address '172.253.115.105 172.253.115.103 172.253.115.104 172.253.115.147 172.253.115.99 172.253.115.106'



2023-09-29 17:31:35,540 DEBG 'watchdog-script' stdout output:

[debug] Waiting for iptables chain policies to be in place...



2023-09-29 17:31:35,559 DEBG 'watchdog-script' stdout output:

[debug] iptables chain policies are in place



2023-09-29 17:31:35,592 DEBG 'watchdog-script' stdout output:

[debug] VPN incoming port is 47095



2023-09-29 17:31:35,592 DEBG 'watchdog-script' stdout output:

[debug] Deluge incoming port is 47095

[debug] VPN IP is 10.37.112.206

[debug] Deluge IP is 10.37.112.206



2023-09-29 17:32:05,596 DEBG 'watchdog-script' stdout output:

[debug] Checking we can resolve name 'www.google.com' to address...



2023-09-29 17:32:05,735 DEBG 'watchdog-script' stdout output:

[debug] DNS operational, we can resolve name 'www.google.com' to address '172.253.115.105 172.253.115.103 172.253.115.104 172.253.115.147 172.253.115.99 172.253.115.106'



2023-09-29 17:32:05,737 DEBG 'watchdog-script' stdout output:

[debug] Waiting for iptables chain policies to be in place...



2023-09-29 17:32:05,754 DEBG 'watchdog-script' stdout output:

[debug] iptables chain policies are in place



2023-09-29 17:32:05,789 DEBG 'watchdog-script' stdout output:

[debug] VPN incoming port is 47095

[debug] Deluge incoming port is 47095

[debug] VPN IP is 10.37.112.206

[debug] Deluge IP is 10.37.112.206



2023-09-29 17:32:35,796 DEBG 'watchdog-script' stdout output:

[debug] Checking we can resolve name 'www.google.com' to address...



2023-09-29 17:32:35,943 DEBG 'watchdog-script' stdout output:

[debug] DNS operational, we can resolve name 'www.google.com' to address '142.251.36.36'



2023-09-29 17:32:35,945 DEBG 'watchdog-script' stdout output:

[debug] Waiting for iptables chain policies to be in place...



2023-09-29 17:32:35,966 DEBG 'watchdog-script' stdout output:

[debug] iptables chain policies are in place



2023-09-29 17:32:35,999 DEBG 'watchdog-script' stdout output:

[debug] VPN incoming port is 47095

[debug] Deluge incoming port is 47095

[debug] VPN IP is 10.37.112.206

[debug] Deluge IP is 10.37.112.206



2023-09-29 17:33:06,003 DEBG 'watchdog-script' stdout output:

[debug] Checking we can resolve name 'www.google.com' to address...



2023-09-29 17:33:06,178 DEBG 'watchdog-script' stdout output:

[debug] DNS operational, we can resolve name 'www.google.com' to address '142.251.36.36'



2023-09-29 17:33:06,180 DEBG 'watchdog-script' stdout output:

[debug] Waiting for iptables chain policies to be in place...



2023-09-29 17:33:06,199 DEBG 'watchdog-script' stdout output:

[debug] iptables chain policies are in place



2023-09-29 17:33:06,227 DEBG 'watchdog-script' stdout output:

[debug] VPN incoming port is 47095

[debug] Deluge incoming port is 47095

[debug] VPN IP is 10.37.112.206

[debug] Deluge IP is 10.37.112.206

 

[Ginga_Ninge]

Howdy all.
Been reading up n im also stumped on the current error when trying to open my web Ui.

ERR_CONNECTION_REFUSED

In the log i get the following error. -: WARNING: file 'credentials.conf' is group or others accessible

 

2023-09-30 03:45:09,111 DEBG 'start-script' stdout output:
2023-09-30 03:45:09 TCP/UDP: Preserving recently used remote address: [AF_INET]212.102.35.143:1198

2023-09-30 03:45:09,111 DEBG 'start-script' stdout output:
2023-09-30 03:45:09 UDPv4 link local: (not bound)
2023-09-30 03:45:09 UDPv4 link remote: [AF_INET]212.102.35.143:1198

2023-09-30 03:45:10,133 DEBG 'start-script' stdout output:
2023-09-30 03:45:10 [amsterdam416] Peer Connection Initiated with [AF_INET]212.102.35.143:1198

2023-09-30 03:45:11,418 DEBG 'start-script' stdout output:
2023-09-30 03:45:11 AUTH: Received control message: AUTH_FAILED

2023-09-30 03:45:11,418 DEBG 'start-script' stdout output:
2023-09-30 03:45:11 SIGTERM[soft,auth-failure] received, process exiting

2023-09-30 03:45:11,421 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2023-09-30 03:45:11,432 DEBG 'start-script' stdout output:
2023-09-30 03:45:11 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 

2023-09-30 03:45:11,433 DEBG 'start-script' stdout output:
2023-09-30 03:45:11 WARNING: file 'credentials.conf' is group or others accessible

2023-09-30 03:45:11,433 DEBG 'start-script' stdout output:
2023-09-30 03:45:11 OpenVPN 2.6.6 [git:makepkg/c9540130121bfc21+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Aug 15 2023
2023-09-30 03:45:11 library versions: OpenSSL 3.1.3 19 Sep 2023, LZO 2.10
2023-09-30 03:45:11 DCO version: N/A

2023-09-30 03:45:11,434 DEBG 'start-script' stdout output:
2023-09-30 03:45:11 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2023-09-30 03:45:11,436 DEBG 'start-script' stdout output:
2023-09-30 03:45:11 CRL: loaded 1 CRLs from file -----BEGIN X509 CRL-----
MIICWDCCAUAwDQYJKoZIhvcNAQENBQAwgegxCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTETMBEGA1UEBxMKTG9zQW5nZWxlczEgMB4GA1UEChMXUHJpdmF0ZSBJbnRl
cm5ldCBBY2Nlc3MxIDAeBgNVBAsTF1ByaXZhdGUgSW50ZXJuZXQgQWNjZXNzMSAw
HgYDVQQDExdQcml2YXRlIEludGVybmV0IEFjY2VzczEgMB4GA1UEKRMXUHJpdmF0
ZSBJbnRlcm5ldCBBY2Nlc3MxLzAtBgkqhkiG9w0BCQEWIHNlY3VyZUBwcml2YXRl
aW50ZXJuZXRhY2Nlc3MuY29tFw0xNjA3MDgxOTAwNDZaFw0zNjA3MDMxOTAwNDZa
MCYwEQIBARcMMTYwNzA4MTkwMDQ2MBECAQYXDDE2MDcwODE5MDA0NjANBgkqhkiG
9w0BAQ0FAAOCAQEAQZo9X97ci8EcPYu/uK2HB152OZbeZCINmYyluLDOdcSvg6B5
jI+ffKN3laDvczsG6CxmY3jNyc79XVpEYUnq4rT3FfveW1+Ralf+Vf38HdpwB8EW
B4hZlQ205+21CALLvZvR8HcPxC9KEnev1mU46wkTiov0EKc+EdRxkj5yMgv0V2Re
ze7AP+NQ9ykvDScH4eYCsmufNpIjBLhpLE2cuZZXBLcPhuRzVoU3l7A9lvzG9mjA
5YijHJGHNjlWFqyrn1CfYS6koa4TGEPngBoAziWRbDGdhEgJABHrpoaFYaL61zqy
MR6jC0K2ps9qyZAN74LEBedEfK7tBOzWMwr58A==
-----END X509 CRL-----

2023-09-30 03:45:11,437 DEBG 'start-script' stdout output:
2023-09-30 03:45:11 TCP/UDP: Preserving recently used remote address: [AF_INET]104.16.113.56:1198
2023-09-30 03:45:11 UDPv4 link local: (not bound)
2023-09-30 03:45:11 UDPv4 link remote: [AF_INET]104.16.113.56:119

 

 

Still learning how this all works so still only know simple steps.
 

please and thankyou

Edited September 30, 2023 by Ginga_Ninge

[almulder]

got my new server up and running and reinstalled, however I am unable to access GUI. Looking at the log I see this error: (Token removed from my post)

 

2023-10-02 16:49:15,300 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json payload from URL 'https://10.10.112.1:19999/getSignature' using token 

 

It tries this 10 times and then stops and never connects.  Never had an issue on old server.

[binhex]

On 9/30/2023 at 11:42 AM, Ginga_Ninge said:

2023-09-30 03:45:11 AUTH: Received control message: AUTH_FAILED

See Q16:-  https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

[sir_storealot]

Hi, I have a weird issue with the delugevpn container consuming 100 % CPU even though it's idle and not processing any network traffic. There are a 5 stuck downloads, which are not progressing, so there is just some protocol chatter going over the network. See screenshots.

 

I am using PIA VPN with external IP address port forwarding. 

 

The web GUI is responsive as normal. If I add a new torrent, it starts downloading as normal.

 

docker log file:

2023-10-06 13:12:06,327 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '23891'

2023-10-06 13:27:06,476 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '23891'

2023-10-06 13:42:06,619 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '23891'

2023-10-06 13:57:06,770 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '23891'

2023-10-06 14:12:06,921 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '23891'

 

Any clues as to whats going on, and how I can resolve this? My NAS is using +25 % more power because of the high CPU utilization. It drops immediately when I kill the container. After restart, it works normally for a couple of hours, and then hits 100 % CPU again.

 

Thanks for your help!

[PassTheSalt]

I've been having an issue  where eventually delugevpn and SAbnzbd (ran through delugevpn network)  won't respond on their webui ports. I just get connection timeouts.  Both containers still work properly. I can see Sab is still downloading and sorting things. The Sabnzbd is being routed through the delugevpn container so it's also going through a vpn so both are related. Restarting the containers and even stopping and restarting docker doesn't fix it.  The only thing that fixes it (that i've found) is to restart the entire server. If I restart the server they normally work fine for a few days before it happens again.
I'm assuming its something to do with unraid forwarding the port to the container? idk what would cause that to stop working.  Currently running 6.11.5  Any ideas?  

 

Edit: I just had the issue and restarted again and SAB connects but deluge doesn't.... hmm

supervisord.log

[Corneloues]

Port forwarding using DelugeVPN as a proxy server on Windows.

 

The proxy is working fine, and I can see that PIA is popping me out nicely in my preferred location.

 

What I'm struggling with is port forwarding from Windows, through this container and out to PIA.

 

I have the following set in the container config:

VPN_INPUT_PORTS: 8989,7878,9696,8191,52488,52489,2416
VPN_OUTPUT_PORTS: 52488,52489,2416

 

The ones in bold are the ones I am expecting to be passed through from the local machine and out to the VPN.

The others are what are there by default.

 

Here's my proxy settings:

 

 

However, the app I am using is reporting remotely that the ports are still closed.

Not sure what I've missed or am doing wrong.

 

Any help would be appreciated.

Edited October 6, 2023 by Corneloues

[Mainfrezzer]

3 hours ago, Corneloues said:

Port forwarding using DelugeVPN as a proxy server on Windows.

 

The proxy is working fine, and I can see that PIA is popping me out nicely in my preferred location.

 

What I'm struggling with is port forwarding from Windows, through this container and out to PIA.

 

I have the following set in the container config:

VPN_INPUT_PORTS: 8989,7878,9696,8191,52488,52489,2416
VPN_OUTPUT_PORTS: 52488,52489,2416

 

The ones in bold are the ones I am expecting to be passed through from the local machine and out to the VPN.

The others are what are there by default.

 

Here's my proxy settings:

 

 

However, the app I am using is reporting remotely that the ports are still closed.

Not sure what I've missed or am doing wrong.

 

Any help would be appreciated.

youre using the wrong container. Privoxy is a http proxy not a socks proxy.

[Spucoly]

I am having issues getting the Deluge WebGUI to connect after an os upgrade to ver 6.12.4. Any help would be appreciated. Log file included.

DelugeVpnLogFile.txt

[sir_storealot]

On 10/6/2023 at 2:23 PM, sir_storealot said:

Hi, I have a weird issue with the delugevpn container consuming 100 % CPU even though it's idle and not processing any network traffic. There are a 5 stuck downloads, which are not progressing, so there is just some protocol chatter going over the network. See screenshots.

 

I am using PIA VPN with external IP address port forwarding. 

 

The web GUI is responsive as normal. If I add a new torrent, it starts downloading as normal.

 

 

 

I cant seem to solve this

Any idea how to find out what deluge is doing?

[Jorgen]

2 hours ago, sir_storealot said:

I cant seem to solve this

Any idea how to find out what deluge is doing?

One thing that could lead to some of those symptoms is running out of space in the /downloads directory.
for example: I have my downloads go to a disk outside the array mounted by unassigned devices, and somehow the disk got unmourned but the mount point remained. This caused deluge to write all downloads into a temp ram area in unraid, which filled up quickly and caused issues. I never found any logs showing this problem, just stumbled upon it by chance while troubleshooting.

[sir_storealot]

10 hours ago, Jorgen said:

One thing that could lead to some of those symptoms is running out of space in the /downloads directory.
for example: I have my downloads go to a disk outside the array mounted by unassigned devices, and somehow the disk got unmourned but the mount point remained. This caused deluge to write all downloads into a temp ram area in unraid, which filled up quickly and caused issues. I never found any logs showing this problem, just stumbled upon it by chance while troubleshooting.

 

Hi, thank you for your pointer! In fact, that happened to me a month or so ago, and caused exactly the issues you described. I have resolved the situation since, and I'm still seeing the same issue, so it makes me wonder if running out of disk space maybe "broke" something, and leads to this error persisting even though disk space is not an issue anymore. Will try to investigate further in this area!

[lazydaze]

Has anyone been able to set up port forwarding in Deluge with ProtonVPN using wireguard? Deluge is running downloading fine and I've added a wireguard config with port forwarding. But it comes up unconnectable when I check on a few sites.

 

edit: upnp is active on the netowrk. How can I check what port deluge is trying to use? 

 

edit 2: drrr +pmp

Edited October 19, 2023 by lazydaze

[TheJD]

UPDATE: I managed to fix the issue. Since I mainly wanted to use the container to route other containers through the VPN, I didn't configure everything for port forwarding (no username with '+pmp', no WireGuard configuration for P2P servers, ...). Turns out, that having port forwarding enabled is required for the webserver to start. So the issue wasn't with the network but rather the webserver not starting.

 

Hey! I want to set up Deluge with ProtonVPN and have issues connecting to the WebUI.

I have already read the FAQ but couldn't find a suiting answer there, since there is no error logged anywhere.

 

Here are the only entries I changed from default when creating the container:

• Host Path 2: Set to a path within another share
• Key 4 (VPN_PROV): protonvpn
• Key 5 (VPN_CLIENT): wireguard
• Key 9 (LAN_NETWORK): 10.10.10.0/24
• Key 16 (DEBUG): true

The WireGuard configuration obtained from ProtonVPN was placed in /mnt/user/appdata/binhex-delugevpn/wireguard/wg0.conf

I was able to confirm that the VPN-connection works by using 'curl ifconfig.io' from within the container, which shows the VPN-IP-Address.

However, when connecting to the WebUI, Firefox just displays: “Unable to connect”.

 

I suspect that the issue has to do with the interaction between the iptables ruleset and my network setup, since I am able to connect to the WebUI when VPN_ENABLED is set to false (which disables a lot of the iptables rules if I understand the log correctly).

Additionally, I am unable to access any other container I route through deluge (of course with the correct ports added to VPN_INPUT_PORTS).

 

Here is the log: supervisord.log

 

My network setup:

I have two VLANs (VLAN 10: 10.10.10.0/24 and VLAN 20: 10.10.20.0/24), although all machines relevant to my problem are inside VLAN 10. The computer I am trying to access the WebUI from has the IP 10.10.10.10 and Unraid has the IP 10.10.10.18. Here is the Unraid network and docker configuration:

Edited October 22, 2023 by TheJD
Fixed the issue myself

[Corneloues]

I think I've tinkered with one too many docker settings. Is there an easy way to restore without deleting and starting over?

[binhex]

On 10/20/2023 at 10:56 AM, TheJD said:

UPDATE: I managed to fix the issue. Since I mainly wanted to use the container to route other containers through the VPN, I didn't configure everything for port forwarding (no username with '+pmp', no WireGuard configuration for P2P servers, ...). Turns out, that having port forwarding enabled is required for the webserver to start. So the issue wasn't with the network but rather the webserver not starting.

no doubt you had STRICT_PORT_FORWARD set to 'yes', this env var when set to yes forces the connection to try to acquire a incoming port, if it cannot get a incoming port it will retry until failure. In your case you don't care about port forwarding, so setting this to 'no' will allow you to connect to any vpn endpoint.

[binhex]

54 minutes ago, Corneloues said:

I think I've tinkered with one too many docker settings. Is there an easy way to restore without deleting and starting over?

You can restore if you have a backup, you have a backup right?, if not then for next time install the plugin from CA called 'Appdata Backup/Restore v2.5'. So if you don't have a backup (i kinda suspect this is the case) then your best bet is manually record what your current container settings are and then delete the container and re-create from a blank template.

[Corneloues]

11 hours ago, binhex said:

You can restore if you have a backup, you have a backup right?, if not then for next time install the plugin from CA called 'Appdata Backup/Restore v2.5'. So if you don't have a backup (i kinda suspect this is the case) then your best bet is manually record what your current container settings are and then delete the container and re-create from a blank template.

 

Still learning - big lesson here! Installing the Appdata Backup app now. Luckily it's a CA Spotlight app for this month...

 

My issue was trying to use this DelugeVPN to route other apps through and needed to setup additional ports and that's where its all gone Pete Tong!

 

I've been prepared to kill and restore. As long as connect to existing folders, I can minimise the re-work.

[Corneloues]

11 hours ago, binhex said:

You can restore if you have a backup, you have a backup right?, if not then for next time install the plugin from CA called 'Appdata Backup/Restore v2.5'. So if you don't have a backup (i kinda suspect this is the case) then your best bet is manually record what your current container settings are and then delete the container and re-create from a blank template.

 

FYI...

 

It's now called Appdata Backup - turns out I did have this one installed. Investigating...

[snowboardjoe]

Since upgrading to 2.1.1 the client is still seeding existing torrents, but I'm unable to any new ones. When I try to add a new URL I get this error in the logs:

 

Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/twisted/web/_newclient.py", line 1043, in dispatcher
    return func(*args, **kwargs)
  File "/usr/lib/python3.11/site-packages/twisted/web/_newclient.py", line 1594, in _finishResponse_WAITING
    self._giveUp(Failure(reason))
  File "/usr/lib/python3.11/site-packages/twisted/web/_newclient.py", line 1644, in _giveUp
    self._disconnectParser(reason)
  File "/usr/lib/python3.11/site-packages/twisted/web/_newclient.py", line 1633, in _disconnectParser
    parser.connectionLost(reason)
--- <exception caught here> ---
  File "/usr/lib/python3.11/site-packages/twisted/web/_newclient.py", line 555, in connectionLost
    self.response._bodyDataFinished()
  File "/usr/lib/python3.11/site-packages/twisted/web/_newclient.py", line 1043, in dispatcher
    return func(*args, **kwargs)
  File "/usr/lib/python3.11/site-packages/twisted/web/_newclient.py", line 1283, in _bodyDataFinished_CONNECTED
    self._bodyProtocol.connectionLost(reason)
  File "/usr/lib/python3.11/site-packages/twisted/web/client.py", line 1432, in connectionLost
    self.original.connectionLost(reason)
  File "/usr/lib/python3.11/site-packages/deluge/httpdownloader.py", line 73, in connectionLost
    with open(self.agent.filename, 'wb') as _file:
builtins.IsADirectoryError: [Errno 21] Is a directory: '/tmp/delugeweb-79lq129d/'

 

I do see the directory created there, but still don't understand what the problem is.

 

[root@8db4cdfa95b3 tmp]# ls -l
total 52
drwx------ 1 nobody users     0 Oct 22 20:06 delugeweb-0mcyk1et
drwx------ 1 nobody users     0 Oct 22 20:05 delugeweb-1p815gjl
drwx------ 1 nobody users     0 Oct 23 19:40 delugeweb-79lq129d
drwx------ 1 nobody users     0 Oct 23 19:39 delugeweb-lojv_rhe
drwx------ 1 nobody users     0 Oct 22 20:15 delugeweb-wa68rbic
drwx------ 1 nobody users     0 Oct 22 20:08 delugeweb-wb6i4q_0
drwx------ 1 nobody users     0 Oct 22 20:05 delugeweb-z71r_x_h
-rw-rw-rw- 1 root   root    946 Oct 22 20:08 getiptables
-rw-rw-rw- 1 root   root     15 Oct 22 20:08 getvpnextip
-rw------- 1 root   root      0 Oct 22 20:08 start-script-stderr---supervisor-s2urs698.log
-rw------- 1 root   root  22049 Oct 23 19:45 start-script-stdout---supervisor-1g8290c4.log
-rw-rw-rw- 1 root   root      1 Oct 22 20:08 vpngatewayip
-rw-rw-rw- 1 root   root      9 Oct 22 20:08 vpnip
-rw------- 1 root   root   6995 Oct 23 19:41 watchdog-script-stderr---supervisor-15emil97.log
-rw------- 1 root   root   1195 Oct 22 20:08 watchdog-script-stdout---supervisor-bmc8bdvw.log

 

Any suggestions on on what to look at next?