Firefox loses authentication on reload in TrueNAS SCALE 25.10.1 (tab duplicate works)

Hello,

I would like to report a reproducible authentication issue in
TrueNAS SCALE 25.10.1 that only affects Firefox.

Summary:
In Firefox, the TrueNAS WebUI loses authentication whenever a new
browser document context is created (reload, new tab, URL re-open).
The only case that works reliably is duplicating the existing tab.

Environment:

  • Product: TrueNAS SCALE
  • Version: 25.10.1
  • Browser affected: Firefox (clean profile, no extensions)
  • Browser not affected: Chromium / Edge
  • OS tested: Windows and Linux (CachyOS VM)

Steps to reproduce:

  1. Open Firefox
  2. Open the TrueNAS WebUI
  3. Log in successfully
  4. Do one of the following:
    • Press F5
    • Re-enter the URL in the address bar

Result:
The user is logged out or ends up in a non-authenticated UI state.

Expected:
The session should remain valid as long as the session cookie is valid.

Important observations:

  • Duplicating the browser tab works reliably
  • Reloading or opening the URL normally does not
  • Session cookies are sent correctly (verified via HAR)
  • No explicit logout request
  • No obvious 401/403 responses

What was tested / ruled out:

  • Clean Firefox profile and installation
  • Private browsing window
  • Firefox on multiple operating systems
  • Cookies allowed
  • Tracking protection disabled
  • All Firefox site exceptions tested (cookies, pop-ups, redirects, content blocking) — no effect
  • SameSite settings verified
  • Cache settings reset to defaults
  • No HTTPS interception or antivirus browser extensions
  • Hostname and IP tested
  • HAR files confirm cookies are present and sent correctly

Other web UIs are NOT affected:

  • Proxmox
  • OPNsense
  • Jellyfin
  • Portainer
  • Regular internet sites

This strongly suggests that in TrueNAS SCALE 25.10.x the WebUI
authentication is incorrectly bound to the SPA/WebSocket runtime
instead of being re-established from the session cookie on a cold page load.

HAR files are available if needed.

Thanks for looking into this.

Nothing?

Could someone with access to the bug reports please check on this and report back?
Is anyone even interested, or is this bug still being intentionally ignored?

Check this other thread. You even posted there in Dec 2025

Yes, but first there was not enough information about the tested environment, and the Jira ticket was marked as “Closed Without Changes.
It also seems that since no one is opening a new ticket or reopening the existing one, no one really cares.

That is why I created another topic with more information, hoping that someone will be able to open or reopen the bug report in Jira, because it is definitely not fixed at all.

I appreciate the enthusiasm, but if you look at the original ticket it was closed because there was no communication from the reporter for over a week after requesting a debug file and the closing comment even said it could be reopened if more information was provided.

There was nothing stopping that user from uploading a debug and restarting effort on that ticket or any other user from opening a new one, which appears to have already happened, since a fix to NAS-139491 was merged four days ago.

1 Like