Have noticed that the web gui appears to randomly “disconnect”, will show the “attempting to connect” page for several seconds after which it shows the login page. This seems to occur only when logged out, on the login page; do not recall this occurring when I’m logged in and working.
Only the gui is affected. I have ssh enabled, when the gui is “disconnected” - still logged into ssh and can run commands. Shares are still accessible when gui is disconnected; in fact have had several over 20TB file copies going to shares - gui is disconnected but copies to shares were not affected.
I’m using a Mellanox mcx311a-xcat card for 10G networking. Have tried 3 different cards (have 3 different mcx311a-xcat cards), have tried 3 different SFPs (a generic optical 10G, 10G SFP to RJ45, and a Cisco optical 10G). tried different cables (both Cat6 and optical fiber). Tried different ports on switch, different slots for the card. Have even tried with a different motherboard/cpu.
It’s not a huge deal exactly, shares are up, apps are also unaffected. But is extremely annoying. Have had to wait for gui to become available countless time; several times had the disconnect when I was half way through entering my password. So the whole login gets reset, and have to wait for it to become available.
Running clean installs of TrueNAS SCALE 24.10.2
Hi and welcome to the forums.
Yes I have also experienced this, seems like a periodic refresh and as you say can become rather annoying when halfway through entering your password.
Why not raise a bug ticket clicking at the top of the page and even link this thread and let’s see if many others experience this.
I had the same issue, and spent a while this morning looking into it. Thought I’d leave an explanation here so the next people to hit this thread from google can save the time investigating.
Basically, this is caused by the login screen establishing a websocket connection to the TrueNAS box, but doing nothing with it. Because it’s idle, it gets auto-closed by nginx after 60s (the default proxy_read_timeout) causing the frontend to error out and reload.
You can workaround it by increasing the proxy_read_timeout in your nginx.conf to something larger, but it’s only kicking the can down the road, and I believe changes to that file are often overwritten anyway. Really the fix is for the login screen to either not open the socket in the first place, or to send a periodic heartbeat to keep it alive. But, given how minor the impact is (it really does just mean your login screen refreshes every 60s - AFAICT everything else on the box is a-okay), I’d be surprised if anyone could justify devoting a lot of time to fixing it (without wanting to speak for the development team, of course!).
1 Like
If you’ve found a reproducible cause for this, I’d suggest submitting a bug report and letting the devs decide if they can justify fixing it.
