Setup: SparkBox on UGREEN NAS (DXP2800), media module enabled, notifiarr container running fine per docker ps (shows healthy). Symptom: Every time sb-notifiarr starts (fresh boot or restart), logs immediately show: [ERROR] ... Skipping tunnel creation because there is no client info. No outbound API call attempted, no DNS/timeout/TLS error — it just skips before trying anything. This also blocks the local WebUI login at port 5454 — every login attempt (correct username/password) returns: Login failed: Invalid username or password. 401 Unauthorized Confirmed via logs this 401 fires immediately after the "no client info" line — looks like local login auth depends on client registration state, so it 401s for everyone until that's resolved. What I've ruled out (with Tom AI's help): ✅ API key is valid — checked on notifiarr.com, key matches what's saved in the WebUI exactly ⚠️ No device/client shows up on notifiarr.com's device list — key has never successfully registered ✅ Config file (notifiarr.conf) is NOT empty — 5KB+, structurally valid (all trigger/action definitions load correctly at startup per logs) ✅ Not stale/in-memory state — did a full container restart (fresh process, fresh config read), identical failure ✅ Not a file permissions issue — ran fixmediapermissions to confirm ownership/perms on the config dir, no change My read: Since the rest of the config parses and loads fine (actions/triggers work), but whatever field holds the API key/client info specifically isn't being picked up, this looks like a field-mapping bug between what the WebUI writes to notifiarr.conf and what the startup/tunnel-init code reads for "client info." Would love a look at that mapping. Happy to grab more logs/config detail if useful — just say what you need.
5 replies
Chris wrote:
This is a tricky one — you've ruled out the obvious culprits really thoroughly. The API key → environment variable → tunnel init flow looks solid in code, but something in that chain isn't wiring up. Let me flag this directly to Tom; he handles the notifiarr integration personally and will want to see your logs (especially the first ~30 lines when sb-notifiarr starts). Grab those from your logs and reply here with them, and I'll make sure he gets them priority. You're a backer so we'll get this tracked down.
Chris wrote:
Update for you: Tom took your report personally and directed the fix — it is shipping right now in v1.6.376. You had the diagnosis basically right. The key you saved through Notifiarr's own page was being overridden on every startup by an empty one coming from our side, so the client never registered — which is also exactly why the login page 401d everyone (local auth depends on registration). Your ruling-out work made this a fast find, genuinely. Once your box picks up 1.6.376: run sudo sparkbox restart media once, and your existing key should register within a minute — you will see your device appear on notifiarr.com. If it does not, say so here and Tom will look at your box directly.
globaltarheel8 wrote:
Thanks! Unfortunately still having issues. Now when I open notifiarr from SB it doesn’t request global key anymore. In meantime, here’s my Tom AI summary: sb-notifiarr healthy, container up, NOTIFIARRENABLED=true in .env. Login attempts to /?login=true return flat 401. GET /ui/profile 302-redirects back to login (not authenticated). Backed up and fully cleared /opt/sparkbox/modules/media/config/notifiarr, recreated empty dir, restarted container — came up in ~2 min, but same 401 behavior persisted, and it never showed the expected first-run/global-API-key setup screen. So the wipe-and-reseed did not force a fresh setup state — looks like something's either surviving outside /config, or the container isn't actually re-initializing on empty config.
Chris wrote:
Good detective work on that wipe test. I think I see it -- SparkBox has its own separate Notifiarr API key field in Settings (under the Media app's Notifiarr card), apart from the notifiarr.conf file you cleared. If that field still has something saved in it -- even the old broken value -- it gets pushed back into the container on every restart and would explain why the setup screen never shows and it still 401s. Can you check that field, clear it out, save, then paste in your key fresh from notifiarr.com and restart? Let us know what you find.
Chris wrote:
First — a correction on my last message: there is NO Notifiarr key field in SparkBox Settings today. I was wrong to point you there, sorry. Tom checked the actual code and that field simply does not exist yet — which turns out to be the real root of this whole saga: SparkBox never gave you a place to enter the key, and Notifiarr has no browser first-run wizard either. With your config wiped, the box is simply keyless — that is the flat 401. The fix that will work: SSH in and run sudo nano /opt/sparkbox/.env — add this line (key from notifiarr.com, Profile API Keys): NOTIFIARRAPIKEY=your-key-here — save, then sudo sparkbox restart media. Your device should appear on notifiarr.com within a minute, and the WebUI login is username admin with that same API key as the password. Tom also directed a proper fix shipping in the next update: enabling Notifiarr from the dashboard will ask for the key up front, so nobody hits this again.