Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a NFS share on a Netapp and a laptop running windows 7 enterprise that needs to mount the volume. I've installed all the NFS services on windows 7, and am able to mount and browse the drive. The problem is that I don't have access to modify files on the volume.

Googling around, I think this is because I need to map my windows user to a unix user, but all searches for User Name Mapping Service indicate that this is not something I can do on the windows 7 laptop.

Does anyone know what I have to do to get this laptop to access that NFS share? What about other windows laptops?

share|improve this question
up vote 1 down vote accepted

First you need to look at the Qtree security style for the exported volume/qtree. This will be either NTFS/Unix/Mixed.

If it is to only be used by Windows hosts, set it to NTFS, if this particular export is to be mounted on *nix hosts, and you want nix to handle all permissions, set it to Unix. Mixed should generally be avoided.

As for mapping users, this is done by modifying the /etc/usermap.cfg file on the filer. You can edit this in various ways, the easiest (but most unsafe) way to do this is by doing "wrfile /etc/usermap.cfg" from the NetApp command line. The perferred way would be to edit the file using a proper editor by mounting the internal "etc$" share via CIFS or NFS.

Documentation on the formatting of the usermap file can be found at the NetApp NOW Site which requires a login.

Here is a very small snippet of documentation which might get you moving:

# These are some sample "defensive" entries you may wish to use.
# They can be uncommented and placed as needed. See the System
# Administrator's Guide for a full description of this file.
# *\root => nobody        # Map all NT users named "root" to have no
#                         # UNIX perms. They can still log in though.
# guest <= administrator  # Map UNIX user "administrator" to NT guest.
# guest <= root           # Map UNIX root user to guest. This should be
#                         # placed after any real "root" mappings.
# The next two mappings can be used to defeat the default mapping of
# the user names. That way only entries that are mapped previously in
# this file will be allowed.
# *\* => ""               # Map all other NT requests to fail.
# "" <= *                 # Map all other UNIX requests to fail.
# The pound sign "#" is used as a comment character in map entries. The
# next three mappings show how to handle an NT user name which includes
# a pound sign. The name must be quoted. If the user account contains
# both domain and name, the username must be quoted separately.
# "#jdoe" => joed             # Map NT user #jdoe to UNIX user joed.
# NTDOM\"#jdoe" <= joed       # Map UNIX user joed to NT user NTDOM\#jdoe.
# "nt-domain\#jdoe" <= joed   # BAD, won't work.

Basically, you willtake the name of your windows user, and map it to a valid unix user using something like:

domain\user => unixUser

You can also use wild cards.

share|improve this answer
Thanks! I'll give these a shot. – Basil Oct 26 '11 at 15:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.