NAS Share Tips and FAQs

Verify that all file systems used for NAS shares have the StorNext Global Super User enabled. Do the following to see if the global super user is enabled, using the vfs_snfs_tool:

1. Log in to the command line of the server.
2. Enter the following command:

> /usr/local/quantum/bin/vfs_snfs_tool -F /stornext/snfs1

Results will look similar to the following (the global super user shown in green) in this sample output:

fr_options=[DMIG, BRLS, GLOBALSU, WINSEC, RPL, XREPS_CONFIGURED],fr_blocksize=4096,fr_epoch=1529977931277320,fr_total_blocks=8371712,fr_blocks_free=7287496,fr_inode_stripe_width=1048576

3. If you don't see the global super user account listed as above, do the following to enable it for managed file systems (this is not an option for unmanaged file systems):

   1. Access the command line:
   Open an SSH connection to the server and access the command line

   Open an SSH connection to the server and use the IP address used to access the server on the Management (public) or LAN Client (private) network:

   1. Log in to the command line using the following credentials:
      • User name: stornext
      • Password: <stornext user account password>

        Note: "password" is the default password for the stornext user account. If the password has been changed, use the current password. Beginning with StorNext 7.0.2, you must change the default password for the stornext user account. As of StorNext 7.0.2, the first time you log in, you will be prompted to change the password to a different one.

   2. Enter sudo rootsh to gain root user access.
   3. Enter the password for the stornext user account again.

   Note: If the password for the stornext user account was changed after installation, use the current password.

   2. Edit the managedFS file. Use the following command which opens the editor and creates a new file (if one doesn't already exist on the server based on a template for this file):

   Pro Tip!

   You can use vi commands to edit the file. See this helpful site for basic vi commands.

   sncfgedit -n managedFS

   If the file doesn't exist on the server yet, you will see the following output (otherwise, continue to step d):

   Attempting to get managedFS's config file

   Unable to find config file for managedFS

   No config file for managedFS exists. Do you want to create one? (y/n)

   3. Enter y to create the new file.
   For new files
   If you created a new file, you may see notes inside comment tags that indicate this file was created from a template file. ("..." indicates additional content follows this section):
   **** NEW CONFIG TEMPLATE FILE ***
   **** YOU MUST EDIT THIS FILE AND REMOVE THIS AND THE ABOVE LINE BEFORE CLOSING *****
   ...
   To remove the first line of the file using vi commands:
   1. Move the cursor with your arrow keys until the cursor is blinking over the first line.
   2. Enter the letters "dd" to delete the first line.
   3. Enter the letters "dd" again, to delete the next line.
   4. Search for the globalSuperUser entry. The file contents will look similar to the following:

   Note: For a new file, the globalSuperUser entry will be shown as true, as shown in green below. Continue to step e.

   Example (new "managedFS" file)

   ...

   <?xml version="1.0"?>

   <snfs:configDoc xmlns:snfs="http://www.quantum.com/snfs" version="1.0">

   <snfs:config configVersion="0" name="managedFS" fsBlockSize="4096" journalSize="67108864">

   <snfs:globals>

   <snfs:affinityPreference>false</snfs:affinityPreference>

   <snfs:allocationStrategy>round</snfs:allocationStrategy>

   <snfs:haFsType>HaUnmonitored</snfs:haFsType>

   <snfs:bufferCacheSize>268435456</snfs:bufferCacheSize>

   <snfs:cvRootDir>/</snfs:cvRootDir>

   <snfs:storageManager>false</snfs:storageManager>

   <snfs:debug>00000000</snfs:debug>

   <snfs:dirWarp>true</snfs:dirWarp>

   <snfs:extentCountThreshold>49152</snfs:extentCountThreshold>

   <snfs:enableSpotlight>false</snfs:enableSpotlight>

   <snfs:spotlightUseProxy>false</snfs:spotlightUseProxy>

   <snfs:enforceAcls>false</snfs:enforceAcls>

   <snfs:fileLocks>false</snfs:fileLocks>

   <snfs:fileLockResyncTimeOut>20</snfs:fileLockResyncTimeOut>

   <snfs:forcePerfectFit>false</snfs:forcePerfectFit>

   <snfs:fsCapacityThreshold>0</snfs:fsCapacityThreshold>

   <snfs:globalSuperUser>true</snfs:globalSuperUser>

   <snfs:ignorePermissions>false</snfs:ignorePermissions>

   "/tmp/tmp_managedFS_cfg-PFxGn" 119L, 7899C

   Change false to true, if needed
   If the entry for globalSuperUser in the file is false, change the value to true. To do this using vi commands:
   1. Move the cursor with your arrow keys until the cursor is blinking over the word false.
   2. Enter the letter "x" one character at a time until you have deleted the word false.
   3. Enter the letter "i" to enable the text insertion mode, and then type the word true.
   5. Save the file and exit using vi commands (this command exits the command [":"], writes the file ["w"], and then quits the vi editor ["q"]):

   :wq

   6. Enter exit to exit the rootsh account.
   7. Enter exit to exit the stornext account and close your SSH session.

1. Open a browser and access the StorNext GUI.
2. Navigate to Configuration > File Systems, and select the managed file system that you need to enable the Global Super User for.
3. Click Edit.
4. Open the Advanced Parameters section of the page, and select the Special Tab.
5. Click the box next to Global Super User. Make sure this box is checked:
Example

You can create hard links on the Samba server to use from the Mac SMB client.

You can add shares to the directory by issuing the share add command. Keep in mind that you will need to create the share directory before issuing this command.

See Add Shares.

You can re-issue the auth config ads command with one of the following ID map options:

RID

The Relative Identifier (RID) ID map option converts a Security Identifier (SID) to an RID, using an algorithm that allows all Quantum appliances to see the same UID.

TDB

The Trivial Database (TDB) ID map option tells Samba to generate UIDs and GIDs locally on demand.

See Apply AD Authentication To NAS.

Apple SMB clients do not recognize offline (truncated) files. If you use Finder along with Show icon preview to locate a file, the process will attempt to read each file — including offline files — in the folder to generate a preview. This process causes the SMB connection to hang while trying to retrieve offline files.

To avoid this issue, we recommend disabling Show icon preview. We also recommend against using Finder so that a file retrieve is not generated.

Apple SMB clients save file attributes in the Apple Double File. Every time that Finder is used or that the ls -l command issued, the Apple SMB client reads the saved file attributes. Depending on the Archive destination, the file retrieves can cause the SMB connection to hang if offline (truncated) files are included in the Apple Double File.

To avoid this issue, ensure that the Apple Double File is excluded from the truncation policy. Perform this exclusion from the primary node by populating the /usr/adic/TSM/config/excludes.truncate file with the following line:

BEGINS:._

Note: If the /usr/adic/TSM/config/excludes.truncate file does not exist, you need to create it on the primary node.

If an NFS client tries to access an offline file under Storage Manager Control, the process could hang until the file becomes available.

To avoid this issue, use the dmnfsthreads=<value> mount option.

For more information, see StorNext 5 Man Pages Reference Guide.

If you attempt to mount an NFS share on an OS X client, you may receive an Operation is not permitted … error message. This error can occur when OS X clients cannot mount NFS shares that are exported with secure options.

Resolution

Perform one of the following steps to resolve this issue:

• Include the resvport option when mounting the NFS share.

  Example Command: Issued from OS X terminal

  $ mount_nfs –o resvport server:/path directory

• Include the insecure option when adding or changing options for an NFS share

  Example

  > share add nfs myshare /stornext/snfs/myshare ro,insecure

The updated NFS failover functionality in the Appliance Controller 2.0 release requires that each NFS share has a unique StorNext File System ID (fsid) value. Earlier versions of the Appliance Controller and StorNext NAS did not enforce fsid values being assigned to NFS shares. Therefore, if you are upgrading to Appliance Controller 2.0 from earlier versions, you will have NFS shares that do not have an fsid value or NFS shares that have colliding fsid values.

Resolution

1. Unmount the share from the client.
2. Disable and then re-enable NFS failover using the nascluster set nfs-ha (yes | no) [force] command. For instructions to disable and re-enable NFS failover for both NFSv3 and NFSv4, see Enable NFSv4 Failover NFSv4 Failover OverviewImportantIn an environment that does not use NFSv4 failover for NAS clusters, NFSv3 services are automatically enabled. However, you can use the nascluster set nfs-ha (yes|no) [force] command to enable or disable any NFS failover service used in your environment. Note: For a list of all the Appliance Controller commands, see the Command Index.NFSv4 Failover Compatibility:NAS clusters with NFSv4 failover is supported only on the following systems:Dual-server node Xcellis Workflow DirectorDual-server node Xcellis Foundation (upgraded from single-server node configuration)Artico (R630)These systems operate in an active/passive NAS failover configuration.When configuring this type of NAS cluster, keep the following in mind:This configuration does not support scale-out NAS clustering. You can upgrade this configuration to a scale-out NAS cluster by disabling NFSv4. By enabling NAS failover for NFSv4, you are also requiring that all clients connecting to the NAS cluster are running NFSv4. This version of NFS is required to support lock recovery after failover.For more information about NAS failover and supported NAS cluster configurations, see NAS Cluster Overview.PrerequisitesMake sure to perform the following steps before configuring NFS shares in a cluster for NAS failover.Verify that all clients accessing the NFS shares are unmounted.Verify that all clients connecting to the cluster are running NFSv4.If your clients are running on a Windows OS, you will need to download a third-party NFSv4 client for Windows.In addition to running NFSv4, verify that all clients are running CentOS versions 6.4, 6.5, 6.6, or 6.7. Only these versions have been validated in supporting lock recovery.ImportantNFSv4 failover is supported with NFSv4 version 4.0. Lock failover does not work with NFSv4 version 4.1Verify that all nodes within the NAS cluster are running on an Xcellis Workflow Director (CentOS7). Only Xcellis Workflow Director supports the NFSv4.1 lock recovery feature.ImportantFor dual-server node Xcellis Workflow Director, dual-server node Xcellis Foundation, and Artico (R630) systems, StorNext NAS should be configured on the LAN client network. In addition, the IP addresses reserved for both nodes of the NAS cluster and the NAS VIP must be configured on the LAN client network. If you use another network port, the NAS cluster will fail to configure correctly. To Enable NFSv4 FailoverUnmount all clients.After configuring the NAS cluster for NFSv4 failover, you must remount the clients through the NAS VIP.Log in to the Appliance Controller CLI.Enter:nascluster set nfs-ha (yes|no) [force]The parameter is:<yes|no>Enter yes to enable NFS failover on the NAS cluster.Enter no to disable NFS failover on the NAS cluster.[force]If this option is included, then the command is issued without confirmationIf this option is not included, then you must confirm the command.Duplicate Request CacheWhen NAS failover occurs in a NAS cluster of NFS shares, the duplicate request cache is not preserved and the new server cannot recover it. The cache is stored in memory..
3. Remount the share on the client.