Server for NFS

Server for NFS exports Windows directories as Network File System (NFS) file systems, allowing NFS clients to access them.

  • Before you begin using Server for NFS, see Checklist: Setting up Server for NFS.
  • For tips about using Server for NFS, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For troubleshooting information, see Troubleshooting.


Checklist: Setting up Server for NFS

Step | Reference
Read about Server for NFS. | Concepts
Log on as a member of the Domain Admins group of the server's domain. |
Install Server for NFS Authentication on every domain controller in any domain containing users who will access files through Server for NFS. | To install the authentication package
Log on as a member of the (local) Administrators group. |
Configure user authentication. | To set up authentication
Configure logging. | To set up logging
Set the file-locking grace period. | To set the lock grace period
Configure other Server for NFS settings. | To enable TCP support To enable NFS v3 support To configure how file-name characters are translated To hide files with names beginning with a period To configure how often authentication is renewed To configure case sensitivity for file and directory names To set the directory cache size
Create client groups. | To create a group
Make directories available for mounting by network file system (NFS) clients. | To share a directory


Best practices

This section contains information about:

  • General best practices
  • Best practices for running Server for NFS in a server cluster


General best practices

  • Provide user-level security
    With Server for NFS, you can control access by users and groups to network files system (NFS) resources. To enable this, you must install Server for NFS Authentication on the primary and backup domain controllers of all domains containing users to whom you want to provide access. (If you do not use Server for NFS Authentication, all users will access NFS resources as anonymous users.) You must also install User Name Mapping on one computer in your network to associate Windows user accounts with UNIX user accounts.
  • Secure files
    All files shared through Server for NFS should be located on drives formatted for the NTFS file system. This allows you to provide file-level security. Also, when you share a directory through Server for NFS, make sure that directory and file permissions provide appropriate access control for anonymous users. In addition, when sharing the directory, use host-level access control to provide an additional level of security to protect the files in the directory.
  • Secure new drives
    When you add a new drive to a computer running Server for NFS, be sure to modify the permissions protecting the root directory of the drive to ensure that Everybody and other untrusted users cannot write to the directory. This will prevent untrusted users from being able to compromise Server for NFS security protecting shared directories on the drive.
  • Allow users to disconnect before stopping the service
    Before you stop Server for NFS or uninstall it, notify users who are connected to NFS shares that you are about to stop the service. You can then stop the service after the users have had the opportunity to close open files and disconnect from shared directories.
  • Use naming conventions to identify shares with EUC encoding
    If a directory is shared with one type of Extended UNIX Code (EUC) encoding (such as EUC-JP), and a client configured to use a different EUC encoding (such as EUC-TW) attempts to connect to the shared directory, unexpected results can occur. To prevent this, establish a naming convention to use when sharing directories with EUC encoding so users of client computers can know how shared directories are encoded.
  • Protect configuration files
    If you create configuration files (such as a character translation file or an audit log file), be sure to protect them with a discretionary access control list (DACL) that grants Full Control to the built-in System account and to the Administrators group. The DACL should contain no other entries.

For specific information about best practices for running Server for NFS in a server cluster, see Best practices for running Server for NFS in a server cluster.


Best practices for running Server for NFS in a server cluster

  • Ensure share availability when a node fails

    To ensure that a shared directory cluster resource will be available after the node containing the resource fails, make the cluster resource dependent on the appropriate physical disk resource.

  • Use the appropriate tool to manage network file system (NFS) share cluster resources

    Although you can use Windows Explorer to view properties of an NFS share cluster resource, you should not use it to change those properties. You should only use Cluster Administrator or the cluster command to create and administer shared NFS directories on a server cluster.

  • Avoid conflicting share names

    Ensure that the share name of every shared directory on the server cluster is unique. Otherwise, when one node in the cluster fails over to another node, and if shared directories on the two nodes have the same name, only one of the shared directories will be available.

  • Ensure the availability of audit logs

    Do not designate a shared disk resource as the location of the Server for NFS audit log. Only one node in the cluster can own the log file. This means that if the ownership of a group is moved to another node, the audit events for the remaining shares on the original node cannot be recorded in the file. To ensure the availability of Server for NFS audit logs, you should log events to the Event Viewer event log.

  • Move file shares or take them offline before stopping Server for NFS

    When Server for NFS is stopped on a cluster node hosting active NFS share resources, the cluster service responds as though this were a failure of one of its managed resources. Consequently, the cluster service will try to restart the service in an attempt to keep the resource available. Before you attempt to stop Server for NFS on a server cluster node, either move all groups containing NFS file shares to another node on the cluster, or take offline all NFS file shares on the node.

  • Take resources offline before modifying

    Be sure to take an NFS share directory resource offline before modifying its properties. Failing to do so might produce unexpected results.

  • Administer Server for NFS only from computers in a trusted domain

    To ensure that Server for NFS configuration changes are properly replicated, always use a computer that belongs to a trusted domain when you administer Server for NFS running on a cluster. This is necessary because Server for NFS configuration changes are not properly replicated among nodes in a cluster if you run Microsoft Services for Network File System Administration or nfsadmin on a computer that belongs to a domain that is not trusted by the domain of the cluster.

  • Restart Server for NFS service after the Cluster service restarts

    If the Cluster service must be restarted on a node in the cluster, stop and then restart the Server for NFS service on that node. This will ensure that Server for NFS configuration changes will be replicated properly among the nodes of the cluster.

  • Choose the appropriate sharing mode

    When you create an NFS share directory resource, you have the option of sharing the root of the specified directory, or all the subdirectories in the directory. Before choosing this option, first decide whether you will need to control access to the subdirectories or change their share names. If you will, you must share the subdirectories separately because when you create an NFS share directory resource to share the subdirectories, you cannot set access permissions, allow (or deny) anonymous access, or change the share name of the subdirectories separately.

    If you choose to share all the subdirectories in the directory, make sure that the permissions protecting the directory do not allow untrusted users to create subdirectories. Otherwise, an attacker can overwhelm the cluster service by creating a very large number of subdirectories that would automatically be shared as a cluster resource.

  • Use the command line properly when creating or modifying NFS share cluster resources

    If you use the cluster command to create and modify NFS share cluster resources, the following considerations apply:

    • When you create the cluster resource using the cluster command, you can set some nonprivate properties, but not all.
    • When using the cluster command to set properties, do not rely on default values because they might be invalid for an NFS share cluster resource. Always set property values explicitly.
    • To set or view permissions on an NFS share cluster resource, use Cluster Administrator. You can also use the nfsshare command to view permissions, but not to set them.
  • Use hard mounts

    Users of client computers should be instructed to used hard mounts when mounting NFS directories shared on the server cluster. This will ensure that, if the node sharing the directory fails, the client computer will not time out before the failover to another node is complete.

  • Use the correct virtual server name

    Users of client computers should be instructed to mount NFS directories shared on the server cluster using the virtual server name from the same group as the shared directory. Using a virtual server name from another group or the node name will allow the client computer to mount the directory, but the mount can be lost in case of a failover.


How to ...

  • Install the authentication package
  • Start Server for NFS
  • Stop Server for NFS
  • Share a directory
  • Stop sharing a directory
  • Configure a shared directory
  • Configure Server for NFS
  • Manage groups
  • Use Server for NFS on a server cluster


Install the authentication package

To install the authentication package

Using the Windows interface

  1. Insert the Microsoft Windows Services for UNIX compact disc into the CD-ROM drive.
  2. In the Microsoft Windows Services for UNIX Setup Wizard dialog box, click Next.
  3. In the User name box, type your name. If the name of your organization does not appear in the Organization box, type the name of your organization there.
  4. In the CD Key boxes, type the product key found on the back of the CD-ROM case, and then click Next.
  5. Read the End User License Agreement carefully. If you accept the terms of the agreement, click I accept the terms in the License Agreement, and then click Next to continue installation. If you click I do not accept the License Agreement (Exit Setup), the installation procedure terminates.
  6. Click Custom Installation, and then click Next.
  7. In the Components pane, click the down arrow next to Windows Services for UNIX, and then click Entire component will not be available.
  8. Click the plus sign (+) next to Authentication Tools.
  9. In the Components pane, click the plus sign (+) next to Authentication Tools.
  10. Click Server for NFS Authentication, click Will be installed on local hard drive, and then click Next.
  11. Follow the remaining instructions in the Wizard.

Notes

  • To open Add or Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add or Remove Programs.
  • NFS users can be authenticated using either Windows domain accounts or local accounts on the Windows server. Server for NFS Authentication must be installed on all domain controllers in the domain if NFS users will be authenticated using domain accounts. Server for NFS Authentication is always installed on the computer running Server for NFS.

Using a command line

  1. Insert the Microsoft Windows Services for UNIX compact disc into the CD-ROM drive.
  2. At a command prompt, type:

    msiexec /I drive:\sfusetup.msi /qb addlocal="NFSServerAuth"

Notes

  • In the command above, drive is the letter of the CD-ROM drive.
  • Server for NFS Authentication must be installed on all domain controllers in the domain if NFS users will be authenticated using domain accounts. If users will be authenticated using local accounts, Server for NFS Authentication must be installed on the computer running Server for NFS.

Related Topics

Microsoft Services for Network File System overview


Start Server for NFS

To start Server for NFS

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Right-click Server for NFS, and then click Start.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\ComputerName] start

Argument | Description
ComputerName | The name of the computer on which you want to start Server for NFS.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin /?

Related Topics

nfsadmin

Server for NFS overview


Stop Server for NFS

To stop Server for NFS

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Right-click Server for NFS, and then click Stop.

Notes

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.
  • Before attempting to stop Server for NFS running on a node in a server cluster, either move all groups containing network file system (NFS) file shares to another node or take all NFS file shares offline.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\ComputerName] stop

Argument | Description
ComputerName | The name of the computer on which you want to stop Server for NFS.

Notes

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin /?

  • Before attempting to stop Server for NFS running on a node in a server cluster, either move all groups containing NFS file shares to another node or take all NFS file shares offline.

Related Topics

nfsadmin

Server for NFS overview


Share a directory

To share a directory

Using the Windows interface

  1. Open Windows Explorer.
  2. In the details pane, right-click the directory you want to share.
  3. Click Sharing.
  4. On the NFS Sharing tab, click Share this folder.
  5. To change the name of the shared folder, type a new name in Share name. The new name is what users will see when they connect to this shared folder. The actual name of the folder does not change.

Notes

  • For information on how to open Windows Explorer, see To open Windows Explorer.
  • By default, when a directory is shared, all client computers are granted read-only access, and anonymous access is not allowed. See Related Topics for information on changing security settings for a shared directory.

Using a command line

  • At a command prompt, type:

    nfsshare [-o option[=value...]] sharename=drive:path

Argument | Description
sharename | The name of the shared directory.
drive:path | The path to the directory to be shared.
-o Specifies one or more options to be set. If supplied, must be set to at least one of the following:
anon={yes | no}
Specifies whether anonymous (unmapped) users can access the shared directory. The default is no.
anonuid=uid
Specifies that anonymous (unmapped) users will access the share directory using uid as their user identifier (UID). The default is -2. The anonymous UID will be used when reporting the owner of a file owned by an unmapped user, even if anonymous access is disabled.
anongid=gid
Specifies that anonymous (unmapped) users will access the share directory using gid as their group identifier (GID). The default is -2. The anonymous GID will be used when reporting the owner of a file owned by an unmapped user, even if anonymous access is disabled.
encoding={big5|euc-jp|euc-kr|euc-tw|gb2312-80|ksc5601|shift-jis}
Specifies the default encoding used for file and directory names and, if used, must be set to one of the following:
  • big5 (Chinese)
  • euc-jp (Japanese)
  • euc-kr (Korean)
  • euc-tw (Chinese)
  • gb2312-80 (Simplified Chinese)
  • ksc5601 (Korean)
  • shift-jis (Japanese)

If this is option is not set, the default encoding scheme is ANSI or, on systems configured for non-English locales, the default encoding scheme for the locale. The following are the default encoding schemes for the indicated locales:

  • Japanese: SHIFT-JIS
  • Korean: KS_C_5601-1987
  • Simplified Chinese: GB2312-80
  • Traditional Chinese: BIG5

In Windows NT 4.0, if a default encoding scheme other than ANSI is specified, you must have installed the language pack corresponding to the selected encoding scheme, or the command will fail.

{big5|euc-jp|euc-kr|euc-tw|gb2312-80|ksc5601|shift-jis}=host[:host]...
Specifies the file- and directory-name encoding for individual client computers. See the encoding option for more information.
na
Specifies that no client or group is to be granted access to the NFS share unless it is explicitly granted access.
noroot[=host[:host]...]
Denies root access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, root access will be denied by default to all clients and groups for which root access is not explicitly granted. See "Notes" for more information about interactions among option settings when creating a shared directory.
ro[=host[:host]...]
Provides read-only access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, read-only access will be granted by default to all clients and groups for which access is not explicitly granted or denied. When creating a shared directory, if the ro option is set for one or more clients, but the rw option is not set, only the clients specified with the ro option have access to the shared directory. See "Notes" for more information about interactions among option settings when creating a shared directory.
root[=host[:host]...]
Provides root access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, root access will be granted by default to all clients and groups for which root access is not explicitly denied. If the root option is not set when a folder is exported, no clients have root access to the shared directory. See "Notes" for more information about interactions among option settings when creating a shared directory.
rw[=host[:host]...]
Provides read-write access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, read-write access will be granted by default to all clients and groups for which access is not explicitly granted or denied. When creating a shared directly, if neither the ro nor the rw option is set, all clients have read-only access to the shared directory by default. See "Notes" for more information about interactions among option settings when creating a shared directory.

Notes

  • To view the complete syntax for this command, at a command prompt, type:

    nfsshare /?

  • By default, when a directory is shared, all client computers are granted read-only access, and anonymous access is not allowed. See Related Topics for information on changing security settings for a shared directory.
  • The default permissions assigned to client computers when creating a shared directory depends on the combination of options used when creating the shared directory. The following table shows how these default permissions are set for some combinations.
    Options | Permissions
    (None) | All clients: read-only
    -o root | All clients: read-only
    -o noroot | All clients: read-only
    -o ro=host host: read-only
    All other clients: no access
    -o rw=host host: read-write
    All other clients: no access
    -o root=host host: read-write
    All other clients: read-only
    -o noroot=host host: read-write
    All other clients: read-only
    -o root ro=host host: read-only
    All other clients: read-only
    -o noroot ro=host host: read-only
    All other clients: read-only
    -o root rw=host host: read-write
    All other clients: read-only
    -o noroot rw=host host: read-write
    All other clients: read-only
    -o root root=host host: read-write
    All other clients: read-only
    -o noroot noroot=host host: read-write
    All other clients: read-only
    -o rw=host1 root=host2 noroot=host3 host1: read-write
    host2: read-write
    host3: read-write
    All other clients: no access
    -o root=host1 root=host2 noroot=host3 host1: read-write
    host2: read-write
    host3: read-write
    All other clients: no access

    Note that these default settings apply only when creating a new shared directory. When nfsshare is used to modify an existing shared directory, only the specified properties are changed.

Related Topics

To configure access for a client computer or group

To allow anonymous access to a shared directory

To add clients and groups to the shared directory permissions list

To set default encoding for a shared directory

nfsshare

Server for NFS overview


Stop sharing a directory

To stop sharing a directory

Using the Windows interface

  1. Open Windows Explorer.
  2. In the details pane, right-click the directory you want to stop sharing.
  3. Click Sharing.
  4. Click NFS Sharing.
  5. Click Do not share this folder.
  6. Click OK or Apply.
  7. In the confirmation dialog box, click OK.

Note

  • For information on how to open Windows Explorer, see To open Windows Explorer.

Using a command line

  • At a command prompt, type:

    nfsshare /delete {shareName | drive:path}

Argument | Description
shareName | The name of the share that you want to stop sharing.
drive:path | The path to the directory that you want to stop sharing.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    nfsshare /?

Related Topics

nfsshare

To configure access for a client computer or group

Server for NFS overview


Configure a shared directory

  • Add clients and groups to the shared directory permissions list
  • Configure access for a client computer or group
  • Allow anonymous access to a shared directory
  • Set default encoding for a shared directory


Add clients and groups to the shared directory permissions list

To add clients and groups to the shared directory permissions list

Using the Windows interface

  1. Open Windows Explorer.
  2. In the details pane, right-click the directory for which you want to add clients or group.
  3. Click Sharing.
  4. Click the NFS Sharing tab.
  5. If the directory is not already shared, click Share this folder, and then, in the Share name box, type a name for the share.
  6. Click Permissions, click Add, and then do one of the following:
    • In the Names list, click the clients and groups you want to add, and then click Add.
    • Or, in the Add Names box, type the names of clients or groups you want to add, separating names in the list with a semicolon (;).
    • To see a list of the members of a group, in the Names list, click a group, click Members.
  7. In the Type of Access list, click the type of access you want to allow the selected clients and groups.
  8. Select Allow Root Access if you want a user identified as root to have access other than as an anonymous user. By default, the user identifier (UID) root user is coerced to the anonymous UID.
  9. In the Encoding list, click the type of directory- and file-name encoding to be provided to the selected clients and groups.
  10. To close the dialog box, click OK.

Notes

  • For information on how to open Windows Explorer, see To open Windows Explorer.

Using a command line

  • At a command prompt, type:

    nfsshare -o option[=value]... sharename

Argument | Description
sharename | The name of the shared directory.
-o Specifies one or more options to be set, and must be set to at least one of the following:
{big5|euc-jp|euc-kr|euc-tw|gb2312-80|ksc5601|shift-jis}=host[:host]...
Specifies the file- and directory-name encoding for individual client computers and client groups. The following encoding schemes are available:
  • big5 (Chinese)
  • euc-jp (Japanese)
  • euc-kr (Korean)
  • euc-tw (Chinese)
  • gb2312-80 (Simplified Chinese)
  • ksc5601 (Korean)
  • shift-jis (Japanese)

If this is option is not set, the default encoding scheme is used.

In Windows NT 4.0, if an encoding scheme other than ANSI is specified, you must have installed the language pack corresponding to the selected encoding scheme, or the command will fail.

noroot[=host[:host]...]
Denies root access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, root access will be denied by default to all clients and groups for which root access is not explicitly granted.
ro[=host[:host]...]
Provides read-only access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, read-only access will be granted by default to all clients and groups for which access is not explicitly granted or denied.
root[=host[:host]...]
Provides root access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, root access will be granted by default to all clients and groups for which root access is not explicitly denied.
rw[=host[:host]...]
Provides read-write access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, read-write access will be granted by default to all clients and groups for which access is not explicitly granted or denied.

Notes

  • To view the complete syntax for this command, at a command prompt, type:

    nfsshare /?

  • By default, when a directory is shared, all client computers are granted read-only access, and anonymous access is not allowed.

Related Topics

To share a directory

Manage groups

Understanding Server for NFS security


Configure access for a client computer or group

To configure access for a client computer or group

Using the Windows interface

  1. Open Windows Explorer.
  2. In the details pane, right-click the directory for which you want to set permissions.
  3. Click Sharing.
  4. Click NFS Sharing, and then, if the folder has not already been shared, click Share this folder.
  5. Click Permissions.
  6. Click the client or group for which you want to set permissions.
  7. In the Type of Access list, click the type of access you want to allow the client or group.
  8. Select Allow Root Access if you want a user identified as root to have access other than as an anonymous user. By default, the user identifier (UID) root user is coerced to the anonymous UID.
  9. In the Encoding list, click the type of directory- and file-name encoding to be provided to the client or group.
  10. Click OK twice.

Notes

  • For information on how to open Windows Explorer, see To open Windows Explorer.

Using a command line

  • At a command prompt, type:

    nfsshare -o option[=value]... sharename

Argument | Description
sharename | The name of the shared directory.
-o Specifies one or more options to be set and must be set to at least one of the following:
{big5|euc-jp|euc-kr|euc-tw|gb2312-80|ksc5601|shift-jis}=host[:host]...
Specifies the file- and directory-name encoding for individual client computers or client groups. The following encoding schemes are available:
  • big5 (Chinese)
  • euc-jp (Japanese)
  • euc-kr (Korean)
  • euc-tw (Chinese)
  • gb2312-80 (Simplified Chinese)
  • ksc5601 (Korean)
  • shift-jis (Japanese)

If this is option is not set, the default encoding scheme is used.

In Windows NT 4.0, if an encoding scheme other than ANSI is specified, you must have installed the language pack corresponding to the selected encoding scheme, or the command will fail.

na
Specifies that no client or group is to be granted access to the NFS share unless it is explicitly granted access.
noroot[=host[:host]...]
Denies root access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, root access will be denied by default to all clients and groups for which root access is not explicitly granted.
removeclient=host[:host]...
Removes the specified clients from the list of permissions of the shared directory. Separate client and group names with a colon (:).
ro[=host[:host]...]
Provides read-only access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, read-only access will be granted by default to all clients and groups for which access is not explicitly granted or denied.
root[=host[:host]...]
Provides root access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, root access will be granted by default to all clients and groups for which root access is not explicitly denied.
rw[=host[:host]...]
Provides read-write access to the shared directory by the clients or client groups specified by host. Separate client and group names with a colon (:). If host is not specified, read-write access will be granted by default to all clients and groups for which access is not explicitly granted or denied.

Notes

  • To view the complete syntax for this command, at a command prompt, type:

    nfsshare /?

  • By default, when a directory is shared, all client computers are granted read-only access, and anonymous access is not allowed.

Related Topics

To share a directory

To add clients and groups to the shared directory permissions list

Manage groups

Understanding Server for NFS security


Allow anonymous access to a shared directory

To allow anonymous access to a shared directory

Using the Windows interface

  1. Open 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 the Allow anonymous access check box.
  6. To specify a nondefault value for the anonymous user identifier (UID) or anonymous group identifier (GID), type the value in the Anonymous UID or Anonymous GID box.
  7. Click Apply.

Notes

  • For information on how to open Windows Explorer, see To open Windows Explorer.
  • The anonymous UID and anonymous GID values for a share will be used when reporting the owner of a file owned by an unmapped user, even if Allow Anonymous Access is disabled.

Using a command line

  • At a command prompt, type:

    nfsshare -o option=value... sharename

Argument | Description
sharename | The name of the shared directory.
-o Specifies one or more options to be set and must be set to at least one of the following:
anon={yes | no}
Specifies whether anonymous (unmapped) users can access the shared directory. The default is no.
anonuid=uid
Specifies that anonymous (unmapped) users will access the share directory using uid as their user identifier (UID). The default is -2. The anonymous UID will be used when reporting the owner of a file owned by an unmapped user, even if anonymous access is disabled.
anongid=gid
Specifies that anonymous (unmapped) users will access the share directory using gid as their group identifier (GID). The default is -2. The anonymous GID will be used when reporting the owner of a file owned by an unmapped user, even if anonymous access is disabled.

Notes

  • To view the complete syntax for this command, at a command prompt, type:

    nfsshare /?

Related Topics

To share a directory

Understanding anonymous access


Set default encoding for a shared directory

To set default encoding for a shared directory

Using the Windows interface

  1. Open Windows Explorer.
  2. In the details pane, right-click the shared directory you want to manage.
  3. Click Sharing.
  4. Click NFS Sharing.
  5. In the Encoding list, select the type of encoding to be used for file and directory names in the shared directory. In addition to the default American National Standards Institute (ANSI) encoding, the following encoding is available:
    • BIG5 (Chinese)
    • EUC-JP (Japanese)
    • EUC-KR (Korean)
    • EUC-TW (Chinese)
    • GB2312-80 (Simplified Chinese)
    • KSC5601 (Korean)
    • SHIFT-JIS (Japanese)

    If this option is set to ANSI on systems configured for non-English locales, the encoding scheme is set to the default encoding scheme for the locale. The following are the default encoding schemes for the indicated locales:

    • Japanese: SHIFT-JIS
    • Korean: KS_C_5601-1987
    • Simplified Chinese: GB
    • Traditional Chinese: BIG5

Notes

  • For information on how to open Windows Explorer, see To open Windows Explorer.
  • On Windows NT 4.0, if a default encoding scheme other than ANSI is specified, you must have installed the language pack corresponding to the selected encoding scheme.

Using a command line

  • At a command prompt, type:

    nfsshare -o encoding={big5|euc-jp|euc-kr|euc-tw|gb2312-80|ksc5601|shift-jis} sharename

Argument | Description
sharename | The name of the shared directory.
drive:path | The path to the directory to be shared.
-o encoding=type Specifies the default encoding to be used and must be set to one of the following:
  • big5 (Chinese)
  • euc-jp (Japanese)
  • euc-kr (Korean)
  • euc-tw (Chinese)
  • gb2312-80 (Simplified Chinese)
  • ksc5601 (Korean)
  • shift-jis (Japanese)

If this is option is not set, the default encoding scheme is ANSI or, on systems configured for non-English locales, the default encoding scheme for the locale. The following are the default encoding schemes for the indicated locales:

  • Japanese: SHIFT-JIS
  • Korean: KS_C_5601-1987
  • Simplified Chinese: GB2312-80
  • Traditional Chinese: BIG5

Notes

  • To view the complete syntax for this command, at a command prompt, type:

    nfsshare /?

  • In Windows NT 4.0, if a default encoding scheme other than ANSI is specified, you must have installed the language pack corresponding to the selected encoding scheme, or the command will fail.

Related Topics

To share a directory

NFS and file names

Configure a shared directory


Configure Server for NFS

  • Set up authentication
  • Set the lock grace period
  • Release locks
  • Set up logging
  • Add performance counters
  • Add Performance Monitor counters in Windows NT
  • Enable TCP support
  • Enable NFS v3 support
  • Configure how file-name characters are translated
  • Hide files with names beginning with a period
  • Configure how often authentication is renewed
  • Configure case sensitivity for file and directory names
  • Set the directory cache size


Set up authentication

To set up authentication

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click point to Microsoft Services for NFS.
  3. Click the Settings tab.
  4. Type the name of the mapping server you want to use for authentication, and then click Apply.

Notes

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.
  • Before users can access files on the server, your computer must be listed in the .maphosts file on the computer running User Name Mapping. For more information, see Controlling access to User Name Mapping.

Using a command line

  • At a command prompt, type:

    sfuadmin [computerName] config mapsvr=serverName

Argument | Description
computerName | The name of the computer you want to manage.
serverName | The name of the mapping server you want to use for authentication.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    sfuadmin /?

  • Before users can access files on the server, your computer must be listed in the .maphosts file on the computer running User Name Mapping. For more information, see Controlling access to User Name Mapping.

Related Topics

sfuadmin

Understanding Server for NFS security


Set the lock grace period

To set the lock grace period

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Locking tab.
  4. In Waiting period, type the number of seconds within which users can reestablish locks after the server restarts.
  5. To save this setting, click Apply.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] config lockperiod=lockingGracePeriod

Argument | Description
remoteMachineName | The name of the computer you want to manage.
lockingGracePeriod | The time period (in seconds) within which users can re-establish locks after the server restarts.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin /?

Related Topics

nfsadmin

Server for NFS overview


Release locks

To release locks

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Locking tab.
  4. In the list of clients, click the client whose locks you want to release, click Release Locks, and then click Apply.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, do one of the following:
    • To list all locks, type:

      nfsadmin server [\\remoteMachineName] –l

    • To release locks, type:

      nfsadmin server [\\remoteMachineName] –r [client | all]

Argument | Description
client | The client whose locks you want to release.
all | Releases all locks.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin /?

Related Topics

nfsadmin

Server for NFS overview


Set up logging

To set up logging

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Logging tab.
  4. To log events in the Event Viewer application log, select Log events to the event log.
  5. To log events in a file, select Log events in this file and then, in the text box, type the name of the log file, or click Browse to find the file.
  6. In Maximum file size, type the maximum size for the log file.
  7. In Event types, select the events to log from the following options:
    • Mount. Users making mount and unmount requests.
    • Locking. Users locking and unlocking files.
    • Read. Users making requests to read a file.
    • Write. Users making requests to write to a file.
    • Create. Users making requests to create a file.
    • Delete. Users making requests to delete a file.
    • All. All of the above.
  8. To save the settings, click Apply.

Notes

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.
  • By default, no events are logged.
  • The log file must be on your local computer.
  • To stop logging an event, clear its check box.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] [config auditlocation={eventlog | file | both | none}] [config fname=filename] [config fsize=x] [config audit={+ | –}event...]

Argument | Description
remoteMachineName | The name of the computer you want to manage.
{eventlog | file | both | none} Specifies whether events will be audited and where the events will be recorded. One of the following arguments is required:
eventlog
Specifies that audited events will be recorded only in the Event Viewer application log.
file
Specifies that audited events will be recorded only in the file specified by config fname.
both
Specifies that audited events will be recorded in the Event Viewer application log as well as the file specified by config fname.
none
Specifies that events will not be audited.
filename | The name of the logging file. This must be a local file name. If the file does not exist, it is created.
x | The maximum size of the file in megabytes. The default size is 7 MB.
event An event to be logged. Type a plus sign (+) to start logging the event; type a minus sign (–) to stop logging it.
mount
Mount and unmount requests.
read
All requests to read a file.
write
All requests to write to a file.
create
All requests to create a file.
delete
All requests to delete a file.
locking
All requests to lock or unlock a file.
all
All of the above.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    nfsadmin /?

Related Topics

nfsadmin


Add performance counters

To add performance counters

  1. Click Start, point to Programs, point to Administrative Tools, and click Performance.
  2. Click the plus-sign (+) button.
  3. In the Performance object list, click Server for NFS, and then do one of the following:
    • Click All counters, and then click Add.
    • Or, click Select counters from list, click the counters you want to add, and then click Add.

Note

  • There is no command-line method for this procedure.


Add Performance Monitor counters in Windows NT

To add Performance Monitor counters in Windows NT

  1. Click Start, point to Programs, point to Administrative Tools (Common), and then click Performance Monitor.
  2. Click the plus sign (+).
  3. On the Object list, click Server for NFS.
  4. On the Counter list, click the statistics you want to monitor, and then click Add.

Note

  • There is no command-line method for this procedure.


Enable TCP support

To enable TCP support

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Server Settings tab.
  4. Select the Enable TCP support check box.
  5. To save the settings, click Apply.
  6. For the changes to take effect, you must stop and restart Server for NFS. For more information, see Related Topics.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] config enabletcp={yes | no}

Argument | Description
remoteMachineName | The name of the computer you want to manage.

Notes

  • For the changes to take effect, you must stop and restart Server for NFS. For more information, see Related Topics.
  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

  • TCP support is enabled by default.

Related Topics

To stop Server for NFS

To start Server for NFS

NFS and network protocols

nfsadmin


Enable NFS v3 support

To enable NFS v3 support

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Server Settings tab.
  4. Select the Enable NFS v3 support check box.
  5. To save the settings, click Apply.

Important

  • These changes will not take effect until Server for NFS is restarted. For information on how to stop and start Server for NFS, see Related Topics.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] config enablev3={yes | no}

Argument | Description
remoteMachineName | The name of the computer you want to manage.

Important

  • These changes will not take effect until Server for NFS is restarted. For information on how to stop and start Server for NFS, see Related Topics.

Notes

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

  • NFS v3 support is enabled by default.

Related Topics

To stop Server for NFS

To start Server for NFS

NFS and network protocols

nfsadmin


Configure how file-name characters are translated

To configure how file-name characters are translated

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Server Settings tab.
  4. Select the Translate file names check box.
  5. In the Use character translation file box, type the fully qualified path of the file containing the character-translation map list.
  6. To save the settings, click Apply.

Important

  • These changes will not take effect until Server for NFS is restarted. For information on how to stop and start Server for NFS, see Related Topics.
  • To prevent unauthorized users from tampering with the file-name character translation file and causing Server for NFS to fail, ensure that the file is protected with a discretionary access control list (DACL) that grants Full Control to the built-in System account and to the Administrators group. The DACL should contain no other entries.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] config translationfile=file

Argument | Description
remoteMachineName | The name of the computer you want to manage.
file | The fully qualified path and name of the file containing the character-translation map list. If you do not specify a file, character translation will be disabled.

Important

  • These changes will not take effect until Server for NFS is restarted. For information on how to stop and start Server for NFS, see Related Topics.
  • To prevent unauthorized users from tampering with the file-name character translation file and causing Server for NFS to fail, ensure that the file is protected with a discretionary access control list (DACL) that grants Full Control to the built-in System account and to the Administrators group. The DACL should contain no other entries.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    nfsadmin server /?

Related Topics

To stop Server for NFS

To start Server for NFS

NFS and file names

nfsadmin


Hide files with names beginning with a period

To hide files with names beginning with a period

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Server Settings tab.
  4. Select the Create files that have names beginning with ‘.’ as hidden files check box.
  5. To save the settings, click Apply.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] config dotfileshidden={yes | no}

Argument | Description
remoteMachineName | The name of the computer you want to manage.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

Related Topics

NFS and file names

nfsadmin


Configure how often authentication is renewed

To configure how often authentication is renewed

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Server Settings tab.
  4. Do one of the following:
    • To prevent Server for NFS from periodically renewing authentication, click Do not renew authentication.
    • To configure Server for NFS to renew authentication periodically, click Renew authentication every:, and then, in the box, type how many seconds will elapse before authentication will be renewed.
  5. To save the settings, click Apply.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • To configure Server for NFS to not renew authentication periodically, at a command prompt, type:

    nfsadmin server [\\remoteMachineName] config renewauth=no

  • To configure Server for NFS to renew authentication periodically, at a command prompt, type:

    nfsadmin server [\\remoteMachineName] config renewauth=yes

    nfsadmin server [\\remoteMachineName] config renewauthinterval=seconds

Argument | Description
remoteMachineName | The name of the computer you want to manage.
seconds | The number of seconds that will elapse before authentication is renewed. The default is 600.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

Related Topics

Understanding Server for NFS security

nfsadmin


Configure case sensitivity for file and directory names

To configure case sensitivity for file and directory names

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Server Settings tab.
  4. Do one of the following:
    • To enable case-sensitive file and directory names, select the Case sensitive lookups check box. All file systems are automatically set to preserve the case of file names.
    • To specify the case of file names returned by each file system type, clear the Case sensitive lookups check box and then click the button that corresponds to how you want file and directory names to be returned.
  5. To save the settings, click Apply.

Important

  • These changes will not take effect until Server for NFS is restarted. For information on how to stop and start Server for NFS, see Related Topics.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • To enable case sensitivity, at a command prompt, type:

    nfsadmin server [\\remoteMachineName] config casesensitivelookups=yes

  • To disable case sensitivity and optionally specify the case of file names returned by Server for NFS, at a command prompt, type:

    nfsadmin server [\\remoteMachineName] config casesensitivelookups=no [cdfscase={upper | lower | preserve}] [fatcase={upper | lower | preserve}] [ntfscase={upper | lower | preserve}]

Argument | Description
remoteMachineName | The name of the computer you want to manage.

Important

  • These changes will not take effect until Server for NFS is restarted. For information on how to stop and start Server for NFS, see Related Topics.

Notes

  • Use the cdfscase, fatcase, and ntfscase options to set the case sensitivity for the compact disc file system, file allocation table (FAT) file system, and NTFS file system, respectively. The default case sensitivity for all file systems when returning file and directory names is preserve (preserve case).
  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

Related Topics

To stop Server for NFS

To start Server for NFS

nfsadmin


Set the directory cache size

To set the directory cache size

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Server Settings tab.
  4. In the Directory cache size list, click the size in kilobytes to which you want to set the directory cache.
  5. To save the settings, click Apply.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] config dircache=size

Argument | Description
remoteMachineName | The name of the computer you want to manage.
size | The size in kilobytes to which you want to set the directory cache. The default size is 128 KB.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

Related Topics

Understanding the directory cache

nfsadmin


Manage groups

  • Create a group
  • Rename a group
  • Delete a group
  • Add a client computer to a group
  • Delete a client computer from a group


Create a group

To create a group

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Client Groups tab.
  4. In the Group Name text box, type the name of the group you are creating, and then click New. The group name should not be the same as the name of any host in the group.
  5. To save the settings, click Apply.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] creategroup groupname

Argument | Description
remoteMachineName | The name of the computer on which you want to create the group.
groupname | The name of the group to create.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

Related Topics

To add a client computer to a group

nfsadmin


Rename a group

To rename a group

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Client Groups tab.
  4. In the Current Groups list, click the group you want to rename, then click Rename Group.
  5. In the New Group Name box, type the new name for the group, and then click OK.
  6. To save the settings, click Apply.

Notes

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.
  • You cannot give a group the same name as a client in the group.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] renamegroup oldname newname

Argument | Description
remoteMachineName | The name of the computer you want to manage.
oldname | The current name of the group you want to change.
newname | The new name for the group.

Notes

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

  • You cannot give a group the same name as a client in the group.

Related Topics

nfsadmin


Delete a group

To delete a group

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS, and then click the Client Groups tab.
  3. In the Current Groups list, click the group you want to delete, click Delete Group, and then click Apply.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] Deletegroup groupname

Argument | Description
remoteMachineName | The name of the computer on which you want to delete the group.
groupname | The name of the group to delete.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

Related Topics

nfsadmin


Add a client computer to a group

To add a client computer to a group

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. Click the Client Groups tab.
  4. In the Current Groups list, click the group you want to add the member to.
  5. Click Advanced.
  6. In the box at the bottom of the page, type the name or Internet Protocol (IP) address of the client computer you want to add to the group, and then click Add Client.
  7. To save the settings, click Apply.

Notes

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.
  • You cannot add a member to a group that has the same name as the group.
  • You can add a range of IP addresses as a group member, for example, 127.0.0.*. You cannot remove a single computer in the range specified in this manner, however; you must remove the entire range.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] ADDMEMBERS groupname member[,members....]

Argument | Description
remoteMachineName | The name of the computer you want to manage.
groupname | The name of the group to which you want to add members.
member | The name of the member you want to add.

Notes

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

  • You cannot add a member to a group that has the same name as the group.
  • You can add a range of Internet Protocol (IP) addresses as a group member, for example, 127.0.0.*. You cannot remove a single computer in the range specified in this manner, however; you must remove the entire range.

Related Topics

nfsadmin


Delete a client computer from a group

To delete a client computer from a group

Using the Windows interface

  1. Open Microsoft Services for Network File System Administration.
  2. Click Server for NFS.
  3. In the Current Groups list, click the group that contains the computer you want to delete, and then click Advanced.
  4. In the List of Clients, click the name of the client computer you would like to delete, and then click Delete Client.
  5. Click Apply.

Note

  • To open Microsoft Services for Network File System Administration, click Start, point to All Programs, point to Microsoft Services for NFS, and then click Microsoft Services for NFS Administration.

Using a command line

  • At a command prompt, type:

    nfsadmin server [\\remoteMachineName] DELETEMEMBERS groupname member[,members....]

Argument | Description
remoteMachineName | The name of the computer you want to manage.
groupname | The name of the group from which you want to delete members.
member | The name of the member you want to delete.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    • nfsadmin server /?

Related Topics

nfsadmin


Use Server for NFS on a server cluster

  • Share a directory as a cluster resource
  • Modify a shared directory cluster resource
  • Delete a shared directory cluster resource


Share a directory as a cluster resource

To share a directory as a cluster resource

Using the Windows interface

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click the Groups folder.
  3. In the details pane (usually the right pane), click the group to which you want the resource to belong.
  4. On the File menu, point to New, and then click Resource.
  5. In the New Resource wizard, type the appropriate information in Name and Description, and in Resource type, click NFS Share. Click Next.
  6. Add or remove possible owners of the resource, and then click Next.
  7. To add or remove dependencies, do one of the following:
    • To add dependencies, under Available resources, click a resource, and then click Add.
    • Or, to remove dependencies, under Resource dependencies, click a resource, and then click Remove.
  8. In Share Name, type the name of the shared folder.
  9. In Share Path, type the fully qualified path of the folder to be shared.
  10. To share the folder and its contents as a single shared folder, click Share Root Only.

    Or, to share all folders (except hidden folders) in the folder specified in the previous step as separate shared folders, click Share Subdirectories Only.

  11. To allow access by users who have not been authenticated, click Allow anonymous access.
  12. To change the user identifier (UID) and group identifier (GID) values assigned to anonymous users, type the new values in the Anonymous UID and Anonymous GID boxes.
  13. In the Encoding list, select the type of encoding to be used for file and directory names in the shared directory. In addition to the default American National Standards Institute (ANSI) encoding, the following encoding is available:
    • BIG5 (Chinese)
    • EUC-JP (Japanese)
    • EUC-KR (Korean)
    • EUC-TW (Chinese)
    • GB2312-80 (Simplified Chinese)
    • KSC5601 (Korean)
    • SHIFT-JIS (Japanese)

    If this option is set to ANSI on systems configured for non-English locales, the encoding scheme is set to the default encoding scheme for the locale. The following are the default encoding schemes for the indicated locales:

    • Japanese: SHIFT-JIS
    • Korean: KS_C_5601-1987
    • Simplified Chinese: GB2312-80
    • Traditional Chinese: BIG5
  14. To specify permissions for the client computers that can access the shared folder, click Permissions.
  15. Click Finish.

Important

  • Before adding a resource to your cluster, you must verify the following:
    • The NFS Share resource type is available. This resource type was created when you installed Server for NFS on the cluster node.
    • A group already exists within the cluster to which your resource will belong.
    • All dependent resources have been created.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Using a command line

  1. At a command prompt, type (as a single command):

    cluster [ClusterName] resource "ResourceName" /create /restype:"NFS Share" /group:"GroupName" /privproperties ShareName="ShareName":STRING Path="SharePath":STRING ShareSubDirs=ShareType:DWORD GlobalPerm=PermType:DWORD Encoding=EncodingType:DWORD AnonymousAccessAllowed=AccessType:DWORD

  2. Next, type:

    cluster [ClusterName] resource "ResourceName" /online /wait[:Timeout]

Argument | Description
ClusterName | The name of the cluster you want to manage.
ResourceName | The name of the cluster resource.
GroupName | The name of the group to which you want to add the resource.
ShareName | The name of the shared directory you want to create. This value is ignored if ShareType is 0x1
SharePath | The fully qualified path of the directory to be shared.
ShareType | 0x0 if only the directory specified by SharePath is to be shared. 0x1 if the subdirectories (except hidden subdirectories) in the directory specified by SharePath are to be shared individually.
PermType Specifies root-access and read-write permission combinations. PermType must be one of the following values:
  • 0x1—No access
  • 0x9—No Access + Root
  • 0x2—Read only
  • 0xa—Read only + Root
  • 0x4—Read/write
  • 0xc—Read/write + Root
EncodingType Specifies the default encoding used for file and directory names and, if used, must be set to one of the following:
  • 0x7—ANSI
  • 0x5—BIG5 (Chinese)
  • 0x0—EUC-JP (Japanese)
  • 0x1—EUC-KR (Korean)
  • 0x2—EUC-TW (Chinese)
  • 0x6—GB2312-80 (Simplified Chinese)
  • 0x4—KS_C_5601-1987 (Korean)
  • 0x3—SHIFT-JS (Japanese)

If this is option is set to Ox7, the encoding scheme is ANSI or, on systems configured for non-English locales, the default encoding scheme for the locale. The following are the default encoding schemes for the indicated locales:

  • Japanese: SHIFT-JIS
  • Korean: KS_C_5601-1987
  • Simplified Chinese: GB2312-80
  • Traditional Chinese: BIG5
AccessType | 0x0 if anonymous access to the shared directory is not allowed. 0x1 if anonymous access is allowed.
Timeout | The number of seconds cluster waits before cancelling the command if it does not successfully complete. If /wait is specified without this value, cluster waits indefinitely or until the resource state changes.

Important

  • Before adding a resource to your cluster, you must verify the following:
    • The NFS Share resource type is available. This resource type was created when you installed Server for NFS on the cluster node.
    • A group already exists within the cluster to which your resource will belong.
    • All dependent resources have been created.

Notes

  • To view the complete syntax for this command, at a command prompt, type:

    cluster /?

  • All arguments listed above are required. Using default values might produce unexpected results.
  • You must use the Windows interface to set permissions on shared directories.
  • If the attempt to share the directory fails, cluster displays an error message, and detailed information about the failure is recorded in the cluster log.
  • You cannot set the user identifier (UID) and group identifier (GID) values assigned to anonymous users using the command line.

Related Topics

To modify a shared directory cluster resource

To delete a shared directory cluster resource

Understanding server clusters


Modify a shared directory cluster resource

To modify a shared directory cluster resource

Using the Windows interface

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click the Groups folder.
  3. In the details pane (usually the right pane), double-click the group that contains the resource you want to modify, and then click the resource.
  4. On the File menu, click Take Offline.
  5. When the resource is offline, on the File menu, click Properties.
  6. Change the properties you want to modify, and then click OK.
  7. On the File menu, click Bring Online.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Using a command line

  1. At a command prompt, type:

    cluster [ClusterName] resource "ResourceName" /offline /wait[:Timeout]

  2. Next, type:

    cluster [ClusterName] resource "ResourceName" /Option

  3. Next, type:

    cluster [ClusterName] res "ResourceName" /online /wait[:Timeout]

Argument | Description
ClusterName | The name of the cluster you want to manage.
ResourceName | The name of the cluster resource.
Timeout | The number of seconds cluster waits before cancelling the command if it does not successfully complete. If /wait is specified without this value, cluster waits indefinitely or until the resource state changes.

Cluster resource options

The following table describes the available cluster resource options:

Option | Use to...
/status | Display the status of a cluster resource (Online,Offline, or Failed). The resource name is optional. If you do not provide a resource name, the status of all cluster resources is displayed.
/create /group: group name /type: resource type [/separate] | Create a new resource in a specified group. Use /separate to specify that the resource should run in a separate Resource Monitor.
/delete | Delete a resource.
/rename: new resource name | Rename a resource.
/addowner:node name | Add a node name to the list of possible owners.
/removeowner:node name | Remove a node name from the list of possible owners.
/listowners | Display a list of possible owners.
/moveto:group | Move the resource to a different group.
/properties [property list] | View or set the resource common properties. The resource name is optional. If you do not provide a resource name, properties for all resources are displayed.
/privproperties [property list] | View or set the resource private properties. Resource name is optional. If you do not provide a resource name, private properties for all resources are displayed.
/fail | Initiate resource failure.
/online [/wait[:timeout in seconds]] | Bring the resource online.
/offline [/wait[:timeout in seconds]] | Take the resource offline.
/listdependencies | List the dependencies for a resource.
/adddependency: resource | Add a dependency for a resource.
/removedependency:resource | Remove a dependency for a resource.
/addcheckpoints:key[\subkey...][,key[\subkey...]...] | Add a registry checkpoint for a resource.
/removecheckpoints:key[\subkey...][,key[\subkey...]...] | Remove a registry checkpoint for a resource.
/checkpoints | List registry checkpoints for a resource. The resource name is optional. Checkpoints for all cluster resources are displayed if you do not provide a resource name.
/addcryptocheckpoints:key[\subkey...][,key[\subkey...]...] | Add a cryptographic key checkpoint for a resource.
/removecryptocheckpoints:key[\subkey...][,key[\subkey...]...] | Remove a cryptographic key checkpoint for a resource.
/cryptocheckpoints | List cryptographic key checkpoints for a resource. The resource name is optional. If you do not provide a resource name, checkpoints for all cluster resources are displayed.
/? or /help | Display cluster resource syntax.

For example, to change the name of a network file system (NFS) Share resource from "NFSShare1" to "NFSShare2", type the following at the Windows command prompt:

cluster resource "NFSShare1" /privproperties ShareName="NFSShare2":STRING

Cluster resource common property names

The following table describes the common cluster resource property names, their uses, and valid settings:

Common property names | Use
Name | Name of the cluster resource object.
Description | Describes a resource.
Type | Specifies the resource type.
DebugPrefix | Specifies the appropriate debugger for the resource. For more information, see the Microsoft Platform Software Development Kit.
SeparateMonitor | Indicates whether a resource shares a Resource Monitor. Valid values are True (1) and False (0).
PersistentState | Describes the last known persistent state of a resource. In order to save the resource's PersistentState property, the resource must be offline.
LooksAlivePollInterval | Recommended interval (in milliseconds) that the Cluster service polls a resource to determine whether it appears to be operational. If a value is not specified, a default value is taken from the LooksAlivePollInterval property for the resource type.
IsAlivePollInterval | Interval (in milliseconds) that the Cluster service polls a resource to determine whether it is operational. If a value is not specified, a default value is taken from the IsAlivePollInterval property for the specific resource type. IsAlivePollInterval cannot be zero.
RestartAction Describes the action to perform if the resource fails. The choices are as follows:

ClusterResourceDontRestart (0): Do not restart following a failure.

ClusterResourceRestartNoNotify (1): If the resource exceeds its restart threshold within its restart period, the Cluster service does not attempt to failover the group to another node.

ClusterResourceRestartNotify (2): If the resource exceeds its restart threshold within its restart period, the Cluster service attempts to failover the group to another node.

If you do not enter a value, the default allows the resource to affect the group, which can cause the group to failover to another system.
RestartThreshold | Specifies how many times the Cluster service attempts to restart the resource in the RestartPeriod before failing over the group.
RestartPeriod | Specifies the amount of time allowed for the restart attempts to reach the RestartThreshold before the Cluster service fails over the group.
PendingTimeout The amount of time that a Pending Online or Pending Offline resource has to resolve its status before the Cluster service puts the resource in Offline or Failed status.

The default value is three minutes.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    cluster /?

Related Topics

To share a directory as a cluster resource

To delete a shared directory cluster resource

Understanding server clusters


Delete a shared directory cluster resource

To delete a shared directory cluster resource

Using the Windows interface

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click the Groups folder.
  3. In the details pane (usually the right pane), double-click the group that contains the resource you want to modify, and then click the resource.
  4. On the File menu, click Take Offline.
  5. When the resource is offline, on the File menu, click Delete.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Using a command line

  1. At a command prompt, type:

    cluster [ClusterName] resource "ResourceName" /offline /wait[:Timeout]

  2. Next, type:

    cluster [ClusterName] resource "ResourceName" /delete

Argument | Description
ClusterName | The name of the cluster you want to manage.
ResourceName | The name of the cluster resource.
Timeout | The number of seconds cluster waits before cancelling the command if it does not successfully complete. If /wait is specified without this value, cluster waits indefinitely or until the resource state changes.

Note

  • To view the complete syntax for this command, at a command prompt, type:

    cluster /?

Related Topics

To share a directory as a cluster resource

To modify a shared directory cluster resource

Understanding server clusters


Concepts

This section covers:

  • Server for NFS overview
  • Administering Server for NFS


Server for NFS overview

With Server for NFS, a computer running a Microsoft Windows operating system can act as a network file system (NFS) server. Users can then share files in a mixed environment of computers, operating systems, and networks.

Users on computers running NFS client software can gain access to directories (called shares) on the NFS server by connecting (mounting) those directories to their computers. From the viewpoint of the user on a client computer, the mounted files are indistinguishable from local files.

Server for NFS uses the Open Network Computing remote procedure call (ONC RPC) protocol to implement the NFS protocol. Server for NFS also uses the external data representation (XDR) protocol to ensure portable data transmission between NFS clients and the NFS server.

UNIX computers follow advisory locking for all lock requests. This means that the operating system does not enforce lock semantics on a file, and applications that check for the existence of locks can use these locks effectively. However, Server for NFS implements mandatory locks even for those locking requests that are received through NFS. This ensures that locks acquired through NFS are visible through the server message block (SMB) protocol and to applications accessing the files locally. Mandatory locks are enforced by the operating system.

For additional background information about Server for NFS, see:
  • Understanding UNIX-to-Windows mapping
  • Understanding file systems and NFS
  • Understanding Server for NFS security


Understanding UNIX-to-Windows mapping

This section contains information about:

  • Reverse mapping
  • Mapping to domain users
  • Determining the GID of a file
  • Determining the UID of a file


Reverse mapping

Server for NFS uses reverse mapping to map permissions between a security descriptor on the Server for NFS computer and a UID/GID/Mode triplet on the NFS client. To specify a mapping between the UNIX client user identifier (UID) and group identifier (GID) and their corresponding Windows users and groups, use the User Name Mapping administration in Microsoft Services for Network File System Administration.

A given UID can be mapped to any Windows user. This mapping specifies the UID or GID to use when a mapped user or group is found to be the owner of a file. If the given UID is not mapped, the Anonymous logon account is used. Results can be unpredictable when this happens. All users should be mapped to valid Windows accounts.

A given GID can be mapped to any Windows group. If the given GID is not mapped, a group entry for NullGroup is placed in the discretionary access control list (DACL).

Reverse-mapping examples

In the examples, assume the following client and server configurations:

  • In example 1, Client1 has UID 10 and is mapped to Windows user NtUser1.
  • In example 2, Client2 has UID 20 and is mapped to Windows user NtUser2.
  • In example 3, Client1 is a member of group AppGroup1 (GID 15), which is mapped to Windows group NtGroup1.
  • In example 4, Client2 is a member of group AppGroup2 (GID 25), which is mapped to Windows group NtGroup2.
  • In example 5, the group adm is mapped to Windows group Administrators.


Mapping to domain users

With Server for NFS, network file system (NFS) requests can be processed as if they were issued by a Windows user. When Server for NFS users are mapped to domain users, the Authentication Tools must be installed on all authenticating computers. The Authentication Tools can be installed with the Microsoft Services for Network File System Setup wizard.

If you own a single copy of Server for NFS, you are licensed to install the Authentication Tools on all domain computers in your organization. The program should be installed on all domain and backup domain controllers to provide authenticated access to mapped users.

Mapping multiple Windows users to one UNIX user

Server for NFS uses reverse (UNIX user to Windows user) mapping to determine the file-access permissions for an NFS request. When Server for NFS receives the user identifier/group identifier (UID/GID) pair in an NFS request, it uses the mapping to determine the Windows user who is using the UID. The NFS request is determined to originate from that Windows user.

Since multiple Windows user accounts can be mapped to one UNIX user account, one of the mappings is marked as the primary mapping. The primary mapping specifies which mapping is used to determine the Windows user name for a given UID. Because multiple Windows users are mapped to the same UNIX user account, files owned by any of these Windows users are reported as being owned by the mapped UID. For example, if users Kim and Pat are mapped to UID 10, files owned by both Kim and Pat are reported to have UID 10. However, when the NFS request with UID 10 accesses the file, the file is accessed in the context of the primary Windows user. For example, if the mapping between Kim and UID 10 is the primary mapping, the NFS access request for UID 10 will be handled in the context of Kim. Consequently, files owned by Pat, although reported as owned by UID 10, may not be accessible to UID 10.

To avoid such situations, use one-to-one mapping in which each Windows user is mapped to a single UNIX user and vice versa.


Determining the GID of a file

To determine a group identifier (GID) to return to a network file system (NFS) client, Server for NFS first looks at the file group for the file's security descriptor. (See Understanding the Windows security descriptor.) It then proceeds in the order shown in the following list:

  • If the file group has a GID mapping, that GID is reported.
  • If the file group does not have a GID mapping, the anonymous GID is reported with the permissions found in the DACL.


Determining the UID of a file

To determine a user identifier (UID) to return to a network file system (NFS) client as the owner of a file, Server for NFS first looks at the file owner in the file's security descriptor. (See Understanding the Windows security descriptor.) The mapping for this security identifier (SID) is taken as the UID for the file.

If no mapping exists for this SID, the value for anonymous user ID is used as the UID for the file.

In either case, the permissions returned are those granted to the SID given as the Windows file owner.


Understanding file systems and NFS

This section contains information about:

  • NFS and file names
  • Using FAT and CDFS file systems with NFS
  • Using the NTFS file system with NFS


NFS and file names

Because network file system (NFS) has its origins on UNIX-based computers, the conventions used for naming files and directories on NFS file systems differ in several respects from those used by Windows. This topic covers three of these differences and describes how you can configure Server for NFS to deal appropriately with them. These differences are:

  • Special characters
  • Case sensitivity
  • Hidden files

In addition, this topic also discusses directory- and file-name encoding for client computers localized for East Asian languages.

Special characters

Every file system has characters that cannot be used in directory and file names, usually because those characters are reserved for use in path and command syntax. For example, a file stored on the NTFS file system cannot contain a colon (:) character because that character is used to separate the drive letter from the rest of the path in a fully qualified path name. UNIX file systems do not use letters to identify drives, so this syntax is not used, and consequently, colon characters can appear in UNIX file names.

Server for NFS stores files on Windows-based file systems on behalf of NFS clients, which assume UNIX file-system conventions. Because of this, you can use Server for NFS to specify how characters in directory and file names will be converted (mapped) when files are moved between Server for NFS and client computers. To accomplish this, you must create a file that defines how these characters are to be mapped, and then specify where Server for NFS can find the file containing these character maps. For information about creating the character map file, see File-name character translation. To learn how to configure Server for NFS to use this file, see To configure how file-name characters are translated.

Case sensitivity

Windows and UNIX computers typically differ in the way they use the case of letters in directory and file names.

UNIX computers are usually case sensitive when handling directory and file names. That is, a UNIX computer will distinguish between a file named MYFILE and a file named MyFile, allowing both to coexist in the same directory and accessing them only when the case used in the file name matches the stored file name exactly.

Windows computers, on the other hand, are case preserving, but not case sensitive. That is, they will allow a file to be named MyFile or MYFILE and will preserve the case difference, but will not allow two files with the same name, differing only in letter case, to be stored in the same directory. Nor do they use case as a criterion when locating files. In other words, either MyFile or MYFILE can exist in the same directory, but not both, and either file can be accessed using the name MYFILE or MyFile.

By default, Server for NFS is case sensitive when matching directory- and file-access requests to directories and files in its shared directories, and it preserves the case of the names of directories and files when creating files on behalf of NFS clients computers. You can instruct Server for NFS not to be case sensitive when returning directory and file names. For more information, see To configure case sensitivity for file and directory names.

Hidden files

Files can be hidden (that is, not displayed when the directory they are store in is listed) on both Windows and UNIX computers. In the case of Windows computers, files are hidden by setting a special attribute for the file. UNIX file systems simply do not list files whose names begin with a period (.) character. By default, Server for NFS does not create files with names beginning with a period as hidden files in the Windows file system. To learn how to configure Server for NFS to hide files with names beginning with a period, see To hide files with names beginning with a period.

Directory- and file-name encoding

Client computers that are localized for an East Asian language require special support by NFS servers to be able to use characters in that language when creating directory and file names. This support, called encoding, determines how two-byte character codes exchanged between the server and a client computer will be interpreted. You can configure an NFS share to provide a default language-specific encoding scheme for all clients that access the share; you can also specify an encoding scheme for each client in the permissions list of the share. For more information, see To set default encoding for a shared directory and Configure a shared directory.


Using FAT and CDFS file systems with NFS

File Allocation Table (FAT) and CD-ROM file system (CDFS) file systems support approximately the same levels of functionality. Neither of these file systems provides any type of access control. The mount permissions granted by the network file system (NFS) server administrator govern all access control. A CDFS file system always shares data as a read-only resource, regardless of the type of share permission you give it.

The characteristics shared by FAT and CDFS file systems include the following:

  • Write access to the file system equals full access. Any user given access to the file system has full control of the file system. While there does exist a read-only bit for every file entry, its use is strictly advisory, and it can be modified at will.
  • Because these file systems were designed around single-user computers, there is no such thing as a file owner.
  • Just as no file owner exists, neither does a file group.
  • There is no support for file links. These file systems use a single-name/single-file format with no support for multiple directory entries referring to the same file.

Because of these limitations, the following conventions are a part of the Server for NFS implementation:

  • The file owner and group are always returned as the owner and group given in the UNIX verification of the request. This means that every individual user is reported as the owner of all files. Having different users of the same file both reported as owners can seem confusing at first, but it is in keeping with the concept that anyone with access to the file system owns it. Any attempt to modify the owner or group of a file fails. If no UNIX verification is passed, the anonymous user identifier (UID) and the anonymous group identifier (GID) are reported. By default, the anonymous UID and anonymous GID are both –2 (65534 when used as an unsigned 2-byte integer), although these values can be changed for a share.
  • Reporting of file permissions was chosen to provide an accurate description of the permissions granted.
  • For clients granted read access to the mount point, permissions are reported as read-and-execute for owner, group, and other (in UNIX notation: -r-xr-xr-x). Any attempt to modify data or attributes on the shared resource fails.
  • For clients granted read/write or root access to the mount point, permissions are reported as read, write, and execute for the owner, group, and other (in UNIX notation: -rwxrwxrwx).
  • If the read-only attribute is set on a file, permissions are reported with no-write access.
  • A client with read-only access is unable to change permissions on any shared file. If the client is granted read/write or root permission, that client is allowed to manipulate the read-only bit associated with a file, thus making the file writable.

Important

  • If you want to protect data shared from a FAT file system, you must share it as a read-only resource.


Using the NTFS file system with NFS

File-permission mapping for the NTFS file system is required because the Windows security subsystem provides a more robust means of access protection than is available under UNIX file systems. Under UNIX, a file has a single owner and a single group, with certain permissions (read, write, and/or execute) granted to each. Separate permissions are also granted for others, meaning any other users who are not members of the group that owns the file.

NTFS, on the other hand, allows permissions to be assigned to many users or groups independently. For example, an NTFS file can specify that User A is to have read-and-write access, while User B is to have only read access. The same file can also have certain permissions for one or more groups. The objective of Server for NFS is to provide a consistent, intuitive mapping of file permissions that UNIX clients can work with, and users can understand.

For information about how Server for NFS maps NTFS permissions and UNIX modes to each other, see Understanding Windows and UNIX file system security.


Understanding Server for NFS security

Server for NFS security is a combination of Windows security and the security protocols that protect network file system shares (NFS) shares. Both Windows security and NFS security control access to files by individual users, based on the account with which the user logs on. In addition, NFS security controls access to shared directories by specific client computers. Server for NFS enforces both types of access control.

When an NFS client computer sends a file-access request to Server for NFS, Server for NFS first checks to determine whether the client computer is allowed the requested access. If not, Server for NFS returns an error message. For information on how to control client access to Server for NFS shares, see To add clients and groups to the shared directory permissions list and To configure access for a client computer or group .

If the client computer is allowed access, Server for NFS tries to determine whether the user on whose behalf the request is being made is allowed the requested access. The first step in this process is to determine whether the user has a Windows account. The account can either be a local account on the Windows computer running Server for NFS, or it can be a Windows domain account. To make this determination, Server for NFS passes to the server running User Name Mapping the user's user identifier (UID) and group identifiers (GIDs). These are obtained from the NFS client. (If the request is anonymous and Server for NFS is configured to allow anonymous access, Server for NFS supplies the anonymous UID and GID instead.) If the UID corresponds to a Windows account in the User Name Mapping database, and if any of the GIDs match a Windows group, User Name Mapping returns the user name and domain name of the account and the group names to Server for NFS.

In the next step, Server for NFS logs the user on by passing the domain name and user name to Server for NFS Authentication, either on the local computer or a domain controller, depending on the type of account it is. Server for NFS Authentication returns the user's security credentials to Server for NFS.

Once Server for NFS has obtained these credentials, it uses them when it requests file access on behalf of the user. When the file system receives a request from Server for NFS for access to a file, the file system checks the discretionary access control list (DACL) in the file's security descriptor to determine whether the specified user and the groups to which the user belongs are permitted the requested access. If access is permitted, the file system allows Server for NFS to read or write the contents of the file on behalf of the NFS client. If access is not permitted, the file system returns an error to Server for NFS, which in turn sends an error message to the NFS client.

When a client connection is inactive for 10 minutes, Server for NFS forces the user to be reauthenticated. To learn how to change this interval or disable this feature, see To configure how often authentication is renewed.

For additional information about the security descriptor, DACL, and how Server for NFS supports UNIX security, see the other topics covered in this section and Understanding Windows and UNIX file system security.

This section covers:

  • Understanding the Windows security descriptor
  • Understanding the discretionary access control list
  • Understanding setuid, setgid, and sticky bits
  • Understanding anonymous access


Understanding the Windows security descriptor

Server for NFS uses the Windows security descriptor when implementing network file system (NFS) access permissions. The security descriptor is the structure that governs security assignments for Windows. The security descriptor contains the following components:

  • File owner
  • File group
  • System access control list (SACL). The SACL is used for auditing and does not affect file permissions.
  • Discretionary access control list (DACL)

Within the security descriptor, the file owner and group refer to security identifiers (SIDs). A SID can be thought of as the internal representation for an individual user or group. The primary reason for using SIDs is to differentiate among accounts across different domains that share the same account name. Even though the names are the same, they represent different accounts and can be given different permissions to the same file.

For more information, see Understanding the discretionary access control list.


Understanding the discretionary access control list

The discretionary access control list (DACL) within the security descriptor provides the core of Windows security. The DACL is a list of entries that grant or deny certain rights to specific users or groups. A list entry is called an access control entry (ACE). Each ACE consists of the following:

  • A security identifier (SID) to identify a particular user or group.
  • An access list that specifies the permissions allowed or denied for the user or group.

The following is an example of a DACL:

  • DACL: Mrjones Full Control (All)
  • ToolGroup:Read(RX)
  • Everyone:Read (RX)

In this DACL, Mrjones has read, write, and execute access to the file, members of the group ToolGroup have read-and-execute access, and members of the group Everyone (all users) have read-and-execute access.

The following rules govern access to a file:

  • If no DACL is present, everyone is granted full access.
  • If a DACL is present, but contains no entries, everyone is denied access.
  • The file owner always has the ability to change the DACL.

In turn, these rules apply to the DACL:

  • DACL entries are searched sequentially.
  • All permissions are implicitly denied.
  • Once a permission has been denied, it cannot be granted.
  • Once a permission has been granted, it cannot be denied.

For more information, see Understanding the Windows security descriptor.


Understanding setuid, setgid, and sticky bits

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. For example, an executable file that has the setuid bit set will execute under the user ID of the file's owner, not the user ID of the user who is executing the file.

Typically, when the setuid or setgid bit is set on a file, the owner or group of the file is changed to the owner or group under whose ID the file will be executed. Unless a user has the right to restore files or directories, Windows security allows a user to take ownership of a file (if the file's permissions allow it), but not to transfer ownership to a second user. Consequently, to use chown or chgrp to change the owner or group of a file to another user or group, you must have the privilege to restore files and directories. By default, this privilege is assigned to members of the Administrators and Backup Operators groups, although it can be assigned to other groups or to individual users. In addition, the account of the user running chown or chgrp and the user or group to whom ownership is being transferred must be properly mapped by User Name Mapping.

Some UNIX-based network file system (NFS) servers apply special interpretations or restrictions for the setuid, setgid, and sticky bits. Some versions of UNIX, for example, enforce mandatory locking on a directory with the setgid bit set but no execute permissions. Server for NFS does not implement special interpretations or restrictions on using these bits.


Understanding anonymous access

It is not always desirable or possible to create and map a UNIX account for every Windows user. A Windows user whose account is not mapped to a UNIX account is treated by Server for NFS as an anonymous user—that is, a user with a user identifier (UID) and group identifier (GID) of -2 and -2, respectively.

For example, if a user on a UNIX computer lists files on a Server for NFS share, and those files are owned by Windows users whose accounts have not been mapped to UNIX accounts, the owner of those files will be shown as anonymous user and group, (-2,-2).

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 share, those values will be used when reporting the owner of a file owned by an unmapped user, even if anonymous access is not allowed. For more information about configuring anonymous access for a shared directory, see To allow anonymous access to a shared directory.


Administering Server for NFS

This section contains information about:

  • Server for NFS and server clusters
  • Allowing root access to resources
  • Displaying NFS information
  • File-name character translation
  • NFS and network protocols
  • Understanding the directory cache


Server for NFS and server clusters

This section contains information about:

  • Understanding server clusters
  • How Server for NFS runs on a server cluster
  • Adding a computer running Server for NFS to a server cluster


Understanding server clusters

A server cluster is a group of independent computer systems, known as nodes, that work together as a single system to ensure that mission-critical applications and resources remain available to clients. Every node is attached to one or more cluster storage devices. Clustering allows users and administrators to access and manage the nodes as a single system rather than as separate computers.

Server for NFS is specifically designed to make use of the server cluster. Because of this, when Server for NFS is installed on a server cluster, you can share a directory as a cluster resource. This ensures that if the node sharing the directory fails, another node in the cluster will resume sharing the directory until the failed node is restored. Running Server for NFS on a server cluster also allows you to provide static load balancing by distributing file shares among two or more nodes in the cluster. For more information about Windows clustering, see "Server Clusters" in Windows Server 2003 Help. For information about running Server for NFS on a server cluster, see How Server for NFS runs on a server cluster.


How Server for NFS runs on a server cluster

Because Server for NFS is specifically designed to make use of the server cluster, you can use Cluster Administrator to configure network file system (NFS) shared directories as cluster resources. This provides for high availability of those shared directories. This ensures that if the cluster node sharing the directory should be shut down or fail, another node in the cluster will take over the sharing of the NFS shared directory until the first node restarts. In addition to enhancing availability, distributing NFS shares among nodes in the cluster can provide for static load balancing among several servers. For more information about sharing NFS directories on a server cluster, see To share a directory as a cluster resource.

Because the NFS shared directory is the cluster resource (instead of the Server for NFS service itself), ownership of individual NFS shares can move easily from one node to the other, as circumstances require. However, configuration changes to Server for NFS (such as the name of the User Name Mapping server) on one node are automatically replicated to instances of Server for NFS running on other cluster nodes. This simplifies administration of multiple servers because you only have to configure Server for NFS on one computer.

For more information, see Adding a computer running Server for NFS to a server cluster.


Adding a computer running Server for NFS to a server cluster

To add a computer running Server for NFS to a server cluster, you must install the Cluster service on the computer and configure the computer as the first node of a cluster or as a member of an existing cluster. After the computer has been successfully added to the cluster, you must configure Server for NFS to operate in the cluster. To do this, open a command prompt on the computer, and then type the following:

instclus

After running this command, if there are any network file system (NFS) directories being shared by Server for NFS, you must delete those shares and recreate them as cluster resources. For more information, see To share a directory as a cluster resource.

All nodes in the cluster must be running Server for NFS.


Allowing root access to resources

You can allow UNIX users to have root access to resources.
  • Assign the client computer root access when the share is exported. See Configure access for a client computer or group.
  • Map the UNIX user root (UID 0) to the Windows user Administrator. Also, map the group to which root belongs to the Windows group Administrators.
  • Map the UNIX group to which permission will be granted to a Windows group.

For example, consider a situation in which the directory Testdir is owned by Administrators. This directory was created with an account that is a member of the Windows group Administrators. The permissions listed were set after the directory was created. At the UNIX client, the permissions look like this:

ls -ld /testdir
drwxrwxr-x 2 root root 64 Nov 3 12:11 /testdir/

When the directory is owned by Administrators, Server for NFS reports a user identifier (UID) and group identifier (GID) pair of 0,0.


Displaying NFS information

Server for NFS includes several tools for monitoring network file system (NFS) use and probing the network for other NFS servers and resources. These tools include the Windows System Monitor, rpcinfo, showmount, and nfsstat.

You can use the Windows System Monitor to display NFS statistics, including the number and type of requests received and the number of bytes read and written.

You can use the rpcinfo utility to:

  • List all programs registered with the port mapper on a local or remote host (rpcinfo -p).
  • Find all network nodes that have a specified program and version registered with the port mapper (rpcinfo -b). You must specify a program name and number and version.
  • Use the Transmission Control Protocol (TCP) to call the specified program (rpcinfo -t). You must specify a node name and program name. If a version is not specified, the program calls all versions.
  • Use the User Datagram Protocol (UDP) to call the specified program (rpcinfo -u). You must specify a node name and program name. If a version is not specified, the program calls all versions.

You can use the showmount utility to:

  • List all file systems exported on the specified NFS server (showmount -e).
  • List all remotely mounted clients and the directories each has mounted on the specified NFS server(showmount -a).
  • List all directories remotely mounted on the specified NFS server (showmount -d).

You can use the nfsstat utility to display the number of NFS V2, NFS V3, and Mount V3 calls made to the server since the counters were set to 0, either when the service started or when the counters were reset using nfsstat –z.


File-name character translation

Although Windows and UNIX file systems do not allow certain characters in file names, the characters that are prohibited by each operating system are not the same. For example, a valid Windows file name cannot contain a colon (:), but a valid UNIX file name can. If a UNIX user attempts to create a file in a network file system (NFS) share on Server for NFS, and that file contains an illegal character in its name, the attempt will fail.

To prevent this problem, use file-name character mapping to replace characters that are not allowed in a file system. To enable file-name character translation, create a text file that maps Windows to UNIX characters, and then configure Server for NFS to specify the path and name of the translation file.

A file-name character translation file is simply a list of mapped characters in the format:

0x nn 0x nn : 0x nn 0x nn [ ; comment]

where nn is the hexadecimal value of one byte of a two-byte Unicode character, and comment is an optional comment, which is preceded by a semicolon (;). Everything from the semicolon to the end of the line is ignored. The first character in the entry is the character on the client (UNIX) computer, while the second is the character used on the Windows-based Server for NFS computer.

For example, the following maps the UNIX colon (:) to a Windows dash (-):

0x00 0x3a : 0x00 0x2d ; replace client : with - on server

If this entry appears in the file-name character translation file on a Server for NFS computer, when an NFS client creates a file named re:salesquotas on a Server for NFS share, Server for NFS names the file re-salesquotas. This is the name that appears in Windows Explorer when local or remote Windows users display the contents of the shared folder. NFS clients that list the contents of the shared directory, however, see the file name as re:salesquotas. Character translation takes place for all files shared by the server, regardless of whether they were created by an NFS client.

Do not map a given character to more than one character. Mapping a character to two or more different characters, as shown in the following example, will produce unexpected results:

0x00 0x11 : 0x00 0x22
0x00 Ox11 : 0x00 0x33

Do not map a period (.) because it is used in the file-name syntax of both Windows and UNIX file systems.

After you have created the file-name character translation file, you must specify its location. For information on configuring Server for NFS to use character translation, see To configure how file-name characters are translated.

Important

  • To prevent unauthorized users from tampering with the file-name character translation file and causing Server for NFS to fail, ensure that the file is protected with a discretionary access control list (DACL) that grants Full Control to the built-in System account and to the Administrators group. The DACL should contain no other entries.


NFS and network protocols

Network file system (NFS) is a network protocol that, in its most widely adopted forms, is defined in RFC 1094 for NFS version 2 and in RFC 1813 for version 3. By default, Server for NFS supports clients using either version. You can override this, however, and configure Server for NFS to allow access only by version 2 client computers. See To enable NFS v3 support for more information.

NFS relies on two transport protocols: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Server for NFS supports both protocols. You can disable TCP support by Server for NFS. For more information about this, see To enable TCP support.


Understanding the directory cache

To improve performance when resolving path names, Server for NFS maintains a cache of directory information that it can search instead of directories on the physical disk. By default, this cache is configured to use 128 KB of memory. You can reduce the amount of memory the directory cache uses,however. For more information, see To set the directory cache size.


Troubleshooting

What trouble are you having?

Despite appearing to have appropriate permissions, the user cannot access folder or file.

Cause: The user belongs to one or more groups that are not mapped consistently, or User Name Mapping is not running.

Solution: To ensure proper file access, ensure that Windows and UNIX groups that are mapped to each other in User Name Mapping contain the same users, and that the members of the Windows and UNIX groups are properly mapped to each other. Also, ensure that the User Name Mapping service is running on the designated server.

Authenticated users cannot access network file system (NFS) resources.

Cause: User Name Mapping is not properly configured to work with this computer.

Solution: Ensure that the .maphosts file on the computer running User Name Mapping specifies the names or Internet Protocol (IP) addresses of computers that can map user accounts by using User Name Mapping. For more information, see Controlling access to User Name Mapping. If users cannot access NFS resources intermittently and configuring the .maphosts file does not solve the problem, it might be that too many client computers are trying to access User Name Mapping simultaneously. See "Error message: Unable to perform the requested operation as the mapping service cannot be contacted" in User Name Mapping Troubleshooting.

Users, including properly mapped users, cannot change the current directory to a shared directory or create files in the directory, even though anonymous access to the directory is allowed.

Cause: Either the NFS client does not support NFS v3, or Server for NFS is not configured to support NFS v3. Also, the discretionary access control list (DACL) protecting the shared directory does not have an entry for Everyone, and so the access mode bit for Other is reported as 0. Because NFS v2 clients rely on directory mode settings rather than performing a separate access check for the shared directory, the client incorrectly fails the attempted access.

Solution: Do one of the following:

  • To the DACL protecting the directory being shared, add an entry that grants Everyone read or read/write access, as appropriate.
  • Ensure that the NFS client supports NFS v3 and enable v3 support by Server for NFS.

The shared directory is not accessible even though it is listed as available.

Cause: The directory was moved after it was shared.

Solution: Return the directory to its original location, or stop sharing the directory and then reshare it.

All files created on Server for NFS are owned by Anonymous.

Cause: Authentication is not configured properly.

Solution: Ensure that mappings are set up correctly in User Name Mapping and that Server for NFS is configured to use the correct User Name Mapping server. Also, ensure that Server for NFS Authentication is installed on all domain controllers in the domain.

Files created by a new user are owned by Anonymous.

Cause: User Name Mapping and Server for NFS have not yet refreshed data from the Network Information Service (NIS) server. Typically, User Name Mapping refreshes data from NIS once an hour, and Server for NFS refreshes data from User Name Mapping once an hour.

Solution: The new user should wait at least two hours before attempting to access or create files on Server for NFS, or the administrator of the computer running User Name Mapping can refresh the mapping database. See Refresh data now.

A user cannot write to a file.

Cause: File permissions or attributes do not allow write access to the file or its directory.

Solution: If the directory is owned by the Administrators group, make an individual user account the owner of the directory. Ensure that the user's UNIX account is mapped to a valid Windows account and that the NTFS file system permissions of the directory and file allow write access to the Windows user account. Ensure that the read-only attribute is not set on the file or the directory.

Users of Japanese UNIX systems cannot view file names in Japanese.

Cause: Extended UNIX character (EUC) set is not enabled.

Solution: Configure the share to use the appropriate character encoding.

Server for NFS configuration settings are not replicated across nodes in a server cluster.

Cause: The cluster service is not running, was not running when Server for NFS started, or failed after Server for NFS started.

Solution: Take all NFS shares owned by the node offline, or move the cluster groups containing NFS shares to another node. Stop Server for NFS, start the cluster service if needed, and then restart Server for NFS. Return the NFS shares online or move the cluster groups back to the node.

Server for NFS fails to stop on a server cluster.

Cause: This is by design: When an NFS share is online on a cluster node, the cluster service automatically restarts Server for NFS to keep the shares online.

Solution: Before stopping Server for NFS on a server cluster node, take all NFS shares owned by the node offline, or move the cluster groups containing NFS shares to another node.

An network NFS share on a server cluster node fails to come online.

Cause: An NFS share on that node with the same alias or path already exists on the node.

Solution: Make sure that the shared path and alias are unique across the cluster. Also, avoid having nonclustered NFS shares on a server cluster node.

Cause: The user who installed the cluster service does not have read permission on the directory that is shared, so the path cannot be validated.

Solution: Grant read access to the directory for the user who installed the cluster service.

Cause: The disk resource containing the directory being shared is offline, so the cluster service cannot verify the path of the share.

Solution: Bring the disk resource online, and then bring the NFS share online. It is recommended that the NFS share resource be made dependent on the disk resource that contains the shared folder.

Cause: The disk is inaccessible due to hardware error.

Solution: Take the NFS shares on the disk offline. Ensure that the disk is accessible from all cluster nodes, and then bring the NFS shares online.

Cause: There are a large number of subdirectories under a subdirectories-only share, and the resource times out before all the shares are created when the resource is coming online.

Solution: Increase the time-out interval for the resource.

Creating or modifying an NFS share fails with the error: The share path specified does not exist, or you are trying to modify the properties of an online share.

Cause: The specified directory does not exist.

Solution: Make sure that the directory exists and that the path is correct.

Cause: The share is online.

Solution: Take the share offline, make the required modifications, and then bring the share online.

Cause: The disk resource containing the shared directory is offline, so the cluster service cannot verify the path of the share.

Solution: Bring the disk online, make the necessary modifications to the NFS share resource, and then bring the NFS share online.

User Name Mapping is properly configured, but users are not being mapped correctly.

Cause: Server for NFS is not set to use the correct User Name Mapping server.

Solution: Ensure that the specified User Name Mapping server is valid. If the User Name Mapping server is on a server cluster, ensure that the following conditions exist:

  • User Name Mapping is installed on all cluster nodes
  • User Name Mapping data is being replicated to all nodes in the cluster
  • Server for NFS is using the name of a Network Name cluster resource as the User Name Mapping server, not localhost or the name of any of the cluster nodes

Cause: Server for NFS has not received updated maps from the mapping server. If Server for NFS and User Name Mapping are on different computers, this occurs once every 30 minutes.

Solution: Force Server for NFS to refresh the maps by doing one of the following:

  • In Microsoft Services for Network File System Administration, click Server for NFS, and then click Apply.
  • Use the nfsadmin server command to execute an operation, such as by setting a value to its current value.
  • Restart Server for NFS.

Cause: Account changes on the Windows domain controller or the Network Information Service (NIS) server have not been received by User Name Mapping.

Solution: Force Server for NFS to refresh the maps by doing one of the following:

  • In Microsoft Services for Network File System Administration, click Server for NFS, and then click Apply.
  • Use the nfsadmin server command to execute an operation, such as by setting a value to its current value.
  • Restart Server for NFS.

Cause: Local accounts on a cluster node were mapped to UNIX user accounts. Local accounts are not valid on all nodes in a cluster.

Solution: Ensure that all Windows accounts mapped to UNIX accounts on User Name Mapping running on a cluster are Windows domain accounts.

Cause: The passwd and group files are not at the same location on all nodes of the cluster, or on a network drive.

Solution: Ensure that the passwd and group files are identical and at identical locations on local disks of all nodes.

Cause: The Server for NFS server is not on the list of permitted User Name Mapping server clients.

Solution: Ensure that the .maphosts files on all User Name Mapping server cluster nodes are identical to permit the node running Server for NFS to obtain maps from the User Name Mapping server.

Cause: The server running User Name Mapping has failed.

Solution: Correct the cause of failure and then restart User Name Mapping on the server.

Cause: A Windows account mapped to a UNIX account is disabled or no longer exists.

Solution: If the Windows account exists, but is disabled, enable it. If the account does not exist, create a new account and, if necessary, recreate the corresponding advanced map.

Cause: A Windows user account has not been granted the privilege to log on to the network.

Solution: Grant the required privilege to the Windows user account, and then force Server for NFS to refresh the maps by doing one of the following:

  • In Microsoft Services for Network File System Administration, click Server for NFS, and then click Apply.
  • Use the nfsadmin server command to execute an operation, such as by setting a value to its current value.
  • Restart Server for NFS.

Cause: Windows and UNIX groups mapped to each other do not contain the same members.

Solution: Ensure that all Windows users in a group are mapped to UNIX users in the corresponding UNIX group, and that all UNIX users in a group are mapped to users in the corresponding Windows group.

Cause: User Name Mapping settings are not properly replicated on all nodes in a server cluster.

Solution: Ensure that User Name Mapping on a server cluster is configured properly to allow replication on all nodes.

A group containing an NFS share fails to come online on a particular cluster server node.

Cause: Server for NFS is not installed on the node.

Solution: Install Microsoft Services for Network File System on the node.

Cause: The node is not configured as the preferred owner of the group.

Solution: Configure the group's properties to make the node the preferred owner of the group.

Cause: One of the resources in the group does not list the node as a possible owner even though the group specifies the node as a preferred owner.

Solution: Configure the resource's properties to specify the node as a possible owner.

The showmount –e command for a virtual server lists all shares on the node rather than those in the same group as the virtual server.

Cause: This is by design. There is only one instance of Server for NFS running on a node that will enumerate all shares on that node; it does not distinguish between shares in different cluster groups.

Solution: Maintain different groups on different nodes.

The root user is not granted proper permissions.

Cause: The share does not have root access enabled.

Solution: Right-click the shared directory, click Properties, click Permissions, and then click Root access allowed.

Cause: The computer from which the root user is accessing the share is not permitted root access.

Solution: Right-click the shared directory, click Properties, click Permissions, and then do one of the following:

  • Grant root access to ALL MACHINES.
  • Grant root access to a client group containing the computer.
  • Grant root access to the computer itself.

Cause: The root user does not have read/write permission.

Solution: Grant the appropriate permissions to the Windows user mapped to the root user. Right-click the shared directory, click Properties, click Permissions, and then click Root access allowed.

Cause: The root user account is not properly mapped to a Windows user account.

Solution: Map the root user to a Windows account in the Administrators or Domain Admins group, and map the root user's group to the same Windows group.

Cause: Server for NFS has not received updated maps from User Name Mapping.

Solution: Force Server for NFS to refresh the maps by doing one of the following:

  • In Microsoft Services for Network File System Administration, click Server for NFS, and then click Apply.
  • Use the nfsadmin server command to execute an operation, such as by setting a value to its current value.
  • Restart Server for NFS.

Cause: The root user's user identifier (UID) is not 0. Server for NFS grants root access only to a UNIX user with a UID of 0.

Solution: Change the root user's UID to 0.

Anonymous access fails on Windows XP.

Cause: Local security policy is not set to enable Everyone permissions to apply to anonymous users (the default).

Solution: Use the Local Security Policy manager to enable Everyone permissions to apply to anonymous users.


Reverse mapping example 1

The file ABC.TXT is owned by Client1, who is a member of AppGroup1. The file has a permissions mode of 0755, which gives full privileges to the file owner, and read-and-execute permissions to group members and others.

The file ABC.TXT is then assigned the following security descriptor on the Windows NT computer:

  • Owner: NtUser1
  • Group: NtGroup1
  • DACL: NtUser1 Full Control (All)
  • NTGroup1 Read (RX)
  • Everyone Read (RX)

The UNIX permissions are listed on the client as follows:

-rwxr-xr-x Client 1 AppGroup1 64 Nov 2 14:40 abc.txt


Reverse mapping example 2

The file MARKET.DOC has the following security descriptor on the Windows NT computer:

  • Owner: NtUser2
  • Group: NtGroup2
  • DACL: NtUser2 Read (RX)
  • NtGroup2 Read (RX)

The UNIX permissions are listed on the client as follows:

-r-xr-x--- Client2 AppGroup2 64 Nov 2 14:40 market.doc


Reverse mapping example 3

The file DATA.DOC has the following security descriptor on the Windows NT computer:

  • Owner: NtUser4
  • Group: NtGroup4
  • DACL: NtUser4 Full Control (All)
  • Everyone Read (RX)

Notice that NtUser4 is not mapped. Because there is no network file system (NFS) mapping for the Windows NT user NtUser4 and the Windows NT group NtGroup4, the unassigned user ID (Nouser) and group ID (nogrup) are used. The owner (NtUser4) has full permissions, according to the discretionary access control list (DACL). Since the group NtGroup4 does not have explicit permissions, the group permissions are the same as those for Everyone. The UNIX permissions are listed on the client as follows:

-rwxr-xr-x Nouser nogrup 64 Nov 2 14:40 data.doc


Reverse mapping example 4

The file WIRES.TXT has the following security descriptor on the Windows NT computer:

  • Owner: NtUser1
  • Group: NtGroup1
  • DACL: NtUser1 Full Control (All)
  • Everyone Read (RX)

The UNIX permissions are listed on the client as follows:

-rwxr-xr-x Client1 AppGroup1 64 Nov 2 14:40 wires.txt

The owner changes the permissions mode to 455 on the WIRES.TXT file. (Mode 455 gives read-only privileges to the owner and read-and-execute to the group and others.) Now the security descriptor is as follows:

  • Owner: NtUser1
  • Group: NtGroup1
  • DACL: NtUser1 Read (R)
  • Everyone Read (RX)

The UNIX permissions are listed on the client then as follows:

-r--r-xr-x Client1 AppGroup1 64 Nov 2 14:40 wires.txt


Reverse mapping example 5

The file BUILD.C has the following security descriptor on the Windows NT computer:

  • Owner: NtUser2
  • Group: NtGroup2
  • DACL: Everyone Full Control (All)

The UNIX permissions are listed on the client as follows:

-rwxrwxrwx Client2 AppGroup2 7-12-1998build.c