Unfortunately, this did not resolve the issue. I also rebooted just to be sure.

I tried answering both yes and no to the PAM prompt.

I have attached a replacement samba package to fix a possible bug related to kernel oplock breaks. It can be installed by:
1. clone current boot environment (to have a backup)
2. run command /usr/local/libexec/disable-rootfs-protection
3. unzip attached replacement_samba.zip file
4. install truenas-samba_4.21.3+ix-1_amd64.deb via dpkg -i truenas-samba_4.21.3+ix-1_amd64.deb
5. restart SMB service

Let me know how it goes and I’ll refine the patchset accordingly.

Sorry for the delay, but my weekly scrub task kicked off and ran for 16 hours! Unfortunately, I don’t have any job history from prior to the “upgrade” but I don’t recall it taking that long before. I also see the drive temperatures no longer show up on the storage dashboard.

The issue is only occurring on multi-protocol shares. I don’t have any clients currently accessing it via NFS, but I do have a TrueNAS docker Jellyfin container with App group access. It may also be the kernel=oplocks=True parameter. When capturing traffic between Win11 client and TruenNAS SMB, at the 56 second mark I see an Oplock Break Notification and then the writing takes place. The prior 55 seconds is pretty much just stalled with Find, Create, and Close requests and responses. If there’s a way to privately share the wireshark capture, I am willing to do so.

The media share is accessed via SMB by Windows 11 clients, AppleTV Infuse application using SMB, Jellyfin apps on various devices, and Jellyfin is run from the TrueNAS docker library using host path and the App group is applied to the dataset ACL.

For testing, I created new datasets and shares named delete to test out various combinations.

delete - Multiprotocol share. Used identical custom ACL including modify for app.. Experienced same issue.

delete - test 2. Multiprotocol share. Removed the App group from ACL. Experienced same issue.

delete02 - Default share parameters. Used identical custom ACL including modify for App group. No issue.

delete02 - test2. Changed to Multiprotocol. Used identical custom ACL including modify for App group. Experienced the same issue.

delete03 - Default share parameters. Used default ACL and only added user jason with Full Control. No issue.

Does this only occur on shares that are concurrently in-use by other services (NFS, apps, etc)?

If I attempt to copy a new file into that SMB share using TeraCopy Pro or native File Explorer it copies fine. But, when copying a file there that already exists, TeraCopy will hang for 60 seconds before prompting me to skip or overwrite the existing file. File Explorer will typically prompt me to replace the existing file immediately, but will then hang for 60 seconds before actually performing the write operation.

I have also duplicated these results on another PC running the same version of Windows 11. On that PC I also used a different user account.