In CORE, I’m pretty sure my SMB shares stayed connected indefinitely. In SCALE, they seem to drop after about a half hour of inactivity. Is that likely due to an idle timeout setting? How could one change it?
I’ve gotten closer to fixing it; maybe someone can help me across the finish line. I found the SMB configuration file at \etc\smb4.conf .
I also found that the parameter I need to change is deadtime, The number of minutes of inactivity before the connection is ended (unless they have a file open). The config file has a bunch of parameters, but no deadtime entry.
I can edit /etc/smb4.conf and add deadtime = 720 (12 hours) in the [global] section, but the file is overwritten when I restart SMB.
There is a file of the same name at /usr/local/etc/smb4.conf . It has no parameters in it. I can’t add deadtime; I get a read-only filesystem error.
Help!
You can make a bug report and we’ll get it fixed for next release.
3 Likes
Bug report: TrueNAS - Issues - iXsystems TrueNAS Jira
Define “SMB drop”…
Errors?
Default deadtime is already 10080 minutes (1 week). FreeNAS ages ago had a different default (15 minutes) in FreeNAS 11.2.
We removed the deadtime parameter in 11.3 (switching back to 1-week default).
commit c809ca6f8ec0221aa2bf41af09fbc926734e7c94
Author: Andrew <awalker@ixsystems.com>
Date: Mon Jan 6 16:04:25 2020 -0500
Remove dead timer to improve stability of some non-Windows SMB clients
In this case it was in response to MacOS client bug whereby if you closed lid on MacOS laptop after it had mounted a share and if samba scavenged the session before you resumed MacOS client, the client would hang requiring reboot.
No error, just a popup saying “Server connection interrupted”. Any windows that were showing share content just revert to showing a Network window with any available connections.
Well, this is bizarre. After rebooting the server and opening a share on the client, the window was still open the next day. I’ve rebooted many times before but no such luck.
The only persistent change I made is creating a file /etc/samba/smb.conf with the contents
[global]
deadtime = 720
Could that be getting read and effective?
No. It won’t be read or effective.
I’m seeing the same issue on my system. I’m running Scale v24.10.2, the clients are on Windows 10 or 11.
Interestingly, a directly opened share path as in
\\truenas\share\directory
does not vanish, while a mapped drive as in
X:\directory
closes after a while of non-access (it can be as little as about 10 minutes for me.) You can demonstrate by opening two Explorer windows next to each other and let them just sit there: After some time, the mapped one will have closed (Windows’ reaction when the path isn’t there any longer), while the “direct” one remains open.
If the window has closed, a immidiate reconnect (just open the window again and go back to the path) works without a hitch.
Also, I did not observe any network issues (such as failing PINGs) at the time.
Did you ever find a solution?
No.
I’m experiencing the same thing 150d described. My connections in applications reading files, like a Nuke read node, will randomly error out. Reloading the file restores it immediately.
I get the same behavior in windows explorer too, anything open on my mapped share will just close out.
Still investigating the cause.
TrueNAS-13.0-U6.7
Windows 11 clients
I may have stumbled upon something:
In my Windows Domain, the drive mappings are assigned by GPO (GPP to be exact.) In this policy, I had originally set the mode of each mapping to “Replace”. Since I changed this to “Update” I haven’t observed the disconnections any more.
Apparently, “Replace” causes the drive to periodically disconnect and reconnect on the client, whenever GPO is applied (routinely every 20 minutes or so), even if the setting hasn’t changed. Possibly this was handled differently with a real Windows server (“recover” active connections instead of dropping them), but Samba (as in TrueNAS) works differently. But that’s just a theory.
Hmm, I wonder if that has a macOS equivalent.