File copy attempts falsely locked on NFS shares accessed from Windows client [Reopened ticket]

This is a re-opening of ticket NAS-104346, as instructed by Caleb St. John .

Problem:

When a FreeNAS NFS share is mounted on a Windows client with file lock enabled, copying any file onto the share (whether new or overwriting) always results in an error: "0x80070021: The process cannot access the file because another process has locked a portion of the file."

Steps to reproduce:

Create an NFS share on FreeNAS. (Example path: " /mnt/Pool/NFS_Share ")
Set mapall user to "root", and mapall group to "wheel". (All other NFS settings under "Services > NFS" and " Shares > NFS " were tested to be inconsequential.)
On a Windows 2016/2019 Server or Windows 10 Enterprise system with "Client for NFS" installed, connect to the share using the following command:

mount -o anon,fileaccess=7,mtype=hard \\IP.ADDR\mnt\Pool\NFS_Share *

The share will mount successfully. Next, via Windows Explorer, attempt to copy any file (such as a random DOC or TXT file on the desktop of the PC) to the mounted NFS drive (mounted as Z: ).

Windows Explorer presents the following alert:

The destination already has a file named "FILENAME.DOC" **

Click "Replace the file in the destination"
Windows will present the following error:

" An unexpected error is keeping you from copying the file. If you continue to receive this error, you can use the error code to search for help with this problem. "
" Error 0x80070021: The process cannot access the file because another process has locked a portion of the file. "

Click Cancel. Then, click "Refresh" on the Z: window in Explorer. A file matching the same filename as the attempted file will be present, but it will contain no data (0 Kb). This file can be moved or deleted, but the contents cannot be altered.

Workaround:

A workaround is possible by disabling file locking by adding "nolock" to the mount command, as shown below:

mount -o nolock ,anon,fileaccess=7,mtype=hard \\IP.ADDR\mnt\Pool\NFS_Share *

The nolock workaround unfortunately is not desirable in my particular use case.

Expected behavior:

When an NFS share is mounted on a Windows client without the workaround, copying files to the share should not result in an error (except and unless it is legitimately an attempt to overwrite a file in use by another process).

Further testing:

I created an NFS share on an Ubuntu 18.04.3 system and mounted it on Windows using the same methods described above. The share behaved as expected, leading me to presume that the problem is on the FreeNAS side rather than the Windows client.

Problem originally verified on: FreeNAS 11.2-U7 through TrueNAS 12-RELEASE.

I'm willing to test with the Nightlies if requested. Let me know if there's anything you'd like me to try.