Services for UNIX - Interoperability : Client for NFS

Using DFS for Centralized Access to Multiple NFS Servers

Ashish — Fri, 11 Sep 2009 22:28:00 GMT

Using DFS for Centralized Access to Multiple NFS Servers Lately, we have seen customers who are trying to utilize DFS to publish NFS shares from a single DFS server to centralize the access for the clients. This has several benefits. It removes the problem...(read more)

AD Lookup with ADAM/ADLDS

Ashish — Sat, 11 Jul 2009 01:17:00 GMT

AD Lookup with ADAM/ADLDS With removal of UNM in Vista/W2K8, it became really problematic to map users in non-AD environments to use with Vista/LH NFS Servers and Clients. For client, a workaround was discovered which was essentially a registry tweak...(read more)

Can I Set Up User Name Mapping in Windows Vista?

Ashish — Fri, 27 Mar 2009 23:01:00 GMT

Can I Set Up User Name Mapping in Windows Vista? Unfortunately, no if you don't have a SFU 3.5 or W2K3 R2 machines on the network that is running User Name Mapping service. This has been a major disappointment with NFS deployments using Windows Vista....(read more)

NFS and SUA in Windows 7

Ashish — Fri, 23 Jan 2009 22:48:00 GMT

NFS and SUA in Windows 7 Finally, the Windows 7 beta is released to the public and we can now experience it ourselves. The PSS people in Microsoft are always excited to try their hands on the latest betas and Windows 7 is not an exception. The first thing...(read more)

Limitation with Active Directory Lookup feature in Microsoft Services for NFS

Ashish — Tue, 16 Dec 2008 01:25:00 GMT

Limitation with Active Directory Lookup feature in Microsoft Services for NFS The Active Directory Lookup feature that was introduced with Windows Server 2003 R2. This feature greatly simplifies the UNIX identity information management but has its own...(read more)

Set up Services for Network File System in Windows Server 2008

Ashish — Tue, 16 Dec 2008 01:03:00 GMT

Set up Services for Network File System in Windows Server 2008 The Microsoft Services for NFS continues to be the part of the operating system in Windows Server 2008 and seems we will see more improvements when Windows Server 2008 R2 is released. In Windows...(read more)

All (well, almost) about Client for NFS - Configuration and Performance

Ashish — Mon, 14 Apr 2008 08:42:00 GMT

All (well, almost) about Client for NFS - Configuration and Performance

I was looking at the referrals this blog gets and I noticed that a lot of times people look for information on Client for NFS in Services for UNIX, Windows Server 2003 R2 or in Windows Vista and come to this blog, but I don't really have much useful information on installation, configuration and performance on Client for NFS. Now, that will not be the case.

I have received requests to put together something about Client for NFS since there doesn't seem to be a detailed single document which talks about it. There are KB articles which cover installation and configuration of Client for NFS. There are also some of them about issues and registry settings to help optimize the settings for CNFS.

Since it has also been a long time I have spent time on this blog, I guess it's high time I talk about Client for NFS and add some value to my blog.

Client for NFS is a very important offering from Microsoft for small and big enterprises to integrate their Windows systems with existing UNIX based environment. It now comes with RFC2307 support as well. It's one of the most simple component among Services for UNIX components. Client for NFS doesn't really ask for any configuration/restarts in most of the installations and offers true out-of-the-box NFS connectivity. You can see in the following screen shot how Client for NFS can be added/removed if Services for UNIX software is already installed -

In Windows Server 2003 R2, you can find CNFS listed in "Microsoft Services for NFS" under "Other File and Print Services" -

And, on a Windows Vista Enterprise/Ultimate systems, here's how you can add it -

Once you have installed Client for NFS, you are ready to start connecting to UNIX NFS shares where anonymous access is allowed. If your environment doesn't have any such shares to test connectivity, you now need to configure this system to fetch UNIX identity information from an existing User Name Mapping server or configure one if it is not already running.

See these posts to learn more about User Name Mapping, especially Configuring User Name Mapping, Configuring User Name Mapping - Part 1, Configuring User Name Mapping - Part 2 (Simple Mapping) and Configuring User Name Mapping - Part 3 (Advanced Mapping).

With Windows Server 2003 R2 and Windows Vista, you can configure Client for NFS to directly fetch this information from AD if it's already there since they offer RFC2307 support. In fact, you can use any RFC2307 compliant directory service.

Configuration for Client for NFS is over with this and you can start using it. To connect to NFS shares, you can use the same built-in mechanisms as you would with a normal Windows share. In fact, you also get to use the familiar mount command to use.

Run the nfsadmin client command to see what options Client for NFS is configured to use. It might show something like this and is self-explanatory -

The File Setting in the above screen shot is the UMASK value Client for NFS will use when you create a new file or a folder on an NFS mount.

You can use NET command, the mount command which comes with it or the "Map Network Drive..." to map a drive to remote NFS shares. You can also browse the network and look for system which export NFS shares using "Network Neighborhood" or "My Network Places" since Client for NFS adds "NFS Network" under "Entire Network" for people who find it easier to search for machines they would like to connect to.

The mount command is useful because it lets you override the default parameter which applies to the NFS connections from this computer. The help for mount command can be displayed by running it with /? command line switch -

It uses a similar syntax like the NET USE command but it's not completely identical. For example, following is what you can use to map z: drive a remote NFS export -

mount \\servername\sharename z:

On the performance side, Client for NFS is tuned with parameters which suit most of the environments, but still there are things which can be tweaked to see if it helps you the way you want it -

Read and Write buffers - This can tuned from the MMC snap-in or per mount using the mount command. If you do it using the mount command, the syntax will look like -
mount -o rsize=16,wsize=16 \\servername\sharename drive
The default is 32 KB and works perfectly in most of the scenarios.
Case-sensitive mounts - Since Windows is not case-sensitive, enabling case-sensitive option while mounting the NFS shares can reduces the time taken to look up a file on the server. When this is option is not turned on (which is the default behavior), Client for NFS can perform multiple lookups to locate a single file and that will show up as a performance problem
This can only be done using the mount command and the syntax to do this is -
mount -o casesensitive \\servername\sharename drive:
8.3 name cache - As with Windows, Client for NFS also generates a 8.3 format name for the files on the NFS shares being accessed using Client for NFS. This adds up to the processing overhead. Turning off this option is recommended for performance gain. This is done with a registry change and this KB article explains the steps.
8.3 name generation in Windows Server 2003 R2 and later releases are permanently turned off for the same reason.
NFS Caching - NFS v3 uses caching to improve performance but this can be problematic in certain scenarios. Create "RemoteWriteCache" and "FileAttributeCache" DWORD values under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Client for NFS\CurrentVersion\Users\Default\Cache and set these to 0 to disable caching.
Folder Content Caching - Client for NFS also caches the folder contents for 30 seconds to avoid performing lookups to the NFS servers. This can sometimes result in delayed folder content refresh. Follow the steps in this knowledgebase article to disable it.
Set this registry setting to a value between 5-25.

Something worth taking a note - although the settings related to different aspects of caching may improves things on the client side, they can have performance percussions on the server side because when caching is not at work, the client may place more calls to the server and depending on the server and network conditions, it may cause the server to sweat more than it would normally. It's completely up to you to decide who would you like to work more for you - NFS client or the server.

"Network Error 53", "The data area passed to a system call is too small" or "Unknown Error"

Ashish — Tue, 05 Jun 2007 02:51:00 GMT

"Network Error 53", "The data area passed to a system call is too small" or "Unknown Error"

Client for NFS included with Windows Server 2003 R2 returns different errors when trying to access NFS shares on UNIX-based NFS servers. The exact error message may depend on your environment - you might get one or more from the ones mentioned above. And, at the same time, SFU 3.5 Client for NFS may work just fine.

Analyzing the network traffic may show MOUNT or NFS calls being "rejected for security reasons (5)".

The R2 Client for NFS uses high ports (>1024) to connect to NFS servers and that's known to cause the above errors. There are two ways to fix this -

Change how your NFS servers export the NFS shares and make them allow connections from high ports, or,
Add UseReservedPorts DWORD value under HKLM\Software\Microsoft\Client for NFS\CurrentVersion\Default and set it to 1. Restart the Client for NFS service to allow the change to take effect.

Should you worry about security when you change your NFS server to allow connection from high ports? The answer is NO. An excerpt from RFC2623 says so -

Many NFS servers will require that the client send its NFS requests
from UDP or TCP source ports with values < 1024. The theory is that
binding to ports < 1024 is a privileged operation on the client, and
so the client is enforcing file access permissions on its end. The
theory breaks down because:

*    On many operating systems, there are no constraints on what port
     what user can bind to.
*    Just because the client host enforces the privilege on binding
     to ports < 1024 does not necessarily mean that a non-privileged
     user cannot gain access to the port binding privilege. For
     example with a single-user desk-top host running a UNIX
     operating system, the user may have knowledge of the root user
     password. And even if he does not have that knowledge, with
     physical access to the desk-top machine, root privileges are
     trivially acquired.

On the other hand, turning off low ports check on the NFS servers ensures compatibility with NFS clients irrespective of clients using high or low ports to access the NFS servers.

Note that above mentioned errors can be caused by number of other factors as well so if the solutions mentioned above don't work for you - focus your troubleshooting on other aspects.

How User Name Mapping works?

Ashish — Fri, 11 May 2007 23:28:00 GMT

How User Name Mapping works?

User Name Mapping is the core NFS authentication component in Services for UNIX, Windows Server 2003 R2 and Windows Vista. It bridges the gap presented by difference in user identification methods used by Windows and UNIX systems. It plays equally important role for Server for NFS and Client for NFS both.

When Server for NFS receives NFS access request from a UNIX client, all it gets is UID, GID and a set of auxiliary GIDs (which represents the secondary group memberships of that user in the UNIX world). Server for NFS then typically performs the following actions to authenticate the UNIX user who’s trying to access Windows NFS share –

Server for NFS uses User Name Mapping to obtain the corresponding Windows user name or group name.
After the user name is obtained, Server for NFS connects to a domain controller (for a domain account), or to local security authority for a local user –

The domain controller authenticates the domain account using Kerberos extension called Service-For-User (S4U).
Server for NFS Authentication is needed if the user account in question is a local account. Without Server for NFS authentication, the local security authority cannot authenticate the user and access to the UNIX client will be denied.

NFS authentication may not work for domain accounts if you have domain controllers running Window 2000 operating system. S4U extensions is not supported in Windows 2000 and earlier. In such cases, you need to install Server for NFS Authentication on all of your domain controllers to get the NFS authentication to work.

When you use Client for NFS to access a UNIX NFS share, it’s the UNIX NFS Server which authenticates the Windows user at the end. Since Windows users do not have UNIX-style UIDs and GIDs, the Client for NFS gets this information from the User Name Mapping service and uses them to connect to the UNIX NFS Server.

The NFS components included with Windows Server 2003 R2 and Windows Vista have RFC2307 support and can directly fetch the UIDs and GIDs from Active Directory. This post on this same blog talks more about this feature and User Name Mapping. The Active Directory domain, however, needs to be on the R2 schema level for that to work.

UNIX Interoperability and Windows Vista

Ashish — Tue, 01 May 2007 19:44:00 GMT

UNIX Interoperability and Windows Vista

There was SFU 3.5 Interoperability components. It got ported to Windows Server 2003 R2. And now we have similar interop components packaged with Windows Vista too. Windows Vista Ultimate and Enterprise editions include the Client for NFS and Subsystem for UNIX-based Applications (SUA). These Vista editions are targeted towards power users and large enterprise customers who are more likely to be benefitted from these components. However, none of the server components from SFU product line (namely Server for NFS, User Name Mapping, Server for NIS, Password Synchronization etc) are included with Vista.

You can install these components using the Programs and Features in Control Panel and then using the Turn Windows Features on or off -

Installing SUA adds only the subsystem and a program group - Subsystem for UNIX-based Applications. You need to download the utilities and SDK separately. The newly-added program group has a link to the Utilities and SDK download page.

New additions are SVR-5 Korn shell and over 150 utilities (which are found in the /svr-5 directory) and a Visual Studio Debugger add-in. This release also enables development and porting of custom UNIX applications using the Windows OCI (Oracle Call Interface) and Windows ODBC libraries which are collectively referred to as Mixed Mode.

Shanmugam, Program Manager with Microsoft maintains a blog about SFU, SUA and IDMU. You read more about these components in his blog.

Installing Client for NFS adds a Services for Network File System (NFS) MMC Snap-in to manage the Client for NFS configuration. The noticeable difference from R2 (apart from the GUI itself) is that you have two check-boxes to selectively enable User Name Mapping and/or Active Directory lookup for the UNIX identity mapping information -

Another difference is that now you can use the GUI to instruct the Client for NFS to use (or not to) reserved ports. This was otherwise done by tweaking a registry key (HKLM\software\Microsoft\Client for NFS\CurrentVersion\Default\UseReservedPorts) in previous releases -

Client for NFS in Windows Vista and Windows Server 2003 R2 supports RFC2307 attributes so it can also fetch UIDs/GIDs etc from any LDAP store which is RFC2307 compliant. I have tested this feature with Active Directory and this really is a cool addition to this component.