I’m not exactly where where to even start debugging but after upgrading to 25.04 whenever I browse any TrueNAS SMB share from a windows machine it will be fine for a minute or two and then just freeze up for a bit and come back and repeat. I’ve rebooted a couple times after in hopes that would clear it up but nothing. If I stream video or something it’s the same thing which I suspect has to do with it going over SMB as well at that being the root cause but not 100% sure which logs to even start with right now.
Does the share have the MULTI_PROTOCOL_NFS preset?
Yes it does, I wonder if that’s causing it.
Nope, I tried a SMB only share without that and same issue after a bit
Whenever this happens I see these in the smb logs:
[2025/04/18 14:31:21.991146, 1] …/…/source3/modules/vfs_ixnas.c:136(ixnas_get_native_dosmode)
ixnas_get_native_dosmode: rsync/filename: open() failed: Interrupted system call
[2025/04/18 14:31:22.162361, 1] …/…/source3/modules/vfs_ixnas.c:136(ixnas_get_native_dosmode)
ixnas_get_native_dosmode: rsync/filename: open() failed: Interrupted system call
What “purpose” did you have set, I had this exact issue after upgrading to 25.04 until I changed the purpose to “default share parameters”
1 Like
I had the same issue with 2 datasets: 1 was set to multiprotocol, the other just smb
Wasn’t able to find a solution, but I recreated them (with the same settings) and the new ones work fine - no idea why
1 Like
I just tried setting one to “default share parameters” and it still locked up sadly. The rest are sent to Multiprotocol though
So i was getting a similar issue, trying to play vids from my “completed” downloads folder, they would take 2minutes to start, but after reading this thread, deleting the share and creating a new “default parameter” one (and cycling SMB on/off) it worked. Sorry, not much help to OP, but just wanted to document that i also had something funky going on with shares on fangtooth
1 Like
I apparently forgot to restart the SMB service after changing the share purpose to default. I did that on all shares and stable so far!
2 Likes
I was running into the same thing after the upgrade. It was also causing substantial timeouts and pauses and freezes on windows computers when accessing the SMB shares. Indeed, switching a share to default share parameters and restarting smbd resolved it. However… what if I WANT it to be a multi-protocol share? How do I fix this while retaining my existing functionality and configuration?
1 Like
My guess is it is a bug related to RDMA as when I was having the issue I saw the following error every time the disconnect would happen in the windows smbclient event log:
A network connection was disconnected.
Frequent, unexpected disconnects when using an RDMA over Converged Ethernet (RoCE) adapter may indicate a network misconfiguration.
This event corresponded time wise with the following event in the Truenas /var/log/samba4/log.smbd:
ixnas_get_native_dosmode: rsync/filename: open() failed: Interrupted system call
So short answer is I don’t think there is a configuration based fix we can do at this time. Hopefully someone at IXSystems will tell me I am wrong. 
No. The problem is interactions between local processes and kernel oplocks. In at least the case I looked at there was a local application immediately triggering kernel oplock breaks. Probably for 25.04.0 we’ll just disable oplocks entirely for this share type (i.e. no client-side caching).
3 Likes
Thank you @awalkerix for commenting!
interesting the fix mentioned is to return to default share parameters…that’s going to be interesting once i finish my replication. if you have to go to default parameters…which is not how i run my shares…is a big regression…i am currently troubleshooting a big performance regression in smb and iscsi myself.
We discovered a configuration issue with kernel oplocks when people have a mixture of shares that are NFS compatibility and non compatibility that basically requires disabling SMB2 leases globally if shares are configured for mixed-mode NFS access. This of course reduces ability of clients to do client-side caching and has a performance impact in some situations.
i am not using nfs…the share with my air works fine it is the windows shares that have serious performance regressions. iscsi is also severely impacted. everything was working fine until 25.04. i tried a ticket but it was summarily closed basically saying it’s on your end…just like the team did to my enterprise clients for multiple years…
1 Like
The solution repaired my problem. Thank you!
i tired that to no avail…so i am reverting back with a clean install of EE to see if that fixes things.
I tires this as well over the past couple of days to no avail…you can follow my adventures here: 25.04 performance problems after upgrade
So does this mean those of us who are cautious should wait for a .1 release?