I found the cause of my issues, it was my VPN provider, it seems that if I let it decide or if I chose any random server in my country I experience this issue, but I have now selected the country next door, which has a much bigger pool and the throughput increased to the point it was limited by the 1GB NIC 😃 which is a great problem to have it has been running fine all day and night at speeds I have not seen in 3 years

Have you tried a different country or port with your VPN fityp? just in case they have issues that it causing it to reconnect?

Please can someone help with my query

Clevoir
from the logs I cant see anything wrong apart from you do have a real mixture of name servers, are some of them your ISP? (ISP not recommended due to they can cause issues)
'209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1'

just try with 1.1.1.1,1.0.0.1

Google is also not recommended ---as per Binhex recommendation
https://hub.docker.com/r/binhex/arch-sabnzbdvpn/

Have you tried wireguard? there is a lot less overhead and it seems simpler process

Edited October 29, 2025Oct 29 by hwextreme

Since I've done the unRAID stable 7.2.0 update I couldn't connect to this container anymore through tailscale (plugin) while it has worked flawless for months before the update.

I've read that I should add the tailscale ip address of my tailnet to the LAN_NETWORK value in the containers settings and I've tried that without luck. I also tried "100.64.0.0/10" for all tailscale IP's and that did seem to work. I did have to make a change to my sabnzbd "external access" settings though. This was set to "API without configuration" and I had to set it to "full webinterface" to get into the webinterface. Seems logical, but strange that it has always worked without these extra steps.

My guess is that when I disable Magic DNS in tailscale and add my tailnet's IP again, it'll work. But my question is; What changed in unRAID version 7.2.0 vs 7.1.14 that makes it so much harder to use tailscale with this container? I don't really want to disable Magic DNS since all my bookmarks use it.

EDIT:
After typing all this I noticed the different IP's of all tailscale devices. I've added these individual IP addresses with the addition of "/32" to the LAN_NETWORK value in the container settings and now it works again. So I guess I can use this solution and keep Magic DNS on.

Edited October 30, 2025Oct 30 by ontosan

I have been running 7.2.0 for a while with no issues. Noticed that none of my docker images were reporting there was an update available including this one which at the time was over 8 months old. Checking the binhex docker repo said there was a version released a few months ago but I couldn’t see it. Sabnzbd was also complaining it wasn’t up to date when I used it.

I updated to Unraid version 7.2.3 hoping this would resolve the Docker update, but it didn’t. Decided to take the executive decision to manually update it by changing the container setting to point at binhex/arch-sabnzbdvpn:4.5.5-1-01 repository. Clicked apply and let the container run through its scripts.

Sabnzbd launched fine I could hit the web server but whenever I tried to download anything I would get a handshake error with the news hosting server. “Errno 111] _ssl.c:1011: The handshake operation timed out”

Checking the container logs and nothing seems to be reporting an obvious issue. I didn’t change any other setting and I double checked the OpenVPN files were still in their original location.

I did change the name server settings as advised in the post above to just show 1.1.1.1,1.0.0.1 but the same result.

If I disable the VPN then everything works fine so I know it is down to that configuration but I considering it was working last night and after manually updating the docker container it isn’t then something seems to be retaining some information but I don’t know what.

I also tried an updated ovpn file downloaded directly from from my PIA profile but nothing seems to change. It is the same error.

piaovpn.rtf

If it isn’t broke… don’t fix it. Was something I should have just applied but we are where we are.

Edited January 20Jan 20 by HumanSkunk

I also tried to switch to wireguard which generates the wg0.conf is created which as per the wiki defaults to the Netherlands but it will never connect.

I have also attached the logs for that. Not sure what is going on... Will just run using the default ssl link with the Newshosting service for now until someone cleverer than me can spot something.

piawireguard.rtf

Done some more debugging into the wireguard option, I have switched the server to multiple UK based ones in the wg0.conf with no luck. I have noticed that the Interface Address at the top of the configuration is blank as well as the completed public key, I presume that these should be completed in a setup step which isnt being done. Should this happen automatically? Presumably would be completed as part of the step that fails with this warning:

[warn] Failed to download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'

When I open the link I get this:

{

"status": "ERROR",

"message": "no auth data"

}

And the process then hangs. With Sabnzbd inaccessible.

Still unable to run this with any VPN enabled. using my old Openvpn config I still cannot download any test files within sabnzbd. With the VPN disabled everything works exactly how it used to with the VPN enabled. No idea what the issue is. No change to any of the previous log files no matter what setting I modify within the containers.

I found out that my issues were down to Privoxy, I have set PRIVOXY to no and have set all containers not to use Privoxy too. Now I can download using SabNZBVPN OK and Sonarr / Radarr / Lidarr can all search too.

If I turn PIVOXY on again, Sonarr / Radarr / Lidarr can't search for files?

I spoke too soon I can search in Sonarr / Radarr and download, but speeds are terrible, I am using AirVPN and can only download at 800kbs at most?

I've tried other locations but all have the same effect'?

problem here....no big issue....but everytime I restart the docker container or the whole unraid server, the actual download restarts from the beginning. I was downloading a big file of 80 gb, and I was at already 75 gb when I had to restart my system, sabnzb started again from 0. I checked the wizard folder and all 75 gb that are already downloaded are can be found here. dont sabnzb check the wizard folder if you already downloaded some parts of the current job? why does it start from 0 everytime?

If I dont restart the docker or unraid, everything runs fine...but sometimes you have to restart ;)

thanks

Updated today to find that when it restarted the container, I'm now getting a 7za binary... NOT found! warning in the WebGUI. Tried doing a workaround to install 7zip myself by opening the terminal for the container and using pacman -S 7zip, but that returned an error failed to commit transaction (conflicting files) 7zip: /usr/bin/7za exists in the filesystem

Is there something I need to do to fix this issue?

10 minutes ago, OriginSaint said:

Updated today to find that when it restarted the container, I'm now getting a 7za binary... NOT found! warning in the WebGUI. Tried doing a workaround to install 7zip myself by opening the terminal for the container and using pacman -S 7zip, but that returned an error failed to commit transaction (conflicting files) 7zip: /usr/bin/7za exists in the filesystem

Is there something I need to do to fix this issue?

do a force update, latest image is fixed.

52 minutes ago, binhex said:

do a force update, latest image is fixed.

Not for me.
ghcr.io/binhex/arch-sabnzbdvpn

2 minutes ago, ontosan said:

Not for me.
ghcr.io/binhex/arch-sabnzbdvpn

post /config/supervisord.log please.

With the latest image I can now connect to AirVPN using OpenVPN and download at normal speeds again. Thank you!

1 hour ago, binhex said:

do a force update, latest image is fixed.

8 minutes ago, ontosan said:

Not for me.
ghcr.io/binhex/arch-sabnzbdvpn

5 minutes ago, binhex said:

post /config/supervisord.log please.

I tried forcing an update and even adding ':latest' to the end of the repo and applying, no luck, issue persisted.

supervisord.zip

47 minutes ago, OriginSaint said:

I tried forcing an update and even adding ':latest' to the end of the repo and applying, no luck, issue persisted.

57 minutes ago, ontosan said:

Not for me.
ghcr.io/binhex/arch-sabnzbdvpn

sorry missed out a change, try force pulling now (just built).

29 minutes ago, binhex said:

sorry missed out a change, try force pulling now (just built).

No error anymore! Thank you so much for your time! (not just today, in general!)

Edited May 2May 2 by ontosan

1 hour ago, binhex said:

sorry missed out a change, try force pulling now (just built).

Great work. Thanks so much for all you do!

Is anyone else having docker networking issues after updating to 7.2.5? The attached log says

[warn] Unable to identify Docker network interfaces, exiting script...

supervisord 3.log

20 hours ago, WuZiMu said:

Is anyone else having docker networking issues after updating to 7.2.5? The attached log says

[warn] Unable to identify Docker network interfaces, exiting script...

supervisord 3.log

Yes, my binhex sab container tanked since the update too.

On 5/11/2026 at 1:30 AM, WuZiMu said:

Is anyone else having docker networking issues after updating to 7.2.5? The attached log says

[warn] Unable to identify Docker network interfaces, exiting script...

supervisord 3.log

Set the network interface back to 'bridge', this is the default working network configuration.

11 hours ago, kmkoni said:

Yes, my binhex sab container tanked since the update too.

I will need to see a log to help further, please see the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md#unraid-users

Sadly, I can’t provide any logs right now, but I can confirm that after updating to Unraid 7.2.6, neither binhex-sabnzbdvpn nor binhex-qbittorrentvpn was working.

I was able to track it down though, it turned out to be a coincidence. It looks like my OpenVPN config was no longer valid. Apparently PIA no longer supports port forwarding on Swiss servers. I switched to NL instead, and everything is working as usual for me now :)

Edited May 12May 12 by citizen-17