* feat(sabnzbd): enable Home Assistant ingress
The add-on already carried a complete but disabled nginx ingress scaffold:
`etc/nginx/` with its includes and a `servers/ingress.conf`, a
`cont-init.d/32-nginx_ingress.sh` short-circuited by `exit 0`, and
`ENV PACKAGES="nginx"` in a Dockerfile byte-identical to nzbget's. Only
`ingress: true` and the s6 service that starts nginx were missing.
What SABnzbd 5.1.1 actually needs from the proxy, measured against the
running add-on rather than assumed:
- Its interface emits only relative links (`href="../../config/general/"`,
`href="../../staticcfg/css/Auto.css"`, `action="./one"`), and grepping the
5.1.1 source for `(href|src|action)="/` across `interfaces/{Glitter,Config,
wizard}` and for absolute `url:` literals in the Glitter JavaScript returns
nothing. A plain pass-through proxy preserves path depth, so no `sub_filter`
is warranted. The previous config's `sub_filter /sabnzbd ...` would also have
mangled the `https://sabnzbd.org/wiki/...` help links present on every
config page.
- Redirects are the one exception: `Raiser()` prefixes `cfg.url_base()`, so
`GET /` answers `303 Location: /sabnzbd/wizard/`. One `proxy_redirect`
handles every observed case; all of them were path-absolute, never a full
URL. Login redirects and logout go through the same `Raiser()`, and the
session cookie's path is hardcoded to `/` (`interface.py:316`), so it is
still sent under the ingress path.
- SABnzbd rejects a Host header that is not an IP literal:
`Host: homeassistant` answers 403 "Hostname verification failed", while
`Host: 192.168.1.5:8123` answers 200. nginx therefore sends `$proxy_host`
instead of including the shared `proxy_params.conf`, which forwards
`$http_host`.
`ingress_entry: sabnzbd` is dropped rather than kept: Supervisor appends it to
the ingress URL, which only resolves while the user's `url_base` is literally
`/sabnzbd`, and that is a setting they can change. SABnzbd serves the same
interface at `/` as under its `url_base` (verified for `/config/general/`,
`/static/`, `/staticcfg/` and `/wizard/`), so entering at the ingress root
works for any value, including the empty code default.
Ingress traffic reaches SABnzbd as `127.0.0.1:8080` and so is not filtered by
a user's host whitelist; direct ip:port access is unchanged and still is.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(sabnzbd): keep the ingress Location relative and scope the login cookie
Exercising the shipped config against the running add-on caught a bug that
reading it did not. With nginx's default `absolute_redirect on`, rewriting
`Location: /sabnzbd/wizard/` produced
`http://homeassistant.local:18099/api/hassio_ingress/<token>/sabnzbd/wizard/`
— nginx expands a scheme-less replacement using the browser's Host and its own
listen port, which is the add-on's internal ingress port and is not reachable
from the browser. `absolute_redirect off` keeps it a path, which the browser
resolves against the Home Assistant origin.
`proxy_cookie_path` comes from Codex's review of the diff. SABnzbd hardcodes
the login cookie to `Path=/` (`interface.py:316`), so on the shared ingress
origin the browser would send it to every other add-on's ingress path as well.
Verified end to end by running the shipped nginx.conf and ingress.conf against
the live add-on, with the browser Host set to a non-IP hostname throughout:
all five redirect cases return a path under the ingress entry, the config
pages, wizard, API and both static roots return 200, and a stub upstream
emitting `Path=/` comes back rewritten to the ingress path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(sabnzbd): drop webui, which the add-on linter forbids alongside ingress
frenck/action-addon-linter fails the PR with "'webui' should be removed,
Ingress is enabled." No other ingress add-on in this repo keeps the key. The
"Open Web UI" button now opens ingress; the ports mapping is untouched, so
direct ip:port still works, it just has to be typed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(sabnzbd): make the nginx finish script actually work on s6-overlay v3
CodeRabbit is right that the execline finish script copied from nzbget is
inert on this image. s6-portable-utils dropped `s6-test` in favour of
execline's `eltest` — s6-overlay 3.2.1.0 ships no `s6-test` at all — so
execlineb cannot run the first `if` block and never reaches s6-svscanctl.
`/var/run/s6/services` is also the v2 scandir path; v3's legacy services.d
compatibility layer uses /run/service.
Rather than port it to eltest, use the shell form the scrutiny add-on already
ships: `kill -15 1` signals s6-overlay's init directly, so it depends on
neither the s6 tool set nor the scandir path, and it is three lines shorter.
The 0 and 256 exclusions are kept, so a normal shutdown does not trigger it.
Also fix the CHANGELOG date to YYYY-MM-DD per Copilot: that is what this file
and 7705 of the repo's 8068 dated headings use.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Home assistant add-on: sabnzbd
I maintain this and other Home Assistant add-ons in my free time: keeping up with upstream changes, HA changes, and testing on real hardware takes a lot of time (and some money). I use around 5-10 of my >110 addons so regularly I install test machines (and purchase some test services such as vpn) that I don't use myself to troubleshoot and improve the addons
If this add-on saves you time or makes your setup easier, I would be very grateful for your support!
Addon informations
Thanks to everyone having starred my repo! To star it click on the image below, then it will be on top right. Thanks!
About
sabnzbd is a usenet downloader, written in C++ and designed with performance in mind to achieve maximum download speed by using very little system resources. This addon is based on the docker image https://github.com/linuxserver/docker-sabnzbd
Configuration
Webui can be found at http://homeassistant:PORT or through the sidebar using Ingress.
The default username/password: login:sabnzbd, password:tegbzn6789
Configurations can be done through the app webUI, except for the following options.
Options
| Option | Type | Default | Description |
|---|---|---|---|
PGID |
int | 0 |
Group ID for file permissions |
PUID |
int | 0 |
User ID for file permissions |
TZ |
str | Timezone (e.g., Europe/London) |
|
localdisks |
str | Local drives to mount (e.g., sda1,sdb1,MYNAS) |
|
networkdisks |
str | SMB shares to mount (e.g., //SERVER/SHARE) |
|
cifsusername |
str | SMB username for network shares | |
cifspassword |
str | SMB password for network shares | |
cifsdomain |
str | SMB domain for network shares |
Example Configuration
PGID: 0
PUID: 0
TZ: "Europe/London"
localdisks: "sda1,sdb1"
networkdisks: "//192.168.1.100/downloads,//nas.local/usenet"
cifsusername: "downloader"
cifspassword: "password123"
cifsdomain: "workgroup"
Mounting Drives
This addon supports mounting both local drives and remote SMB shares:
- Local drives: See Mounting Local Drives in Addons
- Remote shares: See Mounting Remote Shares in Addons
Custom Scripts and Environment Variables
This addon supports custom scripts and environment variables through the addon_config mapping:
- Custom scripts: See Running Custom Scripts in Addons
- env_vars option: Use the add-on
env_varsoption to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.
Installation
The installation of this add-on is pretty straightforward and not different in comparison to installing any other add-on.
- Add my add-ons repository to your home assistant instance (in supervisor addons store at top right, or click button below if you have configured my HA)
- Install this add-on.
- Click the
Savebutton to store your configuration. - Set the add-on options to your preferences
- Start the add-on.
- Check the logs of the add-on to see if everything went well.
- Open the webUI and adapt the software options
Support
Create an issue on github

