Semantic Differences Between Server for NFS and UNIX-Based NFS Servers

  • Article

Updated: August 1, 2014

Applies To: Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

Before you deploy Server for NFS (the NFS server implementation that is included with Windows server operating systems), you should be aware of the semantic differences between Microsoft® Windows®-based operating systems and UNIX-based operating systems. The semantic differences described in this article will help you understand minor variations in the end-user experience of client computers accessing data stored on Server for NFS using the NFS protocol.

Differences in file system semantics

This section describes semantic differences between Windows and UNIX-based operating systems that are visible when interacting with the file system over NFS. Cautionary notes mentioned in this article apply specifically to NFS shares configured on the NTFS file system.

Case-sensitivity and UNIX-based operating systems

UNIX-based operating systems are typically case-sensitive. This means that the file names OSCAR, Oscar, and oscar are not the same, and you can create three different files with these names when using UNIX-based operating systems. For Windows, the default behavior is case-insensitive. Therefore, the file names OSCAR, Oscar, and oscar refer to the same file. Volume drive letters are also case-insensitive. For example, D:\ and d:\ refer to the same volume.

Configuring case-sensitivity for Windows

Windows can be configured to be case-sensitive. However, before you do this, carefully read the following cautionary note.

Warning

It is critical that the Windows operating system is designed to be case-insensitive. Windows Shell, the Graphical User Interface (GUI) features (including Windows Explorer), the Server Message Block (SMB) protocol, and other Windows features rely on this case-insensitive behavior. It is strongly recommended that you turn on case-sensitive behavior for Windows, but only if the server is intended solely for file serving over the NFS protocol to UNIX-based computers. If there are SMB shares on the server or if other applications are configured to run on the server, you may experience unpredictable failures when these applications are unable to handle multiple files whose names differ only in case.

To configure case-sensitive behavior on the Windows file server, you must set the following registry key, and then restart the computer:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Kernel
Value Name: ObCaseInsensitive
Data Type: REG_DWORD
Value Data: 0 (Case sensitive)

Invalid characters for file names

Operating systems typically specify a set of valid characters that can be used in file names. The set of valid characters specified by UNIX-based operating systems differs from the set of valid characters for the Windows operating system. A detailed explanation of Windows naming conventions is available on MSDN at https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx.

Reserved characters

On Windows, the following sets of characters are reserved and cannot be used in file names:

  • < (less than)

  • > (greater than)

  • : (colon)

  • " (double quote)

  • / (forward slash)

  • \ (backslash)

  • | (vertical bar or pipe)

  • ? (question mark)

  • * (asterisk)

Character translation files

The previous section discusses how the set of valid file name characters on Windows is different from that on UNIX-based operating systems. Because of this, it may not be possible to create certain files with valid Unix file names on an NFS share hosted by Server for NFS. The following list includes examples of characters that are supported in file names in UNIX but are not supported in Windows:

  • * (asterisk)

  • : (colon)

  • ? (question mark)

Server for NFS provides a way to mitigate the effect of this semantic difference between Windows and UNIX-based operating systems. You can do this by creating a special configuration file called a character translation file, and then configure Server for NFS to use this file. For information on how to create character translation files, see Q324218 in the Microsoft Knowledge Base.

Reserved device names

For Windows, the following device names are reserved and should not be used when naming files:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.

In addition, these names should not be followed by an extension; for example, NUL.txt is not recommended.

Path lengths

In the Windows API (with some exceptions that are discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system code page. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path". The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.

Note

Windows Shell and the file system have different requirements. It is possible to create a path with the Windows API that the Shell user interface may not be able to properly interpret. Therefore, it is possible to create files with a long path on an NFS share hosted by Server for NFS from a UNIX-based NFS client. Additionally, these files may not be accessible locally from the Shell or Windows Explorer on the Windows Server, if they exceed the path limits of them.

A soft link (symlink/symbolic link) is a file system object that points to another file system object. Symbolic links are transparent to users. The links appear as normal files or directories, and they can be used by the user or application in exactly the same manner. A hard link is a directory entry that associates a name with a file on the file system. Server for NFS supports both symbolic and hard links; however, there is an important semantic difference that should be noted. The NFS RFC mandates that the NFS server must not interpret the contents of a symbolic link in any way and must treat it as an opaque blob.

On page 44, the NFS v3 Protocol Specification, RFC 1813, states:

““A symbolic link is nominally a pointer to another file. The data is not necessarily interpreted by the server, just stored in the file. It is possible for a client implementation to store a path name that is not meaningful to the server operating system in a symbolic link. A READLINK operation returns the data to the client for interpretation. If different implementations want to share access to symbolic links, then they must agree on the interpretation of the data in the symbolic link.””

Server for NFS stores symbolic links created by NFS clients as special plain text files on its local file system. The data corresponding to the symbolic link is stored inside these files by Server for NFS. In accordance with the NFS RFC, Server for NFS does not interpret the content of symbolic link files in any way and treats it as an opaque blob. The symbolic link data can be accessed by NFS clients over the NFS protocol. This is because Server for NFS recognizes attempts to access the special symbolic link files and returns the data stored in the symbolic link to the NFS client computer, when it is requested (in response to the READLINK procedure).

However, since Server for NFS stores symbolic links as files on the local file system, these will not appear as symbolic links/reparse points to other Windows applications. This includes access using Windows Explorer, access from another computer using the SMB protocol or from any other application running locally on the Windows server. In other words, if you access a symbolic link created by a UNIX-based client from a Windows computer over SMB, it will appear to be a regular file.

Special devices and pipes

The semantic difference described in the previous section on symbolic and hard links also applies to special devices and pipes since these are designated as special files by Server for NFS. When UNIX-based clients access special devices and pipes over the NFS protocol, it works as expected. However, if special devices and pipes are accessed locally on the Windows server or on other Windows computers using the SMB protocol, they appear as regular files. This is usually not a problem since special devices and pipes are meaningful only to the client that created them and not to other client computers.

Note

The Interix Shell is available as part of Subsystem for UNIX-based Applications (SUA) and can be used to view special devices and large files created by NFS clients that are not visible using Windows Shell and Windows Explorer. For more information on installing SUA, see Subsystem for UNIX-based Applications.

Semantic differences in security

Another important area where semantic differences exist between Windows and UNIX-based operating systems is security.

Differences in security namespace

The security namespace on Windows is different from the security namespace on UNIX-based operating systems. The user account namespace on UNIX-based operating systems, such as Linux and Solaris, is based on numeric identifiers known as user identifier (UID) and group identifier (GID). This is different from the Windows account namespace where user and group accounts are identified by a unique identifier called a security identifier (SID). Administrators need to map Unix and Windows identities in order to share files and data between UNIX-based and Windows-based computers. Account/identity mapping is the process of correlating the Unix UIDs and GIDs to corresponding Windows user and group SIDs.

An important difference between UNIX-based operating systems and Windows operating systems is that the group and user account namespace is common in Windows. This means that you cannot configure a group account with the same name as an existing user account. However, on a UNIX-based operating system, you can create user and group accounts that have the same name.

Account mapping

Administrators configure account mapping by mapping UIDs and GIDs to corresponding Windows user and group accounts. Account mapping is persisted in a store that is called an identity mapping store. When an NFS client tries to access the contents of an NFS share using AUTH_SYS authentication, Server for NFS uses the account mapping to perform authentication checks against the underlying file systems. Server for NFS supports the following identity mapping stores:

  • Active Directory Domain Services (AD DS)

  • RFC 2307 compliant LDAP stores such as Active Directory Lightweight Directory Services (AD LDS)

  • User Name Mapping (UNM) server – Note that this mapping store type is scheduled to be removed in a future release of Windows Server. It is recommended to use either Active Directory or Active Directory Lightweight Directory Services (AD LDS) instead.

Account Mapping: Resources/White papers

Microsoft has published a set of white papers that explain how to configure and manage account mapping in the supported identity mapping stores.

Changing ownership of a file (‘chown/chgrp’)

In Windows operating systems, privileges determine the type of system operations a user account can perform. An administrator assigns privileges to user and group accounts. Each user's privileges include those granted to the user and to the groups to which the user belongs. For a list of the available Windows privileges, see Privilege Constants.

Important

You should note that Server for NFS evaluates the right of a Unix user to use a chown or chgrp command to change ownership, based on the privileges that have been configured for the corresponding mapped Windows account.

Assuming ownership of files

In Windows, any user who has WRITE_OWNER access on a file or object can assume ownership of the object (in other words, the user can change the owner of the object to the user’s own account). To assume ownership of a file, the user must have the SeTakeOwnershipPrivilege on Windows. This privilege is required to take ownership of an object without being granted discretionary access. It also allows the owner value to be set only to those values that the user or group may legitimately assign as the owner of an object. However, this privilege is not sufficient to give ownership to someone else.

Granting ownership to files

In Windows, users need to have SeRestorePrivilege to set the owner of a file or object to someone else. This privilege is required to perform restore operations and prompts the system to grant write access control to any file, regardless of the access control list (ACL) specified for the file. Any access request other than write is still evaluated with the ACL. Additionally, this privilege enables you to set any valid user or group SID as the owner of a file.

Note

By default, SeRestorePrivilege is only granted to Administrators and Backup Operators. You should note that if the Unix ‘root’ user is not mapped to an Administrator account on the Windows server, the root user will not be able to grant other users ownership to a file or directory that belongs to an NFS share. However, for UNIX-based operating systems, the root user can grant ownership of files and directories to other user accounts.
You must have the privilege to restore files and directories (SeRestorePrivilege) to use chown or chgrp commands to change the owner or group of a file to another user or group. By default, this privilege is assigned to members of the Administrators and Backup Operators groups, although it can also be assigned to other groups or to individual users. In addition, the account of the user running chown or chgrp commands and the user or group to whom ownership is being transferred must be properly mapped through Active Directory Lookup or User Name Mapping.
You can assign privileges to Windows accounts using Local Security Policy by editing the list of users for each privilege listed under Security Settings/Local Policies/User Rights Assignment in the tool.

Changing group ownership of a file for supplementary groups

UNIX-based operating systems have what are known as supplementary groups. On UNIX-based operating systems, a user may be listed as a member of additional groups in the /etc/group file. The IDs of these groups are referred to as supplementary group IDs. Some UNIX-based operating systems allow NFS clients to change the group ownership of a file to a supplementary group. However, Server for NFS does not support this. In addition, this restriction applies to shares that are configured for Unmapped Unix User Access (UUUA).

Using 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 NTFS formatted volumes and shared using 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 run under the user ID (UID) of the file owner, not the UID 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 ID (GID) where the file will run. 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 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 been assigned the privilege of restoring files and directories (SeRestorePrivilege). 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. The account of the user running chown or chgrp and the user or group to whom ownership is being transferred must be properly mapped in a supported identity mapping store.

Some UNIX-based Network File System (NFS) servers apply special interpretations or restrictions for the setuid, setgid, and sticky bits. For example, some UNIX-based operating systems enforce mandatory locking on a directory with the setgid bit set but no run permissions. Server for NFS does not implement special interpretations or restrictions on using these bits.

Secure default – setuid/setgid turned off

Typical setuid and setgid behavior present a known security issue in UNIX-based operating systems. An intruder can exploit setuid and setgid behavior by overwriting an executable file with a Trojan horse and then running the executable file. The executable file runs with the rights of the owner, instead of running as the intruder. To prevent this known security issue, Windows disables setuid and setgid. This does not affect the UID or GID settings if the file or directory has both of the following characteristics:

  • One or both of the following bits is set: setgid or setuid.

  • The file or directory is group writable, group executable, world writable, or world executable.

Some customers may find this security measure problematic because it is different from the typical behavior of UNIX, although the typical behavior of UNIX setUID and setGID is not specified as part of the NFS protocol. You can change the setuid/setgid behavior by modifying the following registry key:

HKEY_Local_Machine\System\CurrentControlSet\Services\NfsSvr\Parameters\ 

Value Name: SafeSetUidGidBits
Data Type: REG_DWORD
Value Data: 0 (standard Unix behavior, setuid/setgid enabled)
            1 (safer default behavior, setuid/setgid disabled)

ACE Inheritance

As explained in the previous section, by default, Server for NFS does not enable setUID or setGID semantics since it exposes a known security issue. As a result, the owner and group information is not inherited by newly created files and subdirectories in NFS shares. Server for NFS relies on NFS clients to handle propagating owner and group information. Some UNIX-based NFS clients, such as Solaris, manage propagating the owner and group of the parent folder to the newly created files and directories if the setUID and setGID semantics are set on parent directories within the NFS share. However, other UNIX-based clients do not propagate owner and group information.

Windows ACE inheritance can be used as to mitigate this issue when UNIX-based clients do not automatically propagate the owner and group information.

Configuring ACE inheritance

You can enable the KeepInheritance setting to configure the inherited access control entries (ACEs) on newly created files and directories in NFS mounted directories. By default, the value of the KeepInheritance entry is 0, which means that newly created files and directories on NFS shares do not inherit ACEs from their parent directory. However, if you want to be able to read and write every file and directory created in a hierarchy, you should set this value to 1 and set an inheritable read/write ACE at the root of the hierarchy.

HKEY_Local_Machine\Software\ServerForNFS\CurrentVersion\Mapping 

Value Name: KeepInheritance
Data Type: REG_DWORD
Value Data: 0 (KeepInheritance disabled)
            1 (KeepInheritance enabled)

For more information on ACE inheritance in Server for NFS, see Q321049.