Subscribe

NFS share not able to mount on windows 2008

I 've a NAS export with below permissions. and trying to mount on windows server..I was able to mount but unable to access it.

What are the options to be set at windows server end or at vserver end to fix this problem.

 

====

qtree show -vserver bnsf_vs_nfs_01 -volume l122446_bnsf_vol01 -qtree data

                      Vserver Name: bnsf_vs_nfs_01
                       Volume Name: l122446_bnsf_vol01
                        Qtree Name: data
  Actual (Non-Junction) Qtree Path: /vol/l122446_bnsf_vol01/data
                    Security Style: unix
                       Oplock Mode: enable
                  Unix Permissions: ---rwxr-xr-x
                          Qtree Id: 1
                      Qtree Status: normal
                     Export Policy: l122446waps1026_27_67_73_m222445waps1026-29
        Is Export Policy Inherited: false

Re: NFS share not able to mount on windows 2008

Hi 

Refer KB How to perform NFS Mounts with Windows hosts

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

Re: NFS share not able to mount on windows 2008

As we have been sharing NFS for windows servers from 8.3.x (shared CDOT arrays) but when it comes to 8.2.x ( BNSF CDOT) there is bug and here is the resolution for similar future requests of BNSF(8.2.3P1) until this is upgraded.

 

NFS share exports to done as defined by us.

For 8.2.x releases, For all mounts from Windows NFS clients, we require the prefix ROOT-path

mount \\<data-ip-address>\ROOT-path\<junction-path> <drive_letter>

 

cmd on windows server:

mount \\63.241.60.8\ROOT-path\l122446_bnsf_vol01\data x:

 

Notes: 'ROOT-path' is recognized by the Data ONTAP NFS server as a special mount request from the Windows NFS client and the server returns '/ROOT-path' in response to EXPORT RPC call. Since 'ROOT-path' is a valid share name for the Windows NFS client, all NFS path-based operations work correctly.

 

And saw that we were able to create new files/folders, as well as rename them as we expected.

 

BUG Details: http://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=921243