"Permission denied" in Synology container manager

[koehntopp]

I'm getting

Error: Permission denied (os error 13)
2026-08-09T10:01:06.762076Z INFO rustnzb: rustnzb v1.4.1+v1.4.1
Error: Permission denied (os error 13)
2026-08-09T10:01:07.770443Z INFO rustnzb: rustnzb v1.4.1+v1.4.1

Unfortunately the log doesn't show where exactly this comes from, is there a way to increase debug information?

It worked initially, I only tried to change the port to what sabnzbd used to make integration with my other stuff easier (and yes, I shut down sabnzbd). UID and GID are also correct.

Additional info: Seems it fails creating the /download folders - they do get created, but there are still errors:

[AusAgentSmith]

Investigating

[thedancingdeveloper]

Findings

Traced this from main() down through the Docker/s6 startup path. Root cause isn't fully confirmed yet (need info below from the reporter), but here's what the code tells us.

Why the error is bare text with no context

main() returns anyhow::Result<()> (apps/rustnzb/src/main.rs:190). anyhow only prints a "Caused by:" chain when the error carries extra context. Two startup call sites propagate a raw std::io::Error via a bare ? with no .context(), so they print exactly Permission denied (os error 13) and nothing else — matching the report verbatim:

• crates/nzb-web/src/startup.rs:124-126 — create_dir_all on data_dir / incomplete_dir / complete_dir, the first fallible call after the version banner logs.
• apps/rustnzb/src/server.rs:399 — TcpListener::bind(&addr).await?.

Everywhere else that touches io::Error during startup already wraps it with .with_context(...) (e.g. AppConfig::load/save in crates/nzb-core/src/config.rs:314-345, which even prints a Docker-specific ownership hint) — so if either of those had fired, the log would show more than two bare lines. That rules out config load/save as the source here.

The "changed the port" detail is a red herring — and surfaced a separate bug

The Docker image's s6 service script hardcodes the port:

# apps/rustnzb/root/etc/s6-overlay/s6-rc.d/svc-rustnzb/run
exec s6-setuidgid abc rustnzb --config /config/config.toml --data-dir /data --port 9090

Since --port 9090 is always passed explicitly, and clap gives an explicit CLI arg precedence over the RUSTNZB_PORT env fallback, the internal listen port can't actually be changed in the Docker image — not via env var, not via config.toml (it gets overridden at crates/nzb-web/src/startup.rs:92-94), and there's no port field in the Settings UI's UpdateGeneralBody either (apps/rustnzb/src/handlers.rs:1593-1605). So whatever port change was made was almost certainly the Synology host-side port mapping, which doesn't touch the container's internal bind — likely unrelated to the crash, just something changed around the same time. Still, RUSTNZB_PORT being advertised but silently dead in the Docker image is worth fixing on its own.

Best fit for the actual crash, matching "downloads folders get created, but there are still errors"

apps/rustnzb/root/etc/s6-overlay/s6-rc.d/init-rustnzb-config/run only chowns three hardcoded paths — /downloads, /downloads/incomplete, /downloads/complete — non-recursively, with failures silently swallowed (|| true):

mkdir -p /config /data /downloads/incomplete /downloads/complete
chown -R abc:abc /config /data
chown abc:abc /downloads /downloads/incomplete /downloads/complete 2>/dev/null || true

If the effective incomplete_dir / complete_dir / data_dir differs from those three defaults (custom path via Settings, or a Synology shared folder with Btrfs/Windows ACLs that override plain chown), create_dir_all at startup.rs:124 can hit EACCES on a path that looks present but isn't actually writable by abc — directories get created by mkdir -p at container init, ownership silently fails to stick, error surfaces later with no context.

Requesting from reporter

To confirm which of the two unguarded call sites (startup.rs:124 vs server.rs:399) is firing:

1. Full log around the crash — specifically whether Database opened appears before the error (proves it got past directory creation).
2. The effective general.port, incomplete_dir, complete_dir, data_dir values from /config/config.toml.
3. Whether the Synology shared folder backing /downloads (or /config//data) has Windows/Btrfs ACLs enabled — a known source of chown not sticking on Synology even though POSIX bits report success.

Proposed fix scope

1. Add .with_context(...) at startup.rs:124-126 and server.rs:399, mirroring the pattern in config.rs:314-332 (include the failing path, and a Docker/permission hint for the dir-creation case).
2. Fix RUSTNZB_PORT/--port being dead in the Docker image (either stop hardcoding --port 9090 in the s6 run script and rely on the env var default, or document clearly that port isn't configurable in the container).
3. Consider making the init-rustnzb-config chown cover the configured dirs (or recursive on /downloads) rather than three hardcoded defaults, so custom paths set via the Settings UI actually get ownership applied at container init.

Test plan

Positive

• startup::initialize with a fresh, writable custom incomplete_dir/complete_dir/data_dir (not matching the three hardcoded Docker defaults) succeeds and creates all three directories.
• After adding .with_context, a forced create_dir_all failure (e.g. point data_dir at a path under a directory created read-only in the test) produces an error whose {:?} output includes both the failing path and a "Caused by:" permission-denied source — i.e. the fix actually changes what gets printed, not just internal plumbing.
• TcpListener::bind failure in server::serve (e.g. bind a first listener to a fixed port, then call serve again against the same listen_addr/port to force AddrInUse) after the fix carries context identifying the bind address, not a bare os-error string.
• CLI: RUSTNZB_PORT=8123 rustnzb --smoke-test-style check (or a unit test around Args::parse_from / StartupConfig construction) confirming the env var is honored when no explicit --port flag is present — guards against a future regression reintroducing the current Docker-image behavior elsewhere.

Negative

• startup::initialize with data_dir pointed at a path whose parent directory is chmod 000 (unix-only, #[cfg(unix)]) returns Err (not a panic) and the error is PermissionDenied in the source chain.
• server::serve with listen_addr/port already bound by another listener returns Err rather than hanging or panicking.
• Regression guard for the port-hardcoding bug: assert that Args::parse_from(["rustnzb", "--port", "1234"]) still wins over RUSTNZB_PONT/env when an explicit flag is given (documents/locks in the existing clap precedence, since any future entrypoint fix must not silently flip this).

Happy to send a PR for the .context() fixes plus the test additions above once the reporter confirms which path is failing — will keep the port-hardcoding fix and chown-script change as a separate follow-up since they're independent of the immediate crash.

[thedancingdeveloper]

Opened #63 with the .context() fix + regression tests for the bare-error-message mechanism (reproduced locally). Still open pending your config values / full log to pin down which exact path fired for you — see the request above.

[koehntopp]

OK, thanks for the analysis, this fixed it.
I did not manually create config.toml, it got created by importing SABnzbd config.

• docker-compose.yml mapped a NAS folder to "/downloads"
• config.toml now had folders mapped to "Downloads"

So there are two places to configure paths, and the sabnzbd import creates paths that do not exist ("/downloads" vs "Downloads").

It may be able to fix that in the sabnzbd import.

[thedancingdeveloper]

Thanks for confirming, and for digging into the actual cause — that's exactly the kind of detail that was impossible to see before the context fix.

Root cause confirmed: SABnzbd import writes unvalidated paths

Traced this through the code and can confirm your theory:

• crates/nzb-core/src/sabnzbd_import.rs reads SABnzbd's complete_dir / download_dir (from the .ini or the live API) as raw strings, filtered only for emptiness — no check for whether the path is absolute or actually exists.
• apps/rustnzb/src/handlers.rs:2083-2088 (h_setup_apply) then writes those strings straight into config.general.complete_dir / incomplete_dir via a bare PathBuf::from(dir) — no is_absolute() check, no normalization, no awareness that the Docker image's real mount points are fixed at /downloads, /data, /config.
• When that relative path ("Downloads", from your old SABnzbd config) later hits create_dir_all in crates/nzb-web/src/startup.rs, it resolves relative to the container's working directory — not your /downloads volume mount — which is exactly the permission/directory-creation failure you originally hit.

There's currently no test covering a relative-path import; the existing SABnzbd import tests only assert absolute paths pass through unchanged.

Plan

This is a real, separate bug from the diagnostics fix in #63/v1.4.2. I'll follow up with a fix that rejects (or warns on) relative imported paths — either surfacing a warning in the import preview before the user applies it, or having h_setup_apply refuse relative dirs and fall back to the Docker-aware defaults — with regression tests covering both the relative-path rejection and the existing absolute-path passthrough. Will open a separate PR for that; keeping this issue open until it lands.