March 22, 20251 yr 16 hours ago, binhex said: ok becaue you have both containers in the same network changing the host port will do nothing, the way out of this is to change the port that qbittorrent is using, not sabnzbd, as qbittorrent has the ability to change the container port and thus prevent the clash, to change the port see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/qbittorrentvpn.md Well, don't I feel dumb. I looked to see if qbittorrent had a way to change the port but failed to turn on the advanced view. Anyway, this worked perfectly. Thanks!!
April 4, 20251 yr On 8/22/2023 at 12:42 PM, optiman said: After updating the script and installing the latest version of your docker, the script is now working again, thank you! For referrence, this is what they had me do: do a git pull from within the Docker terminal. Once you are connected via terminal (as the appropriate user) try the following commands to do a git pull (and clean etc) cd /nzbToMedia git reset --hard git pull git clean -i The last step to clean didn't work. I'm waiting for a reply to find out why After the recent SABnzbd docker update, the nzbToMedia script was not renaming the files. I had to update the script again, see above steps.
April 14, 20251 yr Is anybody else having issues when trying to download with VPN enabled (specifically Wireguard, haven't tried with others yet), after updating to the latest update on Docker Hub (4.5.1-1-02)? I was previously using the latest release available on there (4.4.1-1-01) which was working fine, but downloads just aren't working at all on the latest update for me. Server connections are timing out with a "[Errno 111] _ssl.c:1011: The handshake operation timed out" error, and the SABnzbd test downloads seem to download the test nzb file fine, but never actually start downloading the actual test file. Reverting back to the older version or turning off the VPN fixes the issue no problem. I'm also using the latest Binhex qBittorrent container with the exact same VPN setup and that one works no problem. I also couldn't see any obvious issues flagged up in the container logs. Edited April 14, 20251 yr by BallistiX09
May 9, 20251 yr I have been using SABnzb docker with news.newshosting.com for years with zero issues. The other day, I had to switch ISPs. In my haste, I forgot to pause my queue and simply switched out cables. Since then, SABnzb has been receiving Server address news.newshosting.com:563 is not valid. I have also tried this using port 119 with the same results. I initially thought I had too many connections because of the switch but that's not the error I was getting back for that. When I hit the wrench for status and interfaces, I get a never-ending loading status. Now as a test I loaded NZBGet docker as a test and everything connects fine and resolves. So this tells me its an issue with SABnzb docker. I also loaded the SABnzb Windows program and it connected fine as well. Does anyone have a clue? I have tested this on two separate machines on two different ISPs on two different networks with the same results. I get the resolve issue on SABnzb docker, but it works fine with NZBGet, both Windows and Linux Docker. I can also ping and do NSLookups with no issues from the machines themselves. I can also do pings and nslookups inside the docker itself with no issue as well.
May 20, 20251 yr Hi all, Have my SABnzdb container installed but according to the configuration inside the container app its using /config as the default user folder and system folder. I would like the user folder to use /data as specified in the container of the docker. As /config is appdata on my cache drive. How do I change this? Thanks, Dwarfboysim
July 10, 2025Jul 10 My SAB container updated to latest version at 12am this morning (11/7/25 6:21am is the time now here) container just keeps restarting with :sabnzb warning SIGTERM signalled exit request signal 15 exit code 143, disabled health check still happening, am currently rolling back to previous release which seemed stable to see if that fixes issue for me***this seems to of fixed the restart loop, also was an “Warning” about 7za being missing I think it was, that is also gone…..so far Edited July 10, 2025Jul 10 by Redman Update on issue inserted into post
July 11, 2025Jul 11 I have also the warning 7za not found since upgrading to the latest version yesterday.Everything that I use seems to work fine but it's a bit annoying having the warning every day
July 11, 2025Jul 11 Author 1 hour ago, BiLKiNiS said:I have also the warning 7za not found since upgrading to the latest version yesterday.Everything that I use seems to work fine but it's a bit annoying having the warning every dayfixed, please pull down latest.
July 16, 2025Jul 16 Hey everyone,I've been running into a new issue with my SABnzbd container randomly shutting down since the last update. This wasn't happening before, so I'm trying to figure out what might be going on.I've already checked my Unraid logs around the shutdown times, but nothing obvious pops out as a cause. Has anyone else experienced this, or does anyone have suggestions on what might be causing these unexpected shutdowns? 025-07-16 18:47:38,484 WARN received SIGTERM indicating exit request2025-07-16 18:47:38,485 DEBG killing start-script (pid 53) with signal SIGTERM2025-07-16 18:47:38,485 INFO waiting for start-script to die2025-07-16 18:47:38,486 DEBG 'start-script' stdout output:2025-07-16 18:47:38,485::WARNING::[__init__:202] Signal 15 caught, saving and exiting...2025-07-16 18:47:38,486 DEBG 'start-script' stdout output:2025-07-16 18:47:38,485::WARNING::[__init__:202] Signal 15 caught, saving and exiting...2025-07-16 18:47:38,486 DEBG 'start-script' stdout output:2025-07-16 18:47:38,486::INFO::[__init__:419] [N/A] Performing SABnzbd shutdown2025-07-16 18:47:38,486 DEBG 'start-script' stdout output:2025-07-16 18:47:38,486::INFO::[__init__:336] SABnzbd shutting down...2025-07-16 18:47:38,487 DEBG 'start-script' stdout output:2025-07-16 18:47:38,486::INFO::[ssdp:102] Stopping SSDP2025-07-16 18:47:38,487 DEBG 'start-script' stdout output:2025-07-16 18:47:38,486::INFO::[directunpacker:564] Aborting all DirectUnpackers2025-07-16 18:47:38,490 DEBG 'start-script' stdout output:2025-07-16 18:47:38,490::INFO::[notifier:163] Sending notification: SABnzbd - Shutting down (type=startup, job_cat=None)2025-07-16 18:47:38,490 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 22561696799376 for <Subprocess at 22561698013808 with name start-script in state STOPPING> (stdout)>2025-07-16 18:47:38,491 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22561696438928 for <Subprocess at 22561698013808 with name start-script in state STOPPING> (stderr)>2025-07-16 18:47:38,491 WARN stopped: start-script (exit status 143)2025-07-16 18:47:38,491 DEBG received SIGCHLD indicating a child quit
July 16, 2025Jul 16 On 7/10/2025 at 3:26 PM, Redman said:My SAB container updated to latest version at 12am this morning (11/7/25 6:21am is the time now here) container just keeps restarting with :sabnzb warning SIGTERM signalled exit request signal 15 exit code 143, disabled health check still happening, am currently rolling back to previous release which seemed stable to see if that fixes issue for me***this seems to of fixed the restart loop, also was an “Warning” about 7za being missing I think it was, that is also gone…..so farLatest still doesn't fix the restart as I still get the signal 15 error. Reverted back to 4.5.1 with no problems.
July 17, 2025Jul 17 Author 11 hours ago, repomanz said:Latest still doesn't fix the restart as I still get the signal 15 error. Reverted back to 4.5.1 with no problems.Please revert back to latest and attach the /config/supervisord.log file
July 18, 2025Jul 18 On 7/16/2025 at 2:17 PM, Specky said:Hey everyone,I've been running into a new issue with my SABnzbd container randomly shutting down since the last update. This wasn't happening before, so I'm trying to figure out what might be going on.I've already checked my Unraid logs around the shutdown times, but nothing obvious pops out as a cause. Has anyone else experienced this, or does anyone have suggestions on what might be causing these unexpected shutdowns?025-07-16 18:47:38,484 WARN received SIGTERM indicating exit request2025-07-16 18:47:38,485 DEBG killing start-script (pid 53) with signal SIGTERM2025-07-16 18:47:38,485 INFO waiting for start-script to die2025-07-16 18:47:38,486 DEBG 'start-script' stdout output:2025-07-16 18:47:38,485::WARNING::[__init__:202] Signal 15 caught, saving and exiting...2025-07-16 18:47:38,486 DEBG 'start-script' stdout output:2025-07-16 18:47:38,485::WARNING::[__init__:202] Signal 15 caught, saving and exiting...2025-07-16 18:47:38,486 DEBG 'start-script' stdout output:2025-07-16 18:47:38,486::INFO::[__init__:419] [N/A] Performing SABnzbd shutdown2025-07-16 18:47:38,486 DEBG 'start-script' stdout output:2025-07-16 18:47:38,486::INFO::[__init__:336] SABnzbd shutting down...2025-07-16 18:47:38,487 DEBG 'start-script' stdout output:2025-07-16 18:47:38,486::INFO::[ssdp:102] Stopping SSDP2025-07-16 18:47:38,487 DEBG 'start-script' stdout output:2025-07-16 18:47:38,486::INFO::[directunpacker:564] Aborting all DirectUnpackers2025-07-16 18:47:38,490 DEBG 'start-script' stdout output:2025-07-16 18:47:38,490::INFO::[notifier:163] Sending notification: SABnzbd - Shutting down (type=startup, job_cat=None)2025-07-16 18:47:38,490 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 22561696799376 for <Subprocess at 22561698013808 with name start-script in state STOPPING> (stdout)>2025-07-16 18:47:38,491 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22561696438928 for <Subprocess at 22561698013808 with name start-script in state STOPPING> (stderr)>2025-07-16 18:47:38,491 WARN stopped: start-script (exit status 143)2025-07-16 18:47:38,491 DEBG received SIGCHLD indicating a child quitI have been experiencing the same. Nothing in logs either. Binhex Plexpass has also been doing it. Other dockers have been fine. Only since most recent updates.
July 18, 2025Jul 18 Author 2 hours ago, Skilid said:I have been experiencing the same. Nothing in logs either. Binhex Plexpass has also been doing it. Other dockers have been fine. Only since most recent updates.ive pushed out a new release, please pull down and let me know how you get on with it.
July 19, 2025Jul 19 My plan is to edit line 123 of skintext . py to display something other than Queue. Like the old days when people had custom header images on the server gui. But I don't know where to begin. Is this even possible?
July 19, 2025Jul 19 Author 15 hours ago, jeff.lebowski said:My plan is to edit line 123 of skintext . py to display something other than Queue. Like the old days when people had custom header images on the server gui. But I don't know where to begin. Is this even possible?It's possible to edit the python code but the change will be overwritten every time a new image is published, so yeah that's going to get frustrating for you real quick, i would back away from anything like that.
July 23, 2025Jul 23 On 7/18/2025 at 11:43 AM, binhex said:ive pushed out a new release, please pull down and let me know how you get on with it.Seems to be sorted now, thanks.
July 23, 2025Jul 23 On 7/18/2025 at 5:43 AM, binhex said:ive pushed out a new release, please pull down and let me know how you get on with it.My arr stack continues to fail after update to binhex/arch-sabnzbd:4.5.2 as well. No logs. Container fails to start.Issue: binhex/arch-sabnzbd:4.5.2 regression- Container starts but produces NO logs- Health check fails: curl -f http://localhost:8080- Previous working version: 4.5.1- Error: "container binhex-sabnzbd is unhealthy"- Behavior: Silent failure - no application logs generatedRolled back to binhex/arch-sabnzbd:4.5.1-1-01 and stack deploys without issue.
July 23, 2025Jul 23 Author 1 hour ago, KMPLSV said:My arr stack continues to fail after update to binhex/arch-sabnzbd:4.5.2 as well. No logs. Container fails to start.Issue: binhex/arch-sabnzbd:4.5.2 regression- Container starts but produces NO logs- Health check fails: curl -f http://localhost:8080- Previous working version: 4.5.1- Error: "container binhex-sabnzbd is unhealthy"- Behavior: Silent failure - no application logs generatedRolled back to binhex/arch-sabnzbd:4.5.1-1-01 and stack deploys without issue.interesting, i cannot replicate the issue, i have just tried with the latest image and a fresh config, i assume you are specifying the healthcheck via new HEALTHCHECK_COMMAND env var, right?.Can you please post your docker run command (edit container, change something, change it back and click apply then paste the contents of the subsequent window here) and attach the /config/supervisord.log file.
July 23, 2025Jul 23 2 hours ago, KMPLSV said:My arr stack continues to fail after update to binhex/arch-sabnzbd:4.5.2 as well. No logs. Container fails to start.Issue: binhex/arch-sabnzbd:4.5.2 regression- Container starts but produces NO logs- Health check fails: curl -f http://localhost:8080- Previous working version: 4.5.1- Error: "container binhex-sabnzbd is unhealthy"- Behavior: Silent failure - no application logs generatedRolled back to binhex/arch-sabnzbd:4.5.1-1-01 and stack deploys without issue.I've been watching this thread because I started having issue as well (just about the same time). Pretty much match what you're saying above.A couple days ago, I blew it away and reinstalled, and didn't restore anything for back up either. knock on wood.....it's been running fine since, on the latest.
July 29, 2025Jul 29 On 7/23/2025 at 3:26 PM, RichJacot said:I've been watching this thread because I started having issue as well (just about the same time). Pretty much match what you're saying above.A couple days ago, I blew it away and reinstalled, and didn't restore anything for back up either. knock on wood.....it's been running fine since, on the latest.Blew the container away, your entire Arr stack, or what? I'm still having the same issue.
August 24, 2025Aug 24 On 7/29/2025 at 2:16 PM, KMPLSV said:Blew the container away, your entire Arr stack, or what? I'm still having the same issue.No, just binhex-sabnzbd. It's been working right along now. 'shrug'
August 30, 2025Aug 30 On 7/23/2025 at 2:47 PM, binhex said:interesting, i cannot replicate the issue, i have just tried with the latest image and a fresh config, i assume you are specifying the healthcheck via new HEALTHCHECK_COMMAND env var, right?.Can you please post your docker run command (edit container, change something, change it back and click apply then paste the contents of the subsequent window here) and attach the /config/supervisord.log file.Regarding healthcheck, i'm using the setup below -- is that the issue? am i using old healthcheck method?binhex-sabnzbd:image: "binhex/arch-sabnzbd:4.5.1-1-01"container_name: "binhex-sabnzbd"hostname: "binhex-sabnzbd"networks:media:ipv4_address: xxxxxxxxhealthcheck:test: ["CMD", "curl", "-f", "http://localhost:8080"]interval: 10stimeout: 5sretries: 25start_period: 10s
October 6, 2025Oct 6 I've setup deluge vpn docker, and have all of my arrs running through it fine. I did this back in the 6.9 days of unraid, so each of those dockers routing through deluge have the --net=container:binhex-delugevpn parameter.Now I've decide to take a look at SABnzdb for usenet. I want to route it thorough my deluge vpn docker as well. The default port for SABnzdb is 8080, which another docker currently uses. So I want to set it to be port 8085 (or whatever free port there is).On the SABnzdb docker, I've set the Port: Web Interface to 8085. On Deluge, I've added that port to the various variable that require it (same as my other dockers). But I cannot get the SABnzdb GUI to load. I even went so far as to try and modify the /mnt/user/appdata/binhex-sabnzbd/sabnzbd.ini file (with the docker off) to use port 8085 (port = 8085). But every time I start the docker, the config file reverts the port back to 8080.I must be missing something with the config. The SAB docker should be able to route through delugevpn. Looking for suggestions on what to try next. Edited October 6, 2025Oct 6 by Xoron
January 12Jan 12 Clicking the purge history button then clicking purge completed does nothing. Nothing in that purge history dialog box functions. I need to click Multi-operations then select all then delete them that way. This stopped working a few months ago. Is there a fix or just a bug with the latest container update?
January 13Jan 13 Author On 1/12/2026 at 1:28 AM, z0ki said:Clicking the purge history button then clicking purge completed does nothing. Nothing in that purge history dialog box functions. I need to click Multi-operations then select all then delete them that way. This stopped working a few months ago. Is there a fix or just a bug with the latest container update?If you are having issues with the application then i would advise posting an issue on the sabnzbd github repo:- https://github.com/sabnzbd/sabnzbd/issues
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.