3 hours ago, ambipro said:

@rogales i run mine from a virtual venv on the host machine, installing it in the arch base is a bit of a hassle and doesn't gain you much of any benefit

I guess you're right.

Was just happy that I made it work..

PS. Good to see you. It's been a while. 🤜🤛

Edited October 26, 2025Oct 26 by rogales

Will this container end up supporting gluetun's to be required authentication? As I see you can tell the container to use gluetun but no option to add a username,pass or api key.

Ref mentioned here - https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#authentication

16 hours ago, Sarge888 said:

Will this container end up supporting gluetun's to be required authentication? As I see you can tell the container to use gluetun but no option to add a username,pass or api key.

Ref mentioned here - https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#authentication

Funny you mention that, i creatd a issue to raise this exact issue here, and its been done so now you can :-), i shall be included authentication into the template for this image as well as gluetun.

On 11/15/2025 at 12:54 PM, binhex said:

Funny you mention that, i creatd a issue to raise this exact issue here, and its been done so now you can :-), i shall be included authentication into the template for this image as well as gluetun.

Awesome to hear, il be looking for the auth variables to add. also with the newest update the port forward api has changed/moved. It's no longer at /v1/openvpn/portforwarded but instead has been moved to /v1/portforward . The old route sends a <a href="/v1/portforward">Moved Permanently</a> response. So you're gluetun script will need to be updated. I can send a pull request if you want but it seems like a easy enough fix so i didnt.

Reference - https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#port-forwarding

Edited November 20, 2025Nov 20 by Sarge888
added reference

@binhex First, thank you for all of the hard work you put in for the Unraid community!

I'm using @ich777 's openvpn-client docker container and I am routing deluge and all of my arr apps through it. I'm using your containers for all of them. I am using ghcr.io/binhex/arch-prowlarr, binhex/arch-radarr, binhex/arch-sonarr, and ghcr.io/binhex/arch-deluge. I run two of the radarr containers; one is for 4K only.

ich777 has built a "connected containers" feature into his openvpn-client container and I'm hoping you can help me get this working correctly. This feature automatically restarts any containers using the VPN in the event that the VPN loses connection and has to restart. Here's a screenshot of the feature explained in the container template:

A few other links:

Here's a link to a post where he helped someone who is using his containers get this configured.

Here's a link to his response to me asking him for the same assistance. He mentioned that you might already have a similar feature.

Any help you can provide would be greatly appreciated! Thank you.

3 hours ago, Richamc01 said:

@binhex First, thank you for all of the hard work you put in for the Unraid community!

I'm using @ich777 's openvpn-client docker container and I am routing deluge and all of my arr apps through it. I'm using your containers for all of them. I am using ghcr.io/binhex/arch-prowlarr, binhex/arch-radarr, binhex/arch-sonarr, and ghcr.io/binhex/arch-deluge. I run two of the radarr containers; one is for 4K only.

ich777 has built a "connected containers" feature into his openvpn-client container and I'm hoping you can help me get this working correctly. This feature automatically restarts any containers using the VPN in the event that the VPN loses connection and has to restart. Here's a screenshot of the feature explained in the container template:

A few other links:

Here's a link to a post where he helped someone who is using his containers get this configured.

Here's a link to his response to me asking him for the same assistance. He mentioned that you might already have a similar feature.

Any help you can provide would be greatly appreciated! Thank you.

OK so all of my images now include baked in Docker healthchecking, this performs the following:

1. check you can connect to https over the internet

2. check you can resolve names over the internet

3. check the application process is running

So if you set deluge 'extra parameters' to include '--restart=always' and set the 'HEALTHCHECK_ACTION' value to 'kill 1' then if any of the above fails then the contianer will be restarted, this should include loss of access to the vpn, and in fact unraid itself will restart all containers routed through another container if the container is rebuilt or restarted, the only caveart to that is that it does not handle manually spun up containers outside of unraid (docker compose).

Having said all of the above, you may want to consider coming over to my solution instead :-), this involves setting up gluetun and using that to route network connectivity for all other containers, i have even included automatic port forwarding assignment for deluge which is especially useful for VPN proviers that use dynamic ports (PIA, ProtonVPN), i have also included monitorng of the port to ensure the incoming port is open, if the port is closed then gluetun vpn is bounced, if the port changes then the application is reconfigured to use the new port, all done automatically for you.

4 hours ago, binhex said:

OK so all of my images now include baked in Docker healthchecking, this performs the following:

1. check you can connect to https over the internet

2. check you can resolve names over the internet

3. check the application process is running

So if you set deluge 'extra parameters' to include '--restart=always' and set the 'HEALTHCHECK_ACTION' value to 'kill 1' then if any of the above fails then the contianer will be restarted, this should include loss of access to the vpn, and in fact unraid itself will restart all containers routed through another container if the container is rebuilt or restarted, the only caveart to that is that it does not handle manually spun up containers outside of unraid (docker compose).

Having said all of the above, you may want to consider coming over to my solution instead :-), this involves setting up gluetun and using that to route network connectivity for all other containers, i have even included automatic port forwarding assignment for deluge which is especially useful for VPN proviers that use dynamic ports (PIA, ProtonVPN), i have also included monitorng of the port to ensure the incoming port is open, if the port is closed then gluetun vpn is bounced, if the port changes then the application is reconfigured to use the new port, all done automatically for you.

This is amazing! I'll get moved over to Gluetun today. Thank you for the prompt response. If I have any issues, I'll post over in that support forum.

40 minutes ago, Richamc01 said:

If I have any issues, I'll post over in that support forum.

Right now there is no gluetun support repo, or at least not one i have created as i have simply created a unraid template that points at the official image, what i might do is a create a generic templates support thread but for now you can post here.

Still good practice to have one support thread per template even if you're not the container author (just mention it) as these "one thread for all" always become a jumbled mess.

On 12/18/2025 at 2:06 AM, binhex said:

OK so all of my images now include baked in Docker healthchecking, this performs the following:

1. check you can connect to https over the internet

2. check you can resolve names over the internet

3. check the application process is running

So if you set deluge 'extra parameters' to include '--restart=always' and set the 'HEALTHCHECK_ACTION' value to 'kill 1' then if any of the above fails then the contianer will be restarted, this should include loss of access to the vpn, and in fact unraid itself will restart all containers routed through another container if the container is rebuilt or restarted, the only caveart to that is that it does not handle manually spun up containers outside of unraid (docker compose).

Having said all of the above, you may want to consider coming over to my solution instead :-), this involves setting up gluetun and using that to route network connectivity for all other containers, i have even included automatic port forwarding assignment for deluge which is especially useful for VPN proviers that use dynamic ports (PIA, ProtonVPN), i have also included monitorng of the port to ensure the incoming port is open, if the port is closed then gluetun vpn is bounced, if the port changes then the application is reconfigured to use the new port, all done automatically for you.

Is there a guide available to set all of this up?

On 12/18/2025 at 8:20 AM, binhex said:

Right now there is no gluetun support repo, or at least not one i have created as i have simply created a unraid template that points at the official image, what i might do is a create a generic templates support thread but for now you can post here.

Hey @binhex

Just checking in, whether you ended up using my updating geoIp.dat at https://geo.el0.org and the updated Stats plugin and https://github.com/zakkarry/deluge-ltconfig/releases/tag/v2.1.0 ltConfig - which has my added high performance profile and previous official profiles. I've taken maintaining ltConfig over officially, just so you're aware.

Hello all, I was poking around and noticed this in my logs. I don't suppose that's anything that can be addressed by us "down stream" of the project maintainers?

8 hours ago, capnJiP said:

I don't suppose that's anything that can be addressed by us "down stream" of the project maintainers?

Nope, that's down to the Deluge developers to sort that out.

37 minutes ago, binhex said:

Nope, that's down to the Deluge developers to sort that out.

I mean, what exactly is the issue we would be addressing? (I'm on Deluge's team) @binhex ?

I don't check these threads super often, but I did post to you just the other day to follow up on some of the things I've been working on that we discussed a while back being integrated into your container.

Anyway, If it's just the pkg_resources warning, I am aware of and know that warning, I get it as well both in Docker containers and when running Deluge in debug and console mode. It's only a warning, and does not result in any change in Deluge's behavior. It's innocuous and just a warning you can ignore.

We will address it, of course, when we can, but given its lack of importance to the actual client/daemon, it'll probably be some time before we get to fixing this.

Edited December 27, 2025Dec 27 by ambipro

On 12/25/2025 at 6:16 AM, ambipro said:

Hey @binhex

Just checking in, whether you ended up using my updating geoIp.dat at https://geo.el0.org and the updated Stats plugin and https://github.com/zakkarry/deluge-ltconfig/releases/tag/v2.1.0 ltConfig - which has my added high performance profile and previous official profiles. I've taken maintaining ltConfig over officially, just so you're aware.

Hi ambipro, yes i believe from memory both are included in the latest image.

5 minutes ago, ambipro said:

I mean, what exactly is the issue we would be addressing? (I'm on Deluge's team)

Well i would assume you would need to remove pkg_resources from your source code or pin the version of pkg_resources in your next release (as stated in the warning), nothing i can do here and as you say it's a warning not an error so I'm not concerned, but users do see it an for whatever reason seem concerned over it (it's been mentioned multiple times).

Yep, those are our thoughts on it as well... I've seen it in both your and LinuxServer's containers, as well as in my own container builds, and when I run it in my IDE from source or an install, the warning appears. So it's not exclusive to any particular container/set/etc. It's even present in the standard Windows install, but you'd have to run the debug console executable rather than the normal deluge.exe.

5 minutes ago, binhex said:

Hi ambipro, yes i believe from memory both are included in the latest image.

That's awesome, you've included the Stats and ltConfig (from my repo) in your image? How did you tackle the GeoIP.dat updates? My link has the .dat and .gz versions, and updates every 3rd day from MaxMind directly.

Anyway, there are several PRs that, while they aren't a simple bugfix for this warning, should result in the error being handled. The issue is that aside from me, the Deluge dev team is mostly just Cas. He's not able to devote much time to not only development (he's the only one with write access to the repo) but also to spending time online generally.

27 minutes ago, ambipro said:

The issue is that aside from me, the Deluge dev team is mostly just Cas. He's not able to devote much time to not only development (he's the only one with write access to the repo) but also to spending time online generally.

I totally get that, no pressure from me on this, my only concern is that only one person has keys to the castle, perhaps promoting a trusted person just in case Cas gets run over by a bus might be wise :-)

27 minutes ago, ambipro said:

How did you tackle the GeoIP.dat updates? My link has the .dat and .gz versions, and updates every 3rd day from MaxMind directly.

A simple function, it doesn't auto update in the background, it's only on start that it updates for now but i think it will suffce.

Yep, I think I linked you to one of my forks of LSIO or your container, where I have the script check on startup if it's been over a week since the last GeoIP.dat update - and then snatches the updated version if it has.

As far as the keys to the repo, i've had this conversation with Cas and a few other contributors (who unfortunately now have taken a backseat) - it's basically just hard and Cas has personal issues preventing him from reviewing PRs currently....I'd say as far as active devs/support team goes, I'm the most active by far, but I don't have the experience or knowledge to field PRs and handle the entire dev cycle.

There was work on converting .egg files for plugins to wheels, but there was a lot of drama in the thread (still on GH, if anyone's interested in reading), with the guy trying to make demands and not following the etiquette and procedures used in our repo.

2 hours ago, ambipro said:

I mean, what exactly is the issue we would be addressing? (I'm on Deluge's team) @binhex ?

I don't check these threads super often, but I did post to you just the other day to follow up on some of the things I've been working on that we discussed a while back being integrated into your container.

Anyway, If it's just the pkg_resources warning, I am aware of and know that warning, I get it as well both in Docker containers and when running Deluge in debug and console mode. It's only a warning, and does not result in any change in Deluge's behavior. It's innocuous and just a warning you can ignore.

We will address it, of course, when we can, but given its lack of importance to the actual client/daemon, it'll probably be some time before we get to fixing this.

Cool, as long as it's not a big deal and not something I need to do something about; I'm happy.