NFS share browsable only on Win10 client

[Cascadoo]

Hi Folks,

I created a NFS share on Freenas 11.3 following the example stated in the manual. I have 2 clients that I want connected to the share, an Ubuntu and Windows 10 Pro system.

The Ubuntu client can access the share, view, edit and execute without issue. The Windows 10 client connects successfully to the share and can browse to directories and files without issue but cannot execute or open any of the files. This is met with an "access is denied" to the file prompt on windows.

Freenas setup:

On the Windows 10 professional client, the NFS features were installed.

Created two DWORD entries, AnonymousUid & AnonymousGid at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default. These contain the nobody UID & GID, 65534.

Even with these entries Windows keeps connecting with UID=-2, GID=41502. I have tried connecting with the mount - anon option from windows cmd but the result is the same. *I had rebooted the client every time I made a change.

Code:

Local    Remote                                 Properties
-------------------------------------------------------------------------------
Z:       \\192.168.2.100\mnt\Storage\Mediaset   UID=-2, GID=415028
                                                rsize=131072, wsize=131072
                                                mount=soft, timeout=0.8
                                                retry=1, locking=yes
                                                fileaccess=755, lang=ANSI
                                                casesensitive=no
                                                sec=sys

Am I overlooking something simple?

 

[Cascadoo]

I noticed that even though I set the permissions to read-write-access (777) on GUI and select apply recursively it only applied to the parent folder for some reason. The permissions of the actual files and folders under the Mediaset folder still reflects 755. I know that you shouldn't make any manual changes but I did a chmod -R 777 on the parent folder to remedy this.

At that point I now start getting "the process cannot access the file because another process has locked a portion of the file" error on the windows client when trying to execute or open a file.

I then came across this post that helped remedy the file locking on the windows end:
https://www.ixsystems.com/community...ile-because-another-process-has-locked.12644/

Mounting this way with the no lock option resolved the problem:

Code:

C:\Users\Marlon>mount \\192.168.2.100\mnt\Storage\Mediaset Z: -o nolock
Z: is now successfully connected to \\192.168.2.100\mnt\Storage\Mediaset

Interestingly it still mounts with UID=-2, GID=415028 and file access as 755. I left the AnonymousGid & AnonymousUid dwords in the registry but it is still not mapping to the nobody user.

C:\Users\Marlon>mount

Code:

C:\Users\Marlon>mount

Local    Remote                                 Properties
-------------------------------------------------------------------------------
Z:       \\192.168.2.100\mnt\Storage\Mediaset   UID=-2, GID=415028
                                                rsize=131072, wsize=131072
                                                mount=soft, timeout=0.8
                                                retry=1, locking=no
                                                fileaccess=755, lang=ANSI
                                                casesensitive=no
                                                sec=sys

*Take note of the locking=no flag*

While probably not the best way to resolve this, the file content is not critical and access on this subnet is limited so this setup works for me for now at least.

 

[Cascadoo]

Does anyone know how to make NFS file locking=no persist after reboot on Windows 10? Even though it is mounted with "-o nolock" it reverts to yes after a reboot.

 

[Samuel Tai]

Does anyone know how to make NFS file locking=no persist after reboot on Windows 10? Even though it is mounted with "-o nolock" it reverts to yes after a reboot.

There doesn't appear to be an automated way via GPO, Registry keys, or PowerShell. Maybe you could try using the Steps Recorder?

Also, when you created your UID/GID DWORDs, did you enter them as decimal or hex, and restart the NFS client service afterwards?

 

[Cascadoo]

I entered the DWORDS values as decimal and restarted OS.

I tried testing it on windows 7 machine but it does the same thing connecting as a different user.

 

[Cascadoo]

Workaround for the moment....or possibly permanent fix , batch script in startup folder

Code:

umount Z:
mount \\192.168.2.100\mnt\Storage\Mediaset Z: -o nolock
exit