Subscribe

Problem with very simple NFS mount on Windows 2008

Hi folks -- this is very confusing, and hopefully someone can share some light....


I have a couple volumes on my NetApp that I export very simply:

vol/files -sec=sys,rw,root=10.10.0.0/16

vol/files1 -sec=sys,rw,root=10.10.0.0/16

etc

All these have the same default QTREE (unix) value.  All can be mounted just fine on Linux systems.

However on a Windows 2008 server in my environment, I can only write to *one* of the volumes, even though they appear identical to me in every way on the Filer!

Here's my mount command on the Windows command line (10.10.20.170 is the ip of the filer)

C:> mount -o mtype=soft \\10.10.20.170\vol\files X:  < ----   works just fine

C:> mount -o mtype=soft \\10.10.20.170\vol\files1 Y:  <---- mounts, but cannot write!

So odd!  Thanks

Re: Problem with very simple NFS mount on Windows 2008

It sounds more like a permissions issue to me.

It's user name mapping most likely... make sure to check that box on install.  Windows won't be able to mount until you map the windows user to root (default only allows root to mount).

Re: Problem with very simple NFS mount on Windows 2008

vol/files1 -sec=sys,rw=root=10.10.0.0/16

You may need to fix the "rw=root=" portion.  Maybe put rw=10.10.0.0/16,root=10.10.0.0/16

Just a guess though.

Re: Problem with very simple NFS mount on Windows 2008

Sorry, wduval02 -- that's a typo (man I *hate* doing that, when I'm asking for technical help). Both volumes are exported in the same way:

-sec=sys,rw,root=10.10.0.0/16

So I looked at this a little more and now am even more confused. I mapped both volumes as drives "X:" and "Y:"  If I right-click and look at 'properties' the volume I can write to has a UID of 2002 and a GID of 2001 (screen shot below).  But the volume that I can't write to has a UID / GID of 0.  If I try to change this value, when I hit 'apply' I get "Access Denied."  This is very strange. What or who set the UID/GID of 2002 2001? Someone on a linux client?

Re: Problem with very simple NFS mount on Windows 2008

The Identity Management for UNIX Active Directory schema extension includes UNIX user identifier (UID) and group identifier (GID) fields. This enables Server for NFS and Client for NFS to look up Windows-to-UNIX user account mappings directly from Active Directory Domain Services. Identity Management for UNIX simplifies Windows-to-UNIX user account mapping management in Active Directory Domain Services.

Mapping (through either Active Directory Lookup or User Name Mapping) the UNIX user root (UID 0) to the Windows user Administrator—and also, mapping the group to which the root belongs to the Windows group Administrators.

By default, Server for NFS does not allow anonymous users to access a shared directory. When you share a directory, you can allow anonymous access to the directory and you can change the default anonymous UID and GID values to the UID and GID of any valid UNIX user and group accounts. If you change the anonymous UID and anonymous GID for a shared resource, those values will be used when reporting the owner of a file owned by a Windows user which is not mapped to UNIX user, even if anonymous access is not allowed.

To allow anonymous access to an NFS share using the Windows interface

  1. Open Windows Explorer: click Start, point to Programs or All Programs, point to Accessories, and then click Windows Explorer.
  2. In the details pane, right-click the shared directory you want to manage.
  3. Click Sharing.
  4. Click NFS Sharing.
  5. Select Allow anonymous access.
  6. To specify a nondefault value for the anonymous user identifier (UID) or anonymous group identifier (GID), type the value in theAnonymous UID or Anonymous GID box.
  7. Click Apply.

====================================================================================================================================

Users of client computers can use the chmod utility to set the setuid (set-user-identifier-on-execution), setgid (set-group-identifier-on-execution), and sticky file mode bits on files or directories that are stored on an NTFS file system partition and shared through Server for NFS. When the file or directory is subsequently accessed by a UNIX-based client, the standard semantics for these bits will apply.

Changing setuid and setgid behavior

Use the following procedure to change the behavior of the setuid and setgid bits:To change setuid and setgid behavior

  1. Open Registry Editor.
  2. Set the following registry key:HKEY_Local_Machine\System\CurrentControlSet\Services\NfsSvr\Parameters\SafeSetUidGidBits = (DWORD)
    • A value of 1 causes safer setuid and setgid behavior.

    • A value of 0 causes the standard UNIX behavior.

Re: Problem with very simple NFS mount on Windows 2008

Thank you Ravi -- that's good information.

I tracked the problem down -- at one point the volume that I could write to had been mounted on a Linux system and someone had down a chown/chgrp to it, assigned the UID/GID of 2001/2003, etc., and 777 permissions, recursively.

Re: Problem with very simple NFS mount on Windows 2008

Cool, way to go!

Re: Problem with very simple NFS mount on Windows 2008

Hi All,

 

I have created one NFS export in CDOT Array. and exported to Client subnet. i am able to ping the ip from windows client mechins. when itry to mount the that nfs export in windows server 2008 r2. i am getting network-53 error. Can anyone suggest me. how can i proceed with this.

 

 

Thanks & Regards,

RaviTeja

Re: Problem with very simple NFS mount on Windows 2008

C:\Users\Administrator>net use S: 192.168.11.211:\Default_Mount_CIFS
System error 67 has occurred.

The network name cannot be found.

Re: Problem with very simple NFS mount on Windows 2008

Hi,

For network -53 error try the following:

Review the used ports by running the windows command rpcinfo – p

VSM has this option for NFS:
 
[-mount-rootonly {enabled|disabled}] - NFS Mount Root Only
 
This optional parameter specifies whether the Vserver allows MOUNT protocol calls only from privileged ports (port numbers less than 1024).        
The default setting is enabled. Hence, the system allows MOUNT protocol calls only from privileged ports (port numbers less than 1024).
Windows Services for UNIX can use ports other than 2049.

 

Thans,

Renifa

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