Was encoding a video file the other day, and it suddenly ground to a halt and was stuck at 81%. No errors, it never failed, it kept chugging along as far as I could tell but never moved past 81%. I was also downloading a file, and the program doing the download eventually simply stopped responding, causing a chain reaction of non-responses and forcing me to reboot. Now, I can’t do anything with the NAS at all, effectively: it takes half an hour to open a txt file, 15 minutes to open a folder, etc etc. Abysmally, unusably slow.
I’m running a media server off it, and that continues to work just fine on my NVIDIA Shield. I can watch 4K video with no problems whatsoever. I can’t even open a video file on my desktop.
My laptop, too, can access the NAS just fine, navigate through folders, open files, etc etc. No problems there.
Even from the desktop, I can navigate through my media server via my web browser, view and update metadata, and so forth. I also successfully updated the NAS from Angelfish to Dragonfish, from my desktop web browser, with no dramas.
Not sure what’s going on here. Both PCs are Windows 10. The laptop is WiFi, the desktop is ethernet, the Shield is powerline.
When did this begin? After you upgraded to Dragonfish?
What are your system specs and full TrueNAS version?
To be clear, this only affects a single computer? No other computer, whether Windows or Linux, is affected by accessing the SMB share?
If you bypass Windows File Explorer, such as using Google Chrome or Firefox to browse the SMB share, does it connect and navigate fast through the folders?[1]
EDIT: I see you might have already ruled this out, unless you meant something else?
You can type file://ip.ad.dre.ss/sharename into the address bar of the web browser to connect to and navigate the SMB share. It will only work after you’ve authenticated successfully (username/password) with Windows File Explorer, first.↩︎
When did this begin? After you upgraded to Dragonfish?
No. A few days ago. I was adding movies to my server but otherwise nothing changed. I did the updates (which also served as NAS reboots) after the issues started.
What are your system specs and full TrueNAS version?
It’s now 24.04.2, not sure what it was before. Per the dashboard, CPU is a 12th-gen Intel Core i3-12100 and there’s 31.1GiB of RAM available. Two pools, a two-wide mirror and a four-wide RAIDZ2, all 20TB WD Reds.
To be clear, this only affects a single computer? No other computer, whether Windows or Linux, is affected by accessing the SMB share?
It only affects one of my two computers. Whether the good computer or the bad computer is an outlier, I cannot say.
I see you might have already ruled this out, unless you meant something else?
I’m running Emby media server, I can go to Emby’s web GUI and navigate around just fine.
If you bypass Windows File Explorer, such as using Google Chrome or Firefox to browse the SMB share, does it connect and navigate fast through the folders?
Either I’ve typed the wrong thing or it’s not working. I’ve got a spinning circle in the tab, indicating loading, but nothing else is happening, I still see the ‘new tab’ page. It’s been a couple of minutes.
Interesting. I would leave this for a while, and see if it eventually connects. This will rule out Windows File Explorer (at least the application itself.) Because it should either instantly connect or immediately give you an error (if you hadn’t already authenticated with File Explorer first.)
Just tried it in Windows Explorer on the laptop and got asked to authenticate. I now have instant access via the web browser. So it’s possible I just haven’t authenticated on the IP via Windows Explorer, but that’s going to take several minutes to double check.
This narrows it down to the problematic computer, and exonerates Windows File Explorer itself. (It also assumes the issue is not server-side, but this is still a possibility.)
You can check the logfile (/var/log/samba4/log.smbd) on the server to see if it clues you into anything. (The name and path might differ between Core and SCALE.)
The same can be done on the Windows client, though I’m not sure what log / event history to read. (Windows “logs” are founder under the “Event Viewer” application.)
EDIT: Possibly under Event Viewer → Applications and Services → Microsoft → Windows → SMB Client
EDIT: Another thing to consider is anti-malware software. You might want to temporarily disable any realtime protection, and try again.
You can check the logfile (/var/log/samba4/log.smbd) on the server
Interesting…connected with WinSCP to go find the log and I can browse through the mnt folder just fine. The log is just “lpcfg_do_global_parameter: WARNING: The “syslog only” option is deprecated” over and over and over again, ad nauseam. I’ve scrolled through a bit, and cannot find a single line in the entire 3000-line file that isn’t that.
Another thing to consider is anti-malware software. You might want to temporarily disable any realtime protection, and try again.
Lots of warnings and errors under Connectivity, all pointing to my other NAS…which it turns out is also suffering the same issue.
Lots of these:
A network connection was disconnected.
Instance name: \Device\LanmanRedirector
Server name: [ServerName]
Server address: 192.168.0.2:445
Connection type: Wsk
InterfaceId: 17
Guidance:
This indicates that the client’s connection to the server was disconnected.
Frequent, unexpected disconnects when using an RDMA over Converged Ethernet (RoCE) adapter may indicate a network misconfiguration. RoCE requires Priority Flow Control (PFC) to be configured for every host, switch and router on the RoCE network. Failure to properly configure PFC will cause packet loss, frequent disconnects and poor performance.
Digging down further, there’s a few of those relating to my TrueNAS too. Under Security, there’s a lot of “A process has requested access to an object, but has not been granted those access rights” relating to the TrueNAS as well.
This might be something that @awalkerix is more familiar with, however it doesn’t appear to be a TrueNAS issue anymore, let alone an exclusive server-side issue.
One last thing to try (to rule out Windows) is to boot into a live Linux USB, such as Ubuntu, and see if you can quickly connect to the SMB share.
If it connects quickly, with no obvious problems, then this can be narrowed down to Windows + the client, rather than a general “hardware issue”.
As it stands now, this could be a combination of “SMB + Windows + that specific computer”. (Emby’s UI frontend and WinSCP are not SMB-related.)
It’s still in the air if “SMB + not Windows + that specific computer” will also reproduce the same problem.
If that’s the case, we might narrow it down to just “SMB on this computer”, rather than “something’s misconfigured in Windows to trigger this problem.”
In other words, if connecting to the SMB shares works normally under Ubuntu, then it’s likely that Windows (or a configuration in Windows) is the underlying problem for that specific computer.
