Open topic with navigation

Disconnected: You’re looking at a local copy of the Appliance Controller Documentation Center. The most current version is online at www.quantum.com/accdocs.

# NAS Share Tips and FAQs

Why did I receive an "EACCESS (-13)" error when adding a new share to a NAS cluster?

StorNext file systems require the StorNext global super user to be enabled for NAS shares on Managed File Systems. There are two methods to enable this:

Enable the Global Super User from the command line

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. The first time you log in, you are 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.

OR

Enable the Global Super User in the StorNext GUI

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

Are defined NAS share paths case-sensitive?

Share paths are compared in a case-insensitive manner.

Example (these two paths are considered identical):

`/stornext/SNFS1/MYPATH`

and

`/stornext/snfs1/mypath`

Rules

1. No two shares, regardless of type, may have an identical path if a portion of the path names uses a different case.

Example 1 – not allowed (the following two share paths are equivalent; this IS NOT supported):

smb1: /stornext/SNFS1/MYPATH

and

smb2: /stornext/snfs1/mypath

Example 2 – not allowed (the following two share paths might have been intended to be used to point to the same location (see rule 2), but are not equivalent; this is NOT supported):

smb1: /stornext/SNFS1/MYPATH

and

nfs1: /stornext/snfs1/mypath

2. Shares for different types (smb and nfs) can use an identical path, but the case used for the share must match.

Example – allowed (these two share paths ARE equivalent; this IS supported)

smb1: /stornext/SNFS1/MYPATH

and

nfs1: /stornext/SNFS1/MYPATH

3. No two shares of the same type (smb or nfs) can have an identical path, regardless of case.

Example – not allowed (these two share paths are equivalent; this IS NOT supported):

smb1: /stornext/SNFS1/MYPATH

and

smb2: /stornext/SNFS1/MYPATH

Why can't my Mac SMB client create hard links?

Mac SMB clients may not be able to create hard links even though Unix extensions have been enabled on the SMB share.

Resolution

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

Why am I receiving an error when issuing the "share create" command?

If you use AD authentication with the RFC2307 ID map option and issue the `share create` command, the system will return the following error:

user 'administrator' not found (E-5060)

When issued, the `share create` command assigns default ownership settings. If you have configured NAS to use AD authentication with the RFC2307 ID map option, the share directories will have the UID and GID assigned by the RFC2307 ID map option. However, Samba does not recognize the UID, and rejects the `share create` command as a security violation.

You can do one of the following to resolve the issue.

Use the "share add" Command

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.

Reconfigure AD Authentication with the RID or TDB ID Map Option

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.

Are there any issues with sharing volumes under StorNext Storage Manager control?

If you share volumes under Storage Manager Control, you could experience the following issues.

Offline File Retrieval Hangs for Apple SMB Clients

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.

Offline File Retrieval Hangs for Apple Double Files

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.

Offline File Retrieval for NFS Clients

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.

Why are my clients unable to mount shares?

This issue can occur in the following 2 scenarios.

macOS X Clients Cannot Mount NFS Shares

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

NFS Client Cannot Mount a Share

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.
3. Remount the share on the client.

Why is the Appliance Controller reporting incorrect information about my NAS shares?

If you run the `df` command from an OS X system, the Appliance Controller could report invalid or misleading information about your NAS shares.

Why shouldn't I share a directory for both SMB and NFS?

Note: As of Appliance Controller release 3.0, this restriction no longer exists.
Quantum recommends upgrading to Appliance Controller 3.0.1 or later. See .Appliance Controller Upgrades

For Appliance Controller releases prior to 3.0.1:

If you attempt to share a directory over both SMB and NFS protocols, you risk file corruption, stale file locks, and other file access issues in the share. Because of these incompatibility issues, we strongly recommend against sharing a directory over both SMB and NFS protocols.

For additional information, see https://access.redhat.com/solutions/1983.

6-68456-07_RevA | Initial publication date: Friday, December 22, 2017 | Last updated on Monday, January 12, 2026.

Open topic with navigation