Dude first off, you crushed this thing. Very much appreciate the work. Looking for some help with Seerr. It crashes about 15-30 seconds after opening. Didnt see anything in the logs and it seems to be still operating-ish (things are still being requisitioned). Not seeing any issues with the other services. The problem seemed to be with how its running on my NAS (sparkbox/seerr works well if ran from my laptop as if it was a server). UGREEN NAS DXP4800PLUS-857
27 replies
tomspark wrote:
Hey, thank you — that genuinely means a lot! 🙏 Let's pin down what "crash" means here, since it works from your laptop but not the NAS. Two quick things: sudo docker ps -a | grep seerr Look at the STATUS — is sb-seerr restarting / short uptime (the container itself is dying), or has it been "Up" a while (in which case it's the web page/session, not the container)? And on screen when it goes ~15-30s in — does the page go blank/white, throw an error, or does the browser tab itself die? That difference tells me whether it's a memory thing on the NAS, a connection drop, or a front-end issue. Paste that docker line and describe what you see, and I'll get it sorted.
tomspark wrote:
Ah, that's much clearer — and good news, your Seerr container is actually healthy (up 27 min), so nothing's crashing. It's a SESSION issue: the login just doesn't stick. SparkBox has a fix for exactly this (a patch that keeps Seerr's login session alive), and it sometimes needs re-applying — most often after a restart or update. Run: sudo sparkbox restart media That re-applies the Seerr session patch and restarts it. Give it a minute, then log into Seerr again and see if it holds past 30 seconds this time. If it STILL kicks you back to the login screen, that points specifically at the Seerr↔Jellyfin link — tell me and I'll dig into that side (there's an open issue there I can tie yours to).
tomspark wrote:
Thanks for trying — so the session patch alone isn't fixing it, which means it's the Seerr↔Jellyfin link specifically, not just the cookie. Two things to pin it down: 1) When it kicks you back to the login screen, grab what Seerr logged at that moment: sudo docker logs sb-seerr --tail 30 Paste it — I'm looking for an auth/401 error right around the logout. 2) How are you opening Seerr on the NAS — directly at http://<NAS-IP:5055, or through a domain/dashboard link? (That "works from my laptop" clue makes me suspect the access path.) I'm also flagging this to Tom — there's an open Seerr/Jellyfin session issue and yours adds a clear data point. We'll get it sorted.
tomspark wrote:
That's a perfect test — thank you. With the laptop fully off and a fresh computer, it STILL logs you out, which rules out the two-servers theory completely. My bad on that call. So this is a genuine session issue on the NAS Seerr itself, not a conflict — which means it's on our side to fix. Get some sleep, you've done the hard diagnostic work already. When you're back, one thing will crack it: grab the Seerr log at the exact moment it kicks you out (now that only the NAS is running, it'll show the real reason cleanly) — sudo docker logs sb-seerr --tail 40. I'm flagging this to Tom as a confirmed Seerr session bug in the meantime. Sleep well, and thanks for the thorough testing! 🙏
tomspark wrote:
Two useful things from that: - The clock's actually fine — that 'off' is just the system showing UTC instead of your local Mountain time (the log stamps line up correctly). So we can rule clock out. - And there's NO error at the kick — just the normal login line and routine jobs. That's the key tell: Seerr isn't erroring or expiring you, so the logout is happening in your browser, not on the server. The page is redirecting itself to login. Two quick tests to corner it: 1. Open Seerr in an incognito/private window (or a different browser) and log in. If it does NOT kick you there → it's a stale cookie in your normal browser; clear Seerr's cookies and you're set. 2. If incognito ALSO kicks you: open dev tools (F12) → Network tab → log in, and watch for a request that turns red / returns 401 right as it boots you (likely something like /api/v1/auth/me). Tell me which request fails — that's the exact culprit. This is the known one I'm chasing, and your detail is genuinely helping pin it.
tomspark wrote:
That 403 nails it — thank you. Here's what's happening: you ARE logged in (your session cookie is right there in the request), but Seerr rejects the follow-up auth check with a 403, not a 401. That exact combo — 403 on /api/v1/auth/me with a valid cookie — is Seerr's 'CSRF Protection' kicking in. CSRF protection is a HTTPS-only feature; with it ON while you're on plain http, every auth check gets forbidden, so it boots you. That's why it's every browser AND incognito. The fix: in Seerr go to Settings - General - find 'Enable CSRF Protection' and turn it OFF - Save. You've got that ~20-second window after login to do it, so head straight there. Then restart Seerr so it takes effect: sudo sparkbox restart media Log back in and it should finally stick. If that 20-second window is too tight to reach the toggle, say the word and I'll give you a one-line terminal command to flip it instead. (And if CSRF is on by default in our build, that's a real bug — anyone accessing over http would hit this — so you may have just helped me find a class-level fix.)
tomspark wrote:
That changes the picture in a good way. If CSRF is already off AND Chrome is rock-solid while only Firefox boots you, then it's not a server problem at all — Seerr is clearly fine (Chrome proves it). Firefox is just a lot stricter about cookies than Chrome, so scratch my CSRF theory. Two quick Firefox fixes: 1. Clear Seerr's cookies in Firefox specifically (it's likely holding a stale session cookie that Chrome already refreshed). Then reload and log in. 2. If that doesn't do it: on the Seerr page in Firefox, click the shield icon in the address bar and turn OFF 'Enhanced Tracking Protection' for that site — Firefox can partition cookies and quietly break the session. Honestly though, Chrome works perfectly, so you're fully unblocked either way — Firefox is just a nice-to-have. Try those two and let me know which one does it.
Marauders wrote:
Maybe crash is the wrong word to use here. After logging in, 15-30 seconds it automatically logs out and it returns to the login screen. The password initially set with jellyfin becomes invalid and, from my limited knowledge of the system, the only way to get a new password is to restart the service. using putty to SSH in. I got: "docker-entrypoint. s..." 27 mintues ago Up 27 minutes (healthy) 0.0.0.0 5055 - 5055/tcp, :::5055-5055/tcp
Marauders wrote:
ran "sudo sparkbox restart media". Still no joy with Seerr. Still kicking me back to the login screen after 30 seconds or so.
Marauders wrote:
I am not seeing a auth/401 error around the log out time. What I am seeing is the address for the laptop with this line "Found matching Jellyfin user; updating user with Jellyfin {ip: "IP address of my laptop", "jellyfinUsername":" sparkbox". My NAS and laptop (sparkbox server) seem to be chatting? (just a thought based on the IP address from laptop sparkbox server). I am using the link from the dashboard and not the Http://:5055. can give that a go.
tomspark wrote:
That's the answer right there — you've got SparkBox running on BOTH your NAS and your laptop, and both are using the same Jellyfin user ("sparkbox"). When you log into one, the other's Seerr updates that Jellyfin user (you can see it in the log stamping your laptop's IP on the account), which boots the other session out. They're fighting over the same login — that's the 30-second logout. Fix: pick ONE to actually use and shut the other's Seerr/SparkBox down, OR if you want both running, give each its own separate Jellyfin user instead of both being "sparkbox". Once they're not sharing one account, the logout loop stops. Good news is it's not a bug — just two servers sharing a login. Nice detective work spotting that laptop IP!
Marauders wrote:
For a quick verification I shutdown that laptop and only had the NAS running. Jumped on another computer. With the laptop sever completely powered off, and using a completely different computer to log into the NAS, seerr is still kicking me to the log in screen. I gotta get some sleep due to work tomorrow, thanks for all the help up until this point. My assumption right now is, something has to be cached. Ill attempt to capture the logs of seerr using the sudo commands above sometime tomorrow and follow up. Thanks again
Marauders wrote:
Good afternoon yall. Ran the sudo code and I got the response below. That IP address listed in that code, I dont recognize it at all. Sanitized the last digits if it was important how this is run Found matching Jellyfin user; updating user with Jellyfin {"ip":"::ffff:192.168.1.XX","jellyfinUsername":"sparkbox"}
tomspark wrote:
Good news on that one — that line is actually Seerr working correctly, not the crash. It found your Jellyfin user (sparkbox) and synced it, and the '::ffff:192.168.1.XX' is just a normal way of writing a regular IPv4 address (the ::ffff: prefix is harmless) — it's whatever device you logged in from. Quick sanity check: is 192.168.1.x your home network's range? If your LAN is a different range that'd be worth a flag; if that IS your range, it's just your device. The key thing: that log caught the LOGIN, not the crash — which fits you not seeing an error. Since it boots you ~15-30s after login on the NAS but is rock-solid from your laptop, this looks like a session drop tied to how it's being reached, not a Seerr error. Two things to pin it down: 1. When it 'crashes', what exactly happens — page goes blank, reloads, logs you out, or shows an error message? 2. Run this RIGHT AFTER it boots you (not at login) and paste it: docker logs sb-seerr --tail 30 — the lines at the crash moment are the ones we need. For the record, this 'logs out shortly after login' is already on my list as a real bug we're chasing, so your details are genuinely helping narrow it.
Marauders wrote:
Copy on the first bit. Should have looked at what was active when I wrote that. Upon the "crash" the window refreshes and it reloads to the log in screen. Using the pasting sudo docker logs sb-seerr --tail 30 gives me the following below. Also for future individuals looking at what I am scooping, I am preparing for a life without interwebs for about 7 months. Marauders@DXP4800PLUS-857:~$ sudo docker logs sb-seerr --tail 30 2026-06-05T03:05:00.028Z [debug][Jobs]: Starting scheduled job: Download Sync 2026-06-05T03:05:00.043Z [info][Jobs]: Starting scheduled job: Jellyfin Recently Added Scan 2026-06-05T03:05:00.044Z [info][Jellyfin Sync]: Scan starting {"sessionId":"874f3837-1846-41b3-a739-7733c931f777"} 2026-06-05T03:05:00.059Z [info][Jellyfin Sync]: Beginning to process recently added for library: Movies 2026-06-05T03:05:00.139Z [debug][Jellyfin Sync]: Title already exists and no changes detected for Protector 2026-06-05T03:05:00.211Z [debug][Jellyfin Sync]: Title already exists and no changes detected for Iron Lung 2026-06-05T03:05:00.215Z [debug][Jellyfin Sync]: Title already exists and no changes detected for Is God Is 2026-06-05T03:05:00.216Z [debug][Jellyfin Sync]: Title already exists and no changes detected for Hokum 2026-06-05T03:05:00.216Z [debug][Jellyfin Sync]: Title already exists and no changes detected for Fuze 2026-06-05T03:05:00.216Z [debug][Jellyfin Sync]: Title already exists and no changes detected for Captain America: Brave New World 2026-06-05T03:05:00.216Z [debug][Jellyfin Sync]: Title already exists and no changes detected for The Killer's Game 2026-06-05T03:05:00.216Z [debug][Jellyfin Sync]: Title already exists and no changes detected for Ballerina 2026-06-05T03:05:00.217Z [debug][Jellyfin Sync]: Title already exists and no changes detected for Over Your Dead Body 2026-06-05T03:05:00.217Z [debug][Jellyfin Sync]: Title already exists and no changes detected for Propeller One-Way Night Coach 2026-06-05T03:05:00.218Z [debug][Jellyfin Sync]: Title already exists and no changes detected for Lee Cronin's The Mummy 2026-06-05T03:05:00.219Z [debug][Download Tracker]: Found 10 item(s) in progress on Radarr server: Radarr 2026-06-05T03:05:00.219Z [debug][Jellyfin Sync]: Title already exists and no changes detected for The Astronaut 2026-06-05T03:05:04.222Z [info][Jellyfin Sync]: Beginning to process recently added for library: TV Shows 2026-06-05T03:05:04.415Z [debug][Jellyfin Sync]: Updating existing title: Rooster Fighter 2026-06-05T03:05:04.435Z [debug][Jellyfin Sync]: Updating existing title: Star City 2026-06-05T03:05:04.440Z [debug][Jellyfin Sync]: Updating existing title: The Last of Us 2026-06-05T03:05:04.441Z [debug][Jellyfin Sync]: Updating existing title: Chief of War 2026-06-05T03:05:04.525Z [debug][Jellyfin Sync]: Updating existing title: Rick and Morty 2026-06-05T03:05:04.531Z [debug][Jellyfin Sync]: Updating existing title: See 2026-06-05T03:05:04.610Z [debug][Jellyfin Sync]: Updating existing title: Foundation 2026-06-05T03:05:04.713Z [debug][Jellyfin Sync]: Updating existing title: Last Week Tonight with John Oliver 2026-06-05T03:05:08.714Z [info][Jellyfin Sync]: Recently Added Scan Complete 2026-06-05T03:06:00.012Z [debug][Jobs]: Starting scheduled job: Download Sync 2026-06-05T03:06:00.163Z [debug][Download Tracker]: Found 10 item(s) in progress on Radarr server: Radarr 2026-06-05T03:06:18.580Z [info][API]: Found matching Jellyfin user; updating user with Jellyfin {"ip":"::ffff:192.168.1.xx","jellyfinUsername":"sparkbox"} One thing I noticed is that after I get logged out., the other apps no longer display the user name or password when I click on them. I need to refresh sparkbox browsing page to get them to be displayed again.
tomspark wrote:
That's a useful detail — it means your session is being dropped, not the app crashing. And your log is clean (just routine scheduled jobs), so Seerr itself is healthy; it's the login session not sticking after you sign in. The biggest clue is that it's rock-solid from your laptop but drops on the NAS — that's almost always about HOW you're reaching it. Two quick questions: 1. On the NAS, how do you open Seerr — typing the NAS IP with :5055, a domain name, Tailscale, or the Seerr button on the dashboard? 2. Is the address http:// or https://? That'll tell me why the session isn't persisting on that path. (And respect on the 7-months-offline prep — let's get this rock-solid for you before then.)
Marauders wrote:
I am opening seerr pretty much through the dashboard. So I can grab the password. I have punched in the NAS IP with :5055 as well. The address is http:// I am going to attempt to create another username on seerr before it kicks me Appreciate all the hustle and I hope I can help nail this down
tomspark wrote:
Helpful — so it's http, via the NAS (both the dashboard and direct :5055), and it boots you. Since it's fine on your laptop but not the NAS, something NAS-specific is invalidating the session. Two quick checks: 1. On the NAS, run: date — is that the exact correct date AND time (to the minute)? If the NAS clock is off, sessions can expire almost instantly, which is a classic 'logged out seconds after login.' 2. The log you grabbed caught a quiet moment (just scheduled jobs). Try to catch it RIGHT as it kicks you: log in, and the second it boots you, run sudo docker logs sb-seerr --tail 15 . The line at the exact kick is the one I need — I'm watching for an auth / 401 / 'unauthorized' line. Creating a 2nd user is a fine test too. Send me those two and we'll corner it.
Marauders wrote:
1. The date is off but I checked the VPN to see where it was and that time checks (mountain time). Bounced that off the time in the control panel in the nas itself and they are sync'd. 2. Ran the --tail 15 and got something similar as before. Marauders@DXP4800PLUS-857:~$ sudo docker logs sb-seerr --tail 15 2026-06-05T03:45:05.428Z [debug][Jellyfin Sync]: Updating existing title: Chief of War 2026-06-05T03:45:05.433Z [debug][Jellyfin Sync]: Updating existing title: Rooster Fighter 2026-06-05T03:45:05.445Z [debug][Jellyfin Sync]: Updating existing title: The Last of Us 2026-06-05T03:45:05.515Z [debug][Jellyfin Sync]: Updating existing title: Rick and Morty 2026-06-05T03:45:05.521Z [debug][Jellyfin Sync]: Updating existing title: See 2026-06-05T03:45:05.526Z [debug][Jellyfin Sync]: Updating existing title: Foundation 2026-06-05T03:45:05.616Z [debug][Jellyfin Sync]: Updating existing title: Last Week Tonight with John Oliver 2026-06-05T03:45:09.618Z [info][Jellyfin Sync]: Recently Added Scan Complete 2026-06-05T03:46:00.016Z [debug][Jobs]: Starting scheduled job: Download Sync 2026-06-05T03:46:00.351Z [debug][Download Tracker]: Found 10 item(s) in progress on Radarr server: Radarr 2026-06-05T03:47:00.017Z [debug][Jobs]: Starting scheduled job: Download Sync 2026-06-05T03:47:00.153Z [debug][Download Tracker]: Found 10 item(s) in progress on Radarr server: Radarr 2026-06-05T03:47:59.962Z [info][API]: Found matching Jellyfin user; updating user with Jellyfin {"ip":"::ffff:192.168.1.35","jellyfinUsername":"sparkbox"} 2026-06-05T03:48:00.002Z [debug][Jobs]: Starting scheduled job: Download Sync 2026-06-05T03:48:00.071Z [debug][Download Tracker]: Found 10 item(s) in progress on Radarr server: Radarr
Marauders wrote:
Booted me out again in incognito. Should have stated that I have tried several browers (chrome, firefox, waterfox) on windows, linux and android. So this was a good step. The moment it kicked me out, the network setting refreshed. It was extremely quick. Looking like on the status column i got a 403 forbidden GET scheme http host 192.168.1.xx:5055 filename /api/v1/auth/me Address 192.168.1.XX:5055 Status 403 Forbidden VersionHTTP/1.1 Transferred317 B (75 B size) Referrer Policystrict-origin-when-cross-origin DNS ResolutionSystem Connection keep-alive Content-Length 75 Content-Type application/json; charset=utf-8 Date Fri, 05 Jun 2026 04:00:16 GMT ETag W/"4b-5kinqevWTB3EAvzO01br5F3Ez9g" Keep-Alive timeout=5 X-Powered-By Express Accept application/json, text/plain, / Accept-Encoding gzip, deflate Accept-Language en-US,en;q=0.9 Connection keep-alive Cookie csrf=8a4a114cbf2b5f9d560e50c70d5c9dea92ae6c3c9215cf4a3e7dc161d36d09e4; connect.sid=s%3AHjuv2AbWJvbyj3kreMBu9LnKQlzYs1cc.egEDP8Qmvy1NTK%2BVnlpssf9Ale0qbuB4vhsenZQQ7Cc Host 192.168.1.xx:5055 Referer http://192.168.1.xx:5055/login Sec-GPC 1 User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0 Hopefully that helps
Marauders wrote:
So I was bouncing back in forth between chrome and firefox. Chrome seems to be stable enough for me to, as we speak, still be in the setting fiddling around. Firefox kicked me out almost immediately. Found CSRF protection in network and its already off.
Marauders wrote:
Both of those brought No Joy. Waterfox was also having the issues. I was sure that chrome was too, but it is still solid as I type this. Tomspark, SparkTeam, sudo god. Appreciate the troubleshooting. Hopefully this thread will help anyone in the future.
tomspark wrote:
Ha, appreciate that — and honestly you did the hard part by isolating it. Here's the takeaway for anyone who finds this thread later: Firefox-family browsers (Firefox, Waterfox) are strict about cookies on plain-http sites and will sometimes refuse to keep the session, which boots you right back to login. Chrome is more relaxed about it, which is why it's rock-solid for you. The proper cure is putting Seerr behind HTTPS (via SparkBox's proxy with a domain/cert, or over Tailscale) — that makes Firefox happy too. But since Chrome works perfectly, you're fully unblocked for your offline prep, so no rush on the https side unless you want Firefox back. Glad it's sorted, and thanks for the thorough troubleshooting!
Marauders wrote:
I think I might have to take that route. Something is still off. Chrome is having the same issue now (which is what i was experiencing before and was dumbfounded the other day when it was fine). Below is what I got from chrome hitting f12 during the logout. I did notice the time is off in chrome. Ill be offline for a while but hopefully this might be useful http://192.168.1.xx:5055/api/v1/auth/me Request Method GET Status Code 403 Forbidden Remote Address 192.168.1.xx:5055 Referrer Policy strict-origin-when-cross-origin connection keep-alive content-length 75 content-type application/json; charset=utf-8 date Sun, 07 Jun 2026 00:20:55 GMT etag W/"4b-5kinqevWTB3EAvzO01br5F3Ez9g" keep-alive timeout=5 x-powered-by Express accept application/json, text/plain, / accept-encoding gzip, deflate accept-language en-US,en;q=0.9 connection keep-alive cookie csrf=6251cf53484fb291e1e534345aed1adfa848a532051f0d0c7a84c67cd231b2ff; connect.sid=s%3AHZD52uLIvuIHVMJEwfYN7j88FsmTh9av.RBgvNGLHu93AXTRp1HIgfMBiGph2Xp9I6wH8A4d0glo host 192.168.1.xx:5055 referer http://192.168.1.xx:5055/login user-agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36
tomspark wrote:
This is the clue we needed, thanks. That 403 on the auth/me call means the server is rejecting your session, not the browser, so Firefox-vs-Chrome was a red herring all along. And the time being off is a big deal here: Seerr ties your login's validity to the clock, so if the NAS clock is wrong or drifting it can decide your fresh login already expired, which fits the 15-30 seconds exactly. So first thing when you're back: check the NAS date and time matches your phone, and that "set time automatically" is turned on in UGOS. Correct it, log into Seerr again, and see if it holds. If the clock turns out genuinely fine, then the durable cure is the HTTPS route we talked about. Reply when you get a chance and we'll close this out.
Marauders wrote:
Alright, NAS date and time matches my phone exactly. I was working on setting up wireguard and I didnt have the password. Well I realized that this is also a problem. Not that I couldnt log in because I dont have the password (future me problem). When I click on the link from the dashboard it, if toggle back to the sparkbox dashboard tab in the browser, and click on any app I get a "could not load services" error in the upper right hand corner. At this point, none of the services will prompt me a password when I click them until I refresh the dashboard and password back in to sparkbox. Ill have to work the tailscale angle to attempt to fix the first issue if they are not related. Hopefully I explained that well enough. System logs seem to be wiped on start up so its hard to capture exact what is going on.
tomspark wrote:
Thanks for testing the clock, that rules it out. And what you just described is actually the real culprit, and it's on us, not you. That "could not load services" plus having to refresh and log back in is the dashboard dropping your sign-in: on NAS storage it's failing to save your session properly, so the moment it re-checks, it's gone, which also lines up with the Seerr logouts you started with. It's a known issue we've flagged to fix, and no data's at risk. Don't worry about chasing the logs (they do get wiped on restart). The dashboard update should settle both.