Report a Bug, attach Debug Dump and post the ticket number or a link in the forum thread so others can follow progress.
1 Like
After updating from TrueNAS-SCALE-26.0.0-BETA.1 to BETA.2, TrueNAS is no longer visible in the Windows 11 Pro Network tab (the one showing other computers connected to the same local network).
SMB shares were enabled and configured ā no changes were made to SMB settings during or after the update. The shares themselves were also not visible in the Network tab.
The only workaround that works is manually mapping drives via UNC path (e.g. \TRUENAS\share) ā access works fine this way, but automatic discovery via Network tab is broken.
After rolling back to TrueNAS-SCALE-26.0.0-BETA.1, everything works correctly again ā TrueNAS and all SMB shares are visible in the Windows 11 Network tab without any changes on the Windows side.
Environment:
- TrueNAS SCALE 26.0.0-BETA.2 (broken) ā rolled back to 26.0.0-BETA.1 (working)
- Windows 11 Pro client
- SMB shares enabled, no config changes
- Network discovery works for all other devices on the same subnet
Possibly related to WS-Discovery (wsdd) changes in BETA.2.
Yes. There is a ticket about this (NAS-141440). Will be fixed in next pre-release build.
In my case, similar error type, but different problem:
Error Name: EINVAL Error Code: 22 Reason: internal error: guest failed to start: Failure in libvirt_lxc startup: cannot find init path ā/sbin/initā
solved by manually mounting the root filesystem:
zfs mount main/.truenas_containers/containers/Debian13`
magically fixed everything. reported as bug.
@stk @Brezlord
NAS-141523
āThank you for the report! We have reason to believe this issue has already been fixed, but the release containing the fix has not been published yet. Please retry on the next stable release once it becomes available, and reopen this ticket if the problem persists.ā
Not sure if next stable release refers to the next Beta, RC or full release of 26
The other ticket is marked to be included in RC.1
great that you found it. it was a major surprise for sure!
After upgrading to TrueNAS SCALE 26.0.0-BETA.2 i noticed a pretty annoying issue:
Itās no longer possible to use a bridge as my primary network interface. Previously (24.04 through to 25.10.4) I had my physical interface (connected, unconfigured) as a member of br0 and then DHCP and IPv6 auto configuration on br0. br0 was also used as the parent NIC for VMs so they can share the fast link.
After switching to 26-Beta.2 the UI complained about the default gateway 10.11.1.1 ānot being reachableā, despite the br0 interface still getting the 10.11.1.149 IP via DHCP and a ping on the CLI to 10.11.1.1 being successful. Internet was also working fine. This is a flat 10.11.1.1/24 network, so it seems like some kind of middleware validation issue, because the underlying system is working as expected. The middleware just doesnāt think it does.
This in turn caused apps to stop working (the app service doesnāt even initialize, it fails with ādefault interface could not be determinedā). Did anyone else have similar issues? I had to delete the bridge and set the physical interface as DHCP + IPv6 autoconf, but that in turn breaks VM <> Host communication which I had to circumvent by manually adding routes to bounce connections via the gateway (ip route replace 10.11.1.16/29 via 10.11.1.1 dev enp65s0 and the same in reverse)ā¦
When I have another night Iāll break the system again to get a debug file, but for now Iām interested whether anyone else has this issue? Having a bridge as the primary interface canāt be that uncommon, right?
1 Like
Having a Web Shell Issue (SSH and console ok)
When i connect to the web console just see a white flashing cursor.
The websocket in the browser F12 network trace shows as pending despite there being a cursor present, no console errors
AI summary of what i found
26.0.0-BETA.2: Web Shell hangs after successful authentication. Terminal stays blank, 0 bytes received. Traced: nginx upgrades the websocket (101) and proxies to /_shell/ (127.0.0.1:6000); webshell_app.py authenticates successfully (audit log shows WEBSHELL_AUTHENTICATION success:true for the account); but no shell output ever reaches the client and nginx logs recv() failed (104: Connection reset by peer) while proxying upgraded connection.
All post-auth primitives verified working standalone: os.forkpty() succeeds, /usr/bin/login present, user homedir valid, user.get_user_obj resolves. Failure appears to be in ShellWorkerThreadās reader/writer/websocket-send interaction or the {"msg":"connected"} handshake, not in any individual operation. Persists across reboot and systemctl restart middlewared. SSH works normally. Separately observed: devpts mounted with ptmxmode=000 (/dev/pts/ptmx mode 0000) does not appear to be the cause since forkpty succeeds, but flagging as a likely-unintended default.
Had no issue on BETA1
Known issue?
toggle ws-discover and netbios off, apply, and then back on, and apply - this made it reappear on my systems
1 Like
Testing Beta 2 also and have a W11 VM for testing and do not see this.
Similar networking setup (br1 has a static IP) and VM uses br1 and also has a static ip.
Guessing a networking/netmask issue somewhere?
Try setting a static IP on br0 (should not make a difference, but in case you have dhcp issues etc.).
As mentioned earlier there is a known bug here that is being addressed in RC.1.
Iām curious about that bug.
Please post bug number or details.
It was a regression in discovery services caused by redesigning how service announcements work on truenas. Note that this isnāt actually part of the SMB protocol or networking. Itās about WS-discovery announcements on the wire and protocol behavior. The most likely people to see the bug are home users who have enabled network browsing in Windows. In business environments people almost always use DNS / AD for resolving servers.
1 Like
i know, i was giving them a workaround that seems to resolve it at least until the next reboot. (it does. for me)
my bigger issue is the web console shell not workingā¦.
I obviously canāt reproduce in a lab. Probably an actual pcap could give some info if youāve filed a ticket. If I were to hazard a guess maybe one side or the other (browser or server) is hanging long enough for the websocket session to drop / fail. You may have some network instability that we donāt see in our lab environment. SSH and a lot of web things can be tolerant of instability, but once you layer terminal over websocket from browser things can be more iffy. File a ticket if you havenāt yet.
1 Like
Thanks. Did check that bug earlier but couldnāt see how network discovery would affect IP connectivity?
I found the main issue: It was STP. there was an exact 30 second delay before dhcp completed, just enough for the rest of the system to start up, which in turn caused the apps service to get confused.
Adding a PRE Init command with ip link set br0 type bridge stp_state 0 restores the previous behaviour.
The broader issue here appears to be the Apps service specifically being pretty fragile. There was a prior issue with a fixed timeout that was too short and required manually (re)starting the apps service if it didnāt initialize at first.
This seems like a similar category where it doesnāt fully wait for the network to be up, tries to start, fails and just never does anything again. I was able to āfixā the Apps service on a ābrokenā system by unsetting and setting the pool again, which (re)started the apps service and everything worked fine.
But for now getting rid of the STP delay also works. In the long term maybe a more robust restart/retry logic for the apps service might be worth a considerationā¦
2 Likes
nothing to do with the network - as per my op the shell was closing immediately on the host, ngix and middleware was opening the socket just fine
finally tracked it down - itās an issue when AD is configured
logged here Jira
seems possibly PAM related, this is the journal entry from the open to the close, so assume this is PAM releated wrt AD
Jun 29 23:28:55 truenas1 ed[2112]: pam_unix(truenas-unix:session): session opened for user root(uid=0) by (uid=0)
Jun 29 23:28:55 truenas1 ed[2112]: pam_truenas(truenas-unix:session): parsing username: root [pam_truenas_ctx.c:61]
Jun 29 23:28:55 truenas1 ed[2112]: pam_truenas(truenas-unix:session): root: username canonicalized to root with dbid: 0 [pam_truenas_ctx.c:92]
Jun 29 23:28:55 truenas1 ed[2112]: pam_truenas(truenas-unix:session): Set PAM_USER to: root [pam_truenas_ctx.c:193]
Jun 29 23:28:55 truenas1 ed[2112]: pam_truenas(truenas-unix:session): [pamh: 0x7efffc03b390] ENTER: pam_sm_open_session
[pam_truenas.c:260]
Jun 29 23:28:55 truenas1 ed[2112]: pam_truenas(truenas-unix:session): Session 02af68c3-1bfb-4ab3-afe4-86c0fb2f702b:2112 stored in keyring (key_id=894775588) [kr_session.c:68]
Jun 29 23:28:55 truenas1 ed[2112]: pam_truenas(truenas-unix:session): [pamh: 0x7efffc03b390] LEAVE: pam_sm_open_session
[pam_truenas.c:290]
Jun 29 23:28:55 truenas1 ed[2112]: pam_unix(truenas-unix:session): session closed for user root
Jun 29 23:28:55 truenas1 ed[2112]: pam_truenas(truenas-unix:session): [pamh: 0x7efffc03b390] ENTER: pam_sm_close_session
[pam_truenas.c:324]
Jun 29 23:28:55 truenas1 ed[2112]: pam_truenas(truenas-unix:session): Session 02af68c3-1bfb-4ab3-afe4-86c0fb2f702b revoked from keyring [kr_session.c:108]
Jun 29 23:28:55 truenas1 ed[2112]: pam_truenas(truenas-unix:session): [pamh: 0x7efffc03b390] LEAVE: pam_sm_close_session
[pam_truenas.c:334]
note my AD is 100% healthy according to UI
i ran these and all showed healthy
- wbinfo -t
- wbinfo -P
- wbinfo --online-status
- time id truenas_admin
- time getent group builtin_administrators
- time wbinfo -u | head
Great finding. I may try to reproduce myself as Iām using static IP address on the bridge.
Best practice is to always set static IP addresses for key machines/services.
But yes, TN does not seem very smart when starting services/processes that require network connectivity.
Ex. I sleep my secondary/thertiary TN servers (rtcwake -m mem), and when they āwakeā up, the NTP service sends an alert that it could not connect to ANY NTP servers, not even the one running in the local router, on same network.
I understand they want to bring everything up as fast as possible, but a basic check for the IP stack status or a simple ping to the default router could do.
(I understand this is not a āsupportedā configuration, but we are just talking about service restarts after going to sleep, just a Linux feature).