Tip: Because ownership of an existing file set path cannot be changed when you are creating a share or export that contains user files or data, ensure that the ownership and corresponding ACLs of all of the directories in the entire path to which the file set is linked are correct. Do this task before you create a share or export on an existing path that contains user files or data.

Tip: When a file system or file set is created, and the owner is not specified, the default owner/group/permissions of the new path is root/root/700.

Tip: This requirement is true even when ACLs are configured with inheritance. Owner specification does not affect ACL settings, including group ACL definitions.

Note: The CLI and GUI do not provide any means to configure or manage the external authentication server.

Important: Obtaining this administrative information is an important requirement for SONAS or IBM Storwize V7000 Unified configuration.

Tip: Netgroups, which are managed by LDAP, are supported.

Tip: The SFU schema extension or W2003R2 is required. NIS in extended mode can be used for netgroups. This is often considered the preferred practice method for SONAS authentication, and the easiest service to maintain overall.

Tip: The SONAS system supports NIS as an extension over AD/Samba PDC in two modes, either netgroups only or netgroups and ID mapping. In the latter mode, ID mappings are stored on, and read from, the NIS server.

Important: The information on the SONAS system for the home directory and template shell are more restrictive than what must be applied on the client. The previously shown example does not provide or apply such settings, and only describes the information that is required for UID/GID to be consistent on all the clients and the SONAS system.

Note: (-) means not selected and (X) means selected in the output in Example 6-1.

NFSv4.0 on SONAS 1.5.1: For SONAS 1.5.1 and later, support for NFSv4.0 is added. This version is the IBM implementation of the NFSv4 protocol. This implementation also supports the NFSv3 protocol.

Tip: SONAS v1.5.1 and later provides support to view and modify ACLs by using either the CLI or the GUI. For more information, see the Authentication chapter in IBM SONAS Implementation Guide, SG24-7962.

Remember: The preceding restriction does not apply to SONAS version 1.5.1 and later. The inheritance behavior of ACLs matches the Windows behavior and also now supports Creator Owner and Creator Group entries.

Tip: Setting the --bypassTraversalCheck option enables a user to directly access files and folders that the user owns, and that are contained under parent folders for which the user does not have Read or Write permissions. Users without Read and Execute access to the share or export in which the user-owned files and folders are located can Read and Modify the files inside the export for which the user has permissions granted by the --bypassTraversalCheck option. However, in this case, operations like Rename file and Delete file are not granted by default. This is normal CIFS behavior. Modify ACLs as required to enable these operations.

Tip: Changing the POSIX bits of a GPFS file system triggers a modification of the file system’s GPFS NFSv4 ACL, including the deletion of some ACEs. Because the SONAS system uses GPFS NFSv4 ACLs for access control, SONAS administrators should avoid changing the POSIX bits of files that are stored on the SONAS system, unless these specific GPFS NFSv4 ACL modifications and ACE deletions are clearly intended.

Tip: Depending on the default ACLs and the usage of inheritance, the directory might become inaccessible. This might be the case when the ACLs are not inherited from the owning directory, and no owner has been specified. In this case, the directory is owned by the default owner root, and therefore inaccessible to users.

Important: Disabling this option (setting it to a value of no) increases the risk of possible data loss if there is a node failure. Tip: This option applies only to file system data, not metadata.

Attention: This option should only be used if data integrity is ensured on the application level (rather than the protocol level). The applications must ensure that files/directories are not modified by multiple processes at the same time, and that reading of file content does not happen while another process is still writing the file. Alternatively, if the application is coordinating all file accesses to avoid conflicts. Without locking, the consistency of files is no longer guaranteed on protocol level. If data integrity is not ensured on application level this can lead to data corruption. Tip: When the --cifs option coherency has a value other than yes, the lsexport SONAS CLI command displays the coherency value of a share or export.

Attention: The CIFS protocol does not include a built-in failover capability to transparently reestablish a lost CIFS connection. If a CIFS connection to the SONAS system is lost due to a failover or a network event, the CIFS client must establish a new CIFS connection and reopen all of the file handles that were previously open when the connection was lost. This is a limitation of the CIFS protocol. The SONAS system synchronizes file data to disk only when it receives a close request for a file. If an SONAS interface node failover occurs during a write request, the most recent changes might not be written to disk. Therefore, only file changes that were both written and closed are always saved, and CIFS clients might experience corrupted files for any files that were open for write at the time of failover.

Note: The preferred practice is to use a fully qualified domain name when connecting to shares. If your organization has a flat domain name server (DNS) namespace, this is less important, but in a large organization with an internal DNS hierarchy, using the full name means the server will be found even if the client moves around the organization.

Tip: Connecting by using CIFS from IBM AIX is not supported.

Tip: Linux clients that are running the CIFS protocol with a version of CIFS before version 1.69 might experience issues that are related to I/O transactions. Use CIFS version 1.69 or higher installed on the client to improve reliability.

Netgroup database	Authentication	ID mapping	SONAS release	CLI commands to configure
NIS	None	None	1.1.1	cfgnis
NIS	Active Directory	Auto	1.1.1	cfgad, cfgnis
NIS	Active Directory	SFU	1.3.1	cfgad, cfgsfu, cfgnis
LDAP	LDAP	LDAP	1.3.1	cfgldap

Note: Local authentication scheme available in SONAS 1.5.1 does not support netgroups.

Tip: The host name in the netgroup definition must have both forward and reverse DNS lookup configured, so that the SONAS system can resolve both the host name and the host IP address, with which the mount service is requested on the SONAS system. Otherwise, a mount request fails with an access denied error.

Tip: NFS clients are responsible for maintaining data integrity when a server restarts, crashes, or fails over. In the NFS protocol, the NFS client is responsible for tracking which data is destaged, for detecting that a server has crashed before destaging all data, and for tracking which data must be rewritten to disk.

Tip: By default, an AIX client (much like a MAC OS client) uses non-reserved ports. However, the SONAS system rejects requests from non-reserved ports. To enable the use of reserved ports on an AIX client, submit the AIX command nfso -p -o nfs_use_reserved_ports=1.

Tip: The mount command is an administrative command unless the administrator gives access privileges to users that include the ability to mount devices. The NFS mount point might already be configured by the administrator.

Important: The FTP protocol does not use encryption. The user name, password, and the file contents are sent across the network in plain text. When possible, use SCP rather than FTP.

Note: The share or export name is optional. If you do not provide the share name, a listing of all available shares will be presented.