Mixed mode operation

The maximum length of a file name is 255 characters, and file names may contain any Unicode character. Case-sensitivity in file names is significant to NFS and FTP clients, but not SMB clients.

Modern Windows (CIFS/SMB) clients (NT and newer) can make full use of UCS-2 (a two byte Unicode encoding). When communicating with Windows 9x, the server uses the Latin-1 version of extended ASCII.

When communicating with NFSv2 or NFSv3 clients, the server supports the Latin-1, UTF-8, EUC-KR, EUC-JP, and EUC-CN encodings. For NFSv2 or NFSv3 clients, the Latin-1 character set is the default. When communicating with NFSv4 clients, the server supports only the UTF-8 encoding.

If you plan to have file names that include non-ASCII characters, you should change the default encoding used by the server using the protocol-character-set command.

Parent Topic

• Mixed mode operation

Symbolic links (symlinks) are commonly used:

• To aggregate disparate parts of the file system.
• As a convenience, similar to a shortcut in the Windows environment.
• To access data outside of a cluster. For example, a symlink can point to data in another server in a server farm or a non- server.

There are two types of symlinks:

• Relative symlinks contain a path relative to the symlink itself. For example, . ./dst is a relative symlink.
• Absolute symlinks contain a path relative to the root of the file system on the NFS client that created the symlink (not relative to the root of the server's file system). For example, /mnt/datadir/dst is an absolute symlink.

When accessing the file system through NFS, the server fully supports symlinks. NFS/UNIX clients assume that files marked as symbolic links contain a text pathname that the client can read and interpret as an indirect reference to another file or directory. Any client can follow a symlink, but accessing the target file (or directory) still requires permission.

Clients using SMB1 cannot follow files marked as symlinks. For these files the server provides a server-side symlink following capability. When an SMB or FTP client accesses a server-side symlink, the server reads the path from the link and attempts to follow it automatically:

• For relative symlinks, the link can be followed because the server can follow the path from the link itself.
• For absolute symlinks, the server does not have access to the root of the file system on the NFS client that created the link, so it cannot follow the link automatically.

  The server provides global symlinks, which allow clients using SMB1 to follow absolute symlinks:

  • If an absolute symlink refers to a file or directory in the same SMB share as the symlink, the server follows the symlink (on behalf of the SMB client) internally.
  • If an absolute symlink refers to an object in a different SMB share to the symlink, the SMB client is redirected to the link's destination via the Microsoft DFS mechanism.
    NoteThe Microsoft DFS mechanism supports redirection only to a directory (not a file). Therefore, absolute symlinks that refer to a file (in a different SMB share) will not be handled properly by an SMB client.

    The link's destination may be on the same file system as the link, on a different file system within a server farm, or on a remote SMB server. To associate a global symlink with an absolute symlink, the server maintains a translation table between absolute symlink paths and global symlink paths.

    NoteAs of release 12.2 of the NAS Platform, clients using SMB2 or later can follow relative and absolute symlinks to files on storage without using server-side symlinks.

When accessing server-side symlinks, SMB clients cannot follow some symlinks which are perfectly valid for NFS, because the storage system follows the symlink on the SMB client's behalf and presents the linked-to file instead of the symlink. In this case, in line with the behavior of Samba, the server hides the existence of the symlink entirely from the SMB/FTP client. By default, a symlink that points outside of the scope of its own share (for example, to a different file system) is not followed.

Clients using SMB2 or later can follow relative and absolute symlinks to files on storage without using server-side symlinks. The following CLI commands manage this client-side SMB2 behavior:

• smb2-client-side-symlink-handling-default
• smb2-client-side-symlink-handling-disable
• smb2-client-side-symlink-handling-enable
• smb2-client-side-symlink-handling-status

For more information about the CLI commands, see the Command Line Reference.

Global symlinks (also called absolute symlinks) start with a slash character (/), and they allow you to set up links to data outside a cluster. NFS clients follow the global symlink directly and, for SMB clients, the server maintains a server-side translation table, that allows those clients to access the symlink destination. Both NFS and SMB clients can follow the same global symlink to the destination directory, when the global symlink, the exports, shares, and mount points are set up correctly. When a client encounters a global symlink:

• For NFS clients, the server returns the content of the global symlink, allowing the client to follow the link to the destination. This means that the NFS client's mount points and the NFS exports must be set up correctly.
• For SMB clients, the server causes the client to request a symlink lookup from the local EVS translation table. Once the client requests the lookup, the server returns the destination server name, share name, and path to the SMB client, allowing it to access the destination.

Using global symlinks with SMB has a performance penalty. Therefore, global symlinks are disabled by default, but can be enabled by selecting the Follow Global Symbolic Links check box on the Add Share page (when creating the share) or CIFS Share Details page (after the share has been created).

Symlink translation tables are maintained on a per-EVS basis, meaning that:

• Table entries do migrate with the EVS. If an EVS is migrated, all of its table entries migrate along with the EVS.
• Table entries do not replicate from the EVS. When replicating data from one EVS to another, the mapping information for global symlinks is not automatically relocated, and it must be recreated in the translation table of the EVS into which the data was copied.
• Table entries do not move with a file system. If a file system is moved from one EVS to another, the mapping information for global symlinks is not automatically relocated and must be manually adjusted, except for those symlinks that are relative to a CNS tree (those symlinks do not require adjustment).
• Table entries irrelevant for symlinks that are relative to a CNS. When an EVS is migrated, no adjustment is necessary for symlinks that are relative to a CNS because, when the client follows the symbolic link, it is first referred to the CNS tree, then from the CNS tree to a real file system when the path crosses a CNS link.

The following CLI commands manage the symlink translation table:

• global-symlink-add
• global-symlink-del
• global-symlink-delall
• global-symlink-list

For more information about the CLI commands, see the Command Line Reference.

Parent Topic

• Mixed mode operation

The storage server supports mixed mode access for file systems, meaning that a mapping is required between the file system permissions and owners in order to ensure consistent security and access. NIS/LDAP services allow the server to locate and map users and permissions based on an existing NIS/LDAP service on the network, instead of creating a local account on the storage server.

On an existing LDAP service, one of the following methods is typically used for allowing the server to locate and map users and permissions:

• RFC 2307 / RFC 2307bis schemas

  RFC 2307 defines a standard convention for the storage and retrieval of user and group mapping information from an LDAP server. If your site uses the RFC 2307 (or RFC 2307bis) schema, and you configure your storage server/cluster to support both mixed mode operations and LDAP services, it is assumed that you have already loaded the RFC 2307 schema into your directory, and that you have already provisioned the user objects appropriately. This is the default method.

• Microsoft Active Directory schema

  This setting configures your server to operate with Microsoft Active Directory 2012 and newer using the default Active Directory schema.

You can also configure the server to operate with two deprecated Microsoft LDAP services:

• Microsoft Windows Services for UNIX (SFU) schema
• Microsoft Identity Management for UNIX (IMU) schema

To ensure optimum performance when your server/cluster is configured to support both mixed mode operations and LDAP services, the most optimized configuration includes the creation of indexes in the LDAP service for attributes queried by the storage server. To ensure fastest responses to queries, exact-match indexes should be configured on the LDAP server for the attributes to be searched. The LDAP server on your network should index at least the following attributes:

To track indexing performance, you can use the ldap-stats command, which permits you to monitor response times for LDAP queries. It is necessary to first let the storage server complete some successful user lookups so that some statistical data can be gathered. In a short period of time, however, you should be able to determine whether any of the attributes are not indexed.

Parent Topic

• Mixed mode operation

The server supports both SMB and NFS locks. The server supports only one type of byte range locking for SMB clients. For NFS clients, however, additional byte range lock types are supported. When created by NFSv2 and NFSv3 clients, the server supports both monitored (NLM/NSM) and non-monitored advisory byte-range locks. When created by NFSv4 clients, the server supports both mandatory and advisory byte range locks.

The following tables describe the server behavior when a client locks a file using a byte range lock:

• Server default configuration (the server treats byte range locks by NFSv4 clients as mandatory):

  Locked by client of type	Lock type when the client accessing the locked file is:
  	NFSv2 or NFSv3	NFSv4	SMB
  NFSv2 or NFSv3	Advisory	Mandatory	Mandatory
  NFSv4	Mandatory	Mandatory	Mandatory
  SMB	Mandatory	Mandatory	Mandatory

• When the server is configured to treat byte range locks from NFSv4 clients as advisory:

  Locked by client of type	Lock type when the client accessing the locked file is:
  	NFSv2 or NFSv3	NFSv4	SMB
  NFSv2 or NFSv3	Advisory	Advisory	Mandatory
  NFSv4	Advisory	Advisory	Mandatory
  SMB	Mandatory	Mandatory	Mandatory

To change the server configuration so that it treats NFSv4 byte-range locks as advisory, use the command set nfsv4-locking-is-advisory-only 1.

To change the server configuration so that it treats NFSv4 byte-range locks as mandatory, use the command set nfsv4-locking-is-advisory-only 0.

Parent Topic

• Mixed mode operation

An oplock is a performance-enhancing technique used in Microsoft networking (SMB) environments. It enables applications to speed up file access and minimize network traffic by caching all or part of a file locally. As the data is kept on the client, read and write operations can be performed locally, without involving the server.

The server supports three categories of oplocks:

• Exclusive. An Exclusive oplock enables a single client to cache a file for both reading and writing. As the client that owns the oplock is the only client accessing the file, it can read and modify all or part of the file locally. The client does not need to post any changes to the server until it closes the file and releases the oplock.
• Batch. A Batch oplock enables a single client to cache a file for both reading and writing, as in the case of an exclusive oplock. In addition, the client can preserve the cached information even after closing the file; file open and close operations are also performed locally. The client does not need to post any changes back to the server until it releases the oplock.
• Level II. A Level II oplock enables multiple clients to cache a file for reading only. The clients owning the oplock can read file data and attributes from local information, cached or read-ahead. If one client makes any changes to the file, all the oplocks are broken.

When dealing with oplocks, the server acts in accordance with the SMB specification. Whether operating in a pure Windows environment or with a mix of SMB and NFS clients, the server allows applications to take advantage of local caches while preserving data integrity.

Parent Topic

• Mixed mode operation

An Exclusive or Batch oplock is an exclusive (read-write/deny-all) file lock that an SMB client may obtain at the time it opens a file. The server grants the oplock only if no other application is currently accessing the file.

When a client owns an Exclusive or Batch oplock on a file, it can cache part or all of the file locally. Any changes that the client makes to the file are also cached locally. Changes do not need to be written to the server until the client releases the oplock. In the case of an Exclusive oplock, the client releases the oplock when the server requests that it does so, or when it closes the file. In the case of a Batch oplock, the client may keep information (including changes) locally even after closing the file. While the client has an Exclusive or Batch oplock on a file, the server guarantees that no other client may access the file.

If a client requests access to a file that has an Exclusive or Batch oplock, the server asks the client with the oplock to release it. The client then writes the changes to the server and releases the oplock. Once this operation has finished, the server allows the second client to access the file. This happens regardless of the second client’s network protocol.

In cases where an SMB client requests an oplock on a file that has an Exclusive or Batch oplock, the server breaks the existing oplock and grants both clients Level II oplocks instead.

Parent Topic

• Mixed mode operation

A Level II oplock is a non-exclusive (read-only/deny-write) file lock that an SMB client may obtain at the time it opens a file. The server grants the oplock only if all other applications currently accessing the file also possess Level II oplocks:

• If another client owns an Exclusive or Batch oplock, the server breaks it and converts it to a Level II oplock before the new client is granted the oplock.
• If a client owns a Level II oplock on a file, it can cache part or all of the file locally. The clients owning the oplock can read file data and attributes from local information without involving the server, which guarantees that no other client may write to the file.
• If a client wants to write to a file that has a Level II oplock, the server asks the client that has the oplock to release it, then allows the second client to perform the write. This happens regardless of the network protocol that the second client uses.

Parent Topic

• Mixed mode operation

In NFSv4 users and groups are identified by UTF-8 strings of the form: user@dns_domain and group@dns_domain. The NAS Platform supports the following universal user/group identifiers:

NFSv4 requires a mapping between Unix and NFSv4 names.

Parent Topic

• Mixed mode operation

When the server is operating in either mixed or UNIX security mode, it creates mappings between UNIX and Windows users and groups. For example, user John Doe could have a UNIX user account named jdoe and a Windows user account named johnd. These two user accounts are made equivalent by setting up a user mapping. Furthermore, the server assumes that equivalent user and group names are the same for both environments. For example, if no explicit mapping is found for user janed, the server assumes that the UNIX user account named janed is the same as the Windows user account with the same name.

There are two steps to follow when setting up user and group mappings on the server:

• Specify each NFS user and group’s name and ID. Note that this step is not required for Windows users or groups, as the server obtains all of the information it needs from the domain controller (DC).
• Map the NFS user (group) names to Windows NT user (group) names.

Parent Topic

• Mixed mode operation

Windows access to a file created by a UNIX user (or vice-versa) is permitted when the UNIX name and Windows name are recognized as being the same user. However, NFS clients present an NFS operation to an NFS server with numerical UNIX User ID (UID) and UNIX Group ID (GID) as credentials. The server must map the UID and GID to a UNIX user or group name prior to verifying the UNIX to Windows name mapping.

The server uses the following methods to map from a numerical UNIX UID or GID to a UNIX user name or group name:

• If the server is configured to use the Network Information Service (NIS) no special configuration steps are needed; the server automatically retrieves the user (group) names and IDs from the NIS server.
• NFS user and group names can be added manually.
• NFS user and group names can be added by importing files. For example, the UNIX /etc/passwd file can be imported, providing the server with a mapping of user name to UID. The /etc/groups file should also be imported to provide the server with a mapping of Group name to GID.
• You can import the numerical ID to Name mappings directly from a NIS server or an LDAP server if one has been configured. Every time a UID is presented to the server, it will issue an NIS request to an NIS server to verify the mapping. This mapping can remain cached in the server for a configurable time. A cached ID to name binding for a User or Group will appear as Transient in the NFS Users or Groups list.
  NoteWhen a Windows user creates a file and the UNIX user or group mapping fails, the server sets the UID or the GID to 0 (root). In previous releases, the server sets the UID or GID to 0 (root) or to 65534 (nobody).

Parent Topic

• Mixed mode operation

Child Topics

• Viewing NFS user mappings
• Creating an NFS user mapping
• Modifying user mappings

  You can modify user mappings in the NAS Manager.

• Deleting a user mapping

  You can delete a user mapping in the NAS Manager.

• Adding group mappings manually

  You can add group mappings manually in the NAS Manager.

• Modifying group mappings

  You can make changes to the group mapping in the NAS Manager.

• Deleting a group mapping

  You can delete a group mapping in the NAS Manager.

You can specify user or group details by importing them from a file.

NFSv4 user and group names are distinct from the UNIX name associated with UNIX UIDs and GIDs. However, in many environments a user/group's NFSv4 name can be derived from their UNIX name by appending the NFSv4 domain. The storage server can perform this conversion automatically, based on the settings specified on the Domain Mappings page of NAS Manager or through the CLI command domain-mappings-add.

To display the Domain Mappings page, navigate to Home File Services, select User Mapping or Group Mapping, and select the View Domain Mapping link. For more information on the domain-mappings-add command, refer to the Command Line Reference.

A UNIX /etc/passwd file can be imported, providing the server with a mapping of user name to UID. The /etc/groups file should also be imported to provide the server with a mapping of Group name to GID.

The server will ignore other fields from the passwd file, such as the encrypted password and the user's home directory. Users or Groups configured by importing from the /etc/passwd file will then appear in the appropriate list on the User Mappings page or the Group Mappings page.

Choose one of the three following formats and use it consistently throughout the file:

• NFSv2/3 user/group data only. The source of the user data can be a UNIX password file, such as /etc/passwd.

  When using Network Information Service (NIS), use the following command to create the file:

  ypcat passwd > /tmp/x.pwd

  The resulting file has the following format:

  john:x:544:511:John Brown:/home/john:/bin/bash

  keith:x:545:517:Keith Black:/home/keith:/bin/bash

  miles:x:546:504:Miles Pink:/home/miles:/bin/bash

  carla:x:548:504:Carla Blue:/home/carla:/bin/bash

• NFSv2/3-to-Windows user/group mappings only. Create a file with entries in the following format:

  UNIXuser="NT User", "NT Domain"

  with the following syntax rules:

  • NT domain is optional.
  • NFS user names cannot contain spaces.
  • NT names must be enclosed in quotation marks.
  • If the domain name is omitted, the server domain is assumed. If the empty domain name is required, it must be specified like this:

    users="Everyone", ""

    where the Everyone user is the only common account with an empty domain name.

• Both NFSv2/3 user/group data and NFSv2/3-to-Windows user mappings. Create a file with entries in the following format:

  UNIXuser:UNIXid="NT User", "NT Domain"

  with the same rules for NFS and NT names as for the NFSv2/3-to-Windows user mapping.

  The resulting file has entries in the following format:

  john:544="john", "Domain1"

  keith:545="keith", "Domain1"

  miles:546="miles", "Domain1"

  carla:548="carla", "Domain1"

Parent Topic

• Mixed mode operation

Child Topics

• Importing a user mapping from a file or an NIS or LDSP server
• Importing a group mapping from a file or an NIS LDAP server

  You can import group mappings from a file stored on your machine or on a network drive, or from an NIS/LDAP server.