Purpose	Use the attach command to attach (or map) a back-end directory to the current share. The ARX volumes clients can then see this back-end directory as though it was one of the volumes directories. Use the no form of the command to remove the attachment.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	attach attach-point-directory [to physical-directory] [access-list map-name]   attach-point-directory (1-256 bytes of UTF-8-encoded characters) is the relative pathname within the direct volume. This creates a new virtual directory, visible to clients. to physical-directory (optional, 1-256 bytes of UTF-8-encoded characters) is the physical directory on the share relative to the share export point. If omitted, use the same name as attach-point-directory. To attach to the root of the back-end share, use a period (.). map-name (optional, 1-64 characters) is the NFS access list to associate with the share.     no attach attach-point-directory   attach-point-directory (1-4096 bytes of UTF-8-encoded characters) is the relative pathname within the volume. This creates a new virtual directory, visible to clients.
Default(s)	None.
Guidelines	This command only applies to a share in a direct volume. It has no effect in a managed volume. Use the show server-mapping command to view the current mappings. Clients can mount any level of the attach-path directory. For example, suppose you create a /etc volume with a /bin/local attach point; clients can mount /etc, /etc/bin, or /etc/bin/local. Mounting a directory below that point would defeat the purpose of federating the attach points into a direct volume, so it is not supported.
Sample(s)	bstnA(gbl-ns-vol-shr[wwclim~/temp~zones])# attach mid-atl attaches a direct-mapped directory named mid-atl to the wwclim~/temp~zones share.
Related Commands	namespace -> volume -> share direct nfs-access-list show server-mapping

Purpose	A managed volume has a limited number of file credits, where one credit is required for each of its files and directories. By default, the volume automatically increases its allocation of file credits as needed. This is a desirable situation unless the volume is used as follows: A direct volume uses this volume as it would use an external filer (with the filer or managed-volume commands), and the direct volume supports NFS. The direct NFS volume cannot function properly if both of the above conditions are true; the direct volume requires an unchanging number of file credits in all of its filers. You can use no auto reserve files for a managed volume behind an NFS direct volume. This is especially important if the direct volume is on a remote ARX, which cannot detect the configuration issue. Use the affirmative form, auto reserve files, to allow the managed volume to automatically reserve its own file credits.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	no auto reserve files auto reserve files
Default(s)	auto reserve files
Guidelines	The auto-reserve-files feature is recommended for most managed volumes. You only need to disable it if the managed volume is being used as an NFS filer by a direct volume. This command has no effect on a direct volume itself.
Sample	bstnA(gbl-ns-vol[ns1~/etc])# no auto reserve files disables automatic file reservations in the ns1~/etc volume. This makes it safe to use this volume as a filer in an NFS-supporting direct volume.
Related Commands	namespace -> volume direct managed-volume show namespace show global-config namespace

Purpose	A managed volumes metadata contains information about names and locations of all files on all of its back-end filers. A filer application, such as anti-virus software, could possibly move, delete, or rename a file without the volumes knowledge; this obsoletes the metadata about the file. If a CIFS user receives an error that indicates that a files metadata is incorrect (the file is missing), the managed volume can automatically launch a sync operation to synchronize the metadata with the filer contents. Use the auto sync files command to allow the current volume to automatically synchronize its metadata. Use no auto sync files to disable automatic synchronizations.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	auto sync files [rename-files] no auto sync files [rename-files]   rename-files (optional) allows the volume to rename a newly-discovered file that collides with another file in the volume. (Two files are said to collide when they share the same path and name on their respective back-end shares.)
Default(s)	disabled
Guidelines	For NFS-only volumes, or for volumes where automatic synchronization is disabled, you can use the sync files command to manually launch a sync-files operation. You must also use the manual command for files that are created on the back-end filer; the auto-sync operation only works for missing files. Directory syncing is not automated by this command; use sync directories to synchronize the volumes metadata with new directories that may have been created at the filer. Each auto-sync operation has a unique job ID and generates a report of its progress. The reports follow this naming convention: auto-sync.sync-job-id.volume.rpt. Use show reports to list all reports, including auto-sync reports. To follow the progress of the auto-sync operation, you can use tail reports report-name follow. The show sync command shows the current status of one or more sync operations. You can use the wait-for sync command to wait for the operation to complete. To cancel the operation, use cancel sync. If the rename option is off, a newly-discovered file is not synchronized in the metadata unless its path is unique in the volume. If the option is enabled, a conflicting file is renamed as follows: myfile.txt on the bills share becomes myfile_bills.32.txt, assuming the auto-sync-job ID is 32.
Guidelines: Access-Based Enumeration (ABE)	CIFS shares on some back-end filers use a security feature called Access-Based Enumeration (ABE) that can complicate auto-sync operations. An ABE-enabled share provides customized directory listings for every client, where the directory listing only shows files and directories where the client has read access. A managed volume examines a clients directory listing before forwarding it to the client; if a file is missing from that listing due to ABE, the volume logs that the file is missing and performs extra processing to find that it is still in the directory. To dampen this logging and help the volume software to work around ABE-based file listings, use the cifs access-based-enum command.
Samples	bstnA(gbl-ns-vol[medarcv~/usr])# auto sync files rename-files allows automatic metadata synchronization in the medarcv~/usr volume. If any newly-discovered files would collide with other files in the volume, the volume is allowed to rename them.   bstnA(gbl-ns-vol[medarcv~/rcrds])# no auto sync files disables auto sync in the /rcrds volume.
Related Commands	namespace -> volume sync files show sync wait-for sync cancel sync cifs access-based-enum show namespace show global-config namespace

Purpose	The cancel import command stops a managed volume from importing a share.
Modes	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	cancel import namespace ns volume vol-path share share-name   ns (1-30 characters) is the namespace where the import is occurring. vol-path (1-1024 characters) specifies the namespace volume. share-name (1-64 characters) is the share that is being imported. Use show namespace status for a list of shares that are in the process of importing.
Default(s)	None
Guidelines	After canceling a share import, you must remove the share from the managed volume. You have three options: 1. Use remove-share migrate to migrate all imported files to another share in the volume. 2. Use remove-share nomigrate to avoid migrating any imported files, thus causing them to disappear from the view of the volumes clients. This command copies all imported directories to another share in the volume, and if the share is later re-imported, the directories use the new share as their home. 3. Use no enable (gbl-ns-vol-shr) and nsck ... rebuild to remove all imported files and directories from the volume. This causes files and directories to disappear from client view. It also forces all of the volumes NFS clients to re-mount the share (CIFS clients are briefly disconnected, which may go unnoticed).
Sample	bstnA# cancel import namespace ns volume /vol share testrun Storage job cancelled successfully. bstnA# cancels the import in progress for the ns~/vol~testrun share.
Related Commands	enable (gbl-ns-vol-shr) show namespace status remove-share migrate remove-share nomigrate nsck ... rebuild

Purpose	A back-end CIFS share with Access-Based Enumeration (ABE) provides customized directory listings to its clients; a directory listing only contains files and folders where the client has read access. Managed-volume software mistakenly assumes that the missing (read-only) files and directories are metadata inconsistencies, and fills them back into the directory listing. Clients of the managed volume therefore see all files and directories, whether or not they have permission to read them. This defeats the purpose of ABE. Use the cifs access-based-enum command to inform the volume that its back-end shares have ABE enabled, and prevent the volume from revealing inaccessible files and subdirectories to its CIFS clients. (This command has a lesser effect in direct volumes, explained in the Guidelines below.) Use no cifs access-based-enum in a volume backed by shares with ABE disabled.
Modes	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	cifs access-based-enum [auto-enable] no cifs access-based-enum   auto-enable (optional) automatically enables ABE on the back-end share when you first invoke enable (gbl-ns-vol-shr) and import the share. (Each of the volumes shares must have the import sync-attributes setting for this operation to succeed.) This ensures ABE consistency for all of the volume shares that you import from now on, and is therefore recommended.
Default(s)	no cifs access-based-enum
Guidelines	This command does not apply to a volume in an NFS-only namespace. An ARX volume with multiple shares should have a consistent ABE setting for all of them. ABE is enforced at the back-end share, not the ARX. If one back-end share has ABE enabled and another share does not, restricted files may seem to appear and disappear if they migrate between those two shares. The CLI prompts for confirmation if the managed volume already contains any shares with conflicting ABE settings; enter yes to proceed. If you use the auto-enable option, the volume software replicates all ABE settings between the volumes back-end shares at share-import time. (Share-import time is the first time each share is enabled, or the first time they are enabled after someone runs nsck ... destage or nsck ... rebuild on the volume.) If the volume was enabled without ABEs auto-enable flag, or if back-end shares otherwise have inconsistent ABE settings, you can use the [no] cifs access-based-enum (priv-exec) command. This priv-exec command enables (or disables) ABE on all of the filer shares behind a volume. This command has no effect on any shares that have already been imported. The command sets a flag that the volume software uses during share import. The volume software otherwise ignores the flag. In a direct volume, the back-end settings for ABE have complete control over the volumes ABE behavior. This command only controls whether or not a direct volume advertises that it supports ABE (as described below).
Guidelines: ABE Restrictions on Shares	After you enable ABE in the volume, the volume enforces ABE consistency on any imported shares or subshares. The enable (gbl-ns-vol-shr) command cannot succeed for a share if its ABE setting differs from that of the volume. The auto-enable flag resolves this by enabling ABE on the filer at share-import time. Each new share must have the import sync-attributes setting for this to succeed. For shares on filers that cannot support ABE, you can use the cifs access-based-enum exclude command on the share. This last command is not generally recommended, as it creates ABE inconsistencies that are confusing to clients, but it may be necessary to support your set of CIFS filers. ABE is not supported on filers before Windows 2003 R1, NetApp 7.2.3, or EMC 5.5. ABE is also not supported on any current release of Samba. Some filers cannot consistently support CIFS ACLs at all, and therefore preclude any ABE support in the volume. If the volume is backed with any of these filers, you must set no persistent-acls at the volume before it can import from them. The volume therefore ignores ACLs entirely. A volume with this setting cannot reliably support ABE, because ABE depends on the permissions settings in file ACLs.
Guidelines: Volume Responses to the abecmd.exe Utility	The abecmd.exe utility, freely available from Microsoft, can query remote shares to determine whether or not they have ABE enabled. If a front-end export (gbl-cifs) for this volume receives such a query, this command determines how to answer it. The abecmd.exe utility cannot change the ABE setting for an ARX CIFS service, because this command controls ABE at the ARX-volume level. A change to ABE in one ARX-CIFS share would change ABE in all of the shares that export the same ARX volume. A direct volume does not probe its shares for their ABE settings, so the cifs access-based enum command has a lesser effect in direct volumes. It only determines how to answer the ABE query from the abecmd.exe utility. The back-end shares have complete control over whether or not ABE is enabled in a direct volume.
Samples	bstnA(gbl-ns-vol[medarcv~/lab_equipment])# cifs access-based-enum sets the medarcv~/lab_equipment volume for ABE processing. This is a managed volume, so it no longer allows anyone to enable (gbl-ns-vol-shr) new shares (and import them) with ABE disabled.
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# no cifs access-based-enum   This volume still contains at least one share with access-based enumeration (ABE) enabled. Disabling ABE on the volume without also disabling ABE on all the volume's shares may result in user access problems.   Are you sure you want to disable ABE behavior for this volume? [yes/no] yes
	sets the medarcv~/lab_equipment volume to discontinue all ABE processing. The volume presumes that file listings from all clients should be consistent for a given directory, and corrects any inconsistencies it finds. This would defeat the purpose of ABE, so ABE should be disabled for all back-end shares behind the volume. From priv-exec mode, you can use no cifs access-based-enum (priv-exec) to disable ABE at all of the volumes back-end shares, too.
Related Commands	namespace -> volume cifs access-based-enum (priv-exec) cifs access-based-enum exclude import sync-attributes

Purpose	A back-end CIFS share with Access-Based Enumeration (ABE) provides customized directory listings to its clients; a clients directory listing only contains files and folders where he or she has read access. The filers behind the volume create these customized listings and the managed volume passes them back to clients. Each of the volumes shares has a separate setting to determine whether or not ABE is enabled. If ABE is enabled at the managed volume, it should also be enabled at all of the volumes backing shares. From priv-exec mode, you can use the cifs access-based-enum command to enable ABE on all of a volumes back-end shares and subshares at once. Use no cifs access-based-enum to disable ABE on all of the back-end shares and subshares behind the volume. This is appropriate for a situation where ABE is disabled on the volume.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	cifs access-based-enum ns vol-path [force] no cifs access-based-enum ns vol-path [force]   ns (1-30 characters) identifies the namespace that contains the ABE-enabled volume. vol-path (1-1024 characters) specifies the managed volume where you want to fully enable ABE. force (optional) tells the operation to enable ABE even on filer shares that are configured but not yet enabled.
Default(s)	None.
Guidelines	This command does not apply to a direct volume or a volume in an NFS-only namespace. The ABE-enable operation produces a report to show results from each back-end share. The report name appears after you enter the command, along with a summary of the overall results. This command is an alternative for using Microsofts abecmd.exe utility on each filer. For any share with cifs access-based-enum exclude, this attempts to disable ABE. The no form of this command disables ABE on all of the volumes back-end shares. Directly before or after disabling ABE at the volumes filers, use the no cifs access-based-enum command to disable ABE on the volume itself. The CLI prompts for confirmation before disabling ABE on any back-end filers; enter yes to proceed. If the volume has ABE disabled while a backing share has ABE enabled, clients may see the following error in their directory listings: 02/24/2009 04:17 PM 9 myFile.doc The parameter is incorrect. This error indicates that the file or directory (myFile.doc in the above example) resides on a back-end share with ABE enabled. CIFS clients only see the results of this command if they connect after you invoke it.
Guidelines: Windows Server Clusters	Some Windows filers are nodes in a larger Windows Server Cluster. A server cluster is a Windows redundancy feature. The ABE-enable or ABE-disable operation only occurs on the currently-active node for any server cluster behind the volume. If the cluster fails over, ABE support is likely to be inconsistent on the newly-active node. After you run this command, go to the clusters administrative interface and manually enable ABE; this applies the ABE setting to all nodes in the cluster. If the clusters interface does not offer an option for ABE, use the abecmd.exe utility to individually set it at each node. As an alternative, you can trigger a failover at the cluster and then re-run this command.
Samples	bstnA# cifs access-based-enum medarcv /rcrds   % INFO: Changed access-based enumeration settings for 13 of 13 shares. There were 0 errors and 0 shares were left unchanged. See report 'cifsAbeChange_20100227014459.rpt'. enables ABE on every filer share behind the medarcv~/rcrds volume. Refer to Figure 22.1 for a sample report.   stkbrgA# cifs access-based-enum bgh /naumkeag_wing force ... enables ABE on every filer share behind the bgh~/naumkeag_wing volume. This also enables ABE on shares that are not yet enabled in the /naumkeag_wing volume.
bstnA# no cifs access-based-enum medarcv /lab_equipment   Volume medarcv~/lab_equipment is not configured for access-based enumeration (ABE). Disabling ABE on this volume's shares will bring them into agreement with the volume configuration.   Proceed to disable ABE for this volume's shares? [yes/no] yes   % INFO: Changed access-based enumeration settings for 3 of 3 shares. There were 0 errors and 0 shares were left unchanged. See report 'cifsAbeChange_200903031058.rpt'.
	disables ABE on every filer share behind the medarcv~/lab_equipment volume. The medarcv~/lab_equipment volume is now prepared to have ABE disabled.
Related Commands	namespace -> volume cifs access-based-enum cifs access-based-enum exclude

Purpose	A back-end CIFS share with Access-Based Enumeration (ABE) provides customized directory listings to its clients; a directory listing only contains files and folders where the client has read access. A managed volume with ABE enabled should have ABE enabled at all of its back-end shares. You can use this command to exclude a share whose backing filer cannot support ABE (such as a Samba filer). This option is designed for a tiered volume, where a lower tier of storage may be on an older or less-expensive filer that does not support ABE. Use the no form to declare that the current shares back-end filer can now support ABE.
Modes	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	cifs access-based-enum exclude no cifs access-based-enum exclude
Default(s)	no cifs access-based-enum exclude
Guidelines	This command does not apply to a share in a direct volume or an NFS-only namespace. It only applies to a managed-volume share where cifs access-based-enum is enabled. This command is not recommended for all sites: a managed volume should typically have consistent ABE settings with all of its back-end filers.
Warning: If ABE is enabled on share A but disabled on share B, a client without permission to read the xyz.doc file sees the file disappear if it migrates to share A. The same client sees the xyz.doc file reappear if it migrates back to share B where ABE is disabled. This inconsistency can be confusing.
	The command is designed for volumes where the above confusion is unavoidable. To mitigate the confusion, place all ABE-excluded shares on the lowest tier of storage in the volume. Do not mix any ABE-enabled shares on the same tier. Also, do not use any combination of place-rules or share-farms that mix files between shares with different ABE settings, other than the place-rule(s) that enforce the tiering policy. If the managed volume has ABE enabled but the current shares filer cannot support ABE, you require this command to allow an enable (gbl-ns-vol-shr) for the share. A managed volume stops a share from importing if the volume has ABE enabled and the back-end share does not. The no form of this command informs the volume that ABE is now supportable at the back-end share. This can occur after a filer upgrade. If the volume has ABE enabled, you can use this command to remove the current shares exclusion from ABE. If necessary, you can then use the cifs access-based-enum (priv-exec) command to enable ABE on all the volumes back-end shares at once.
Sample	bstnA(gbl-ns-vol-shr[ns2~/vol1~sh5])# cifs access-based-enum exclude excludes the sh5 share from ABE support in the ns2~/vol1 volume.
Related Commands	namespace -> volume cifs access-based-enum enable (gbl-ns-vol-shr) cifs access-based-enum (priv-exec)

Purpose	Some back-end CIFS shares support case-sensitive file names, where file.txt and FILE.txt are stored as two different files. Other CIFS filers and file servers use both names to refer to the same file. (The same is also true of many CIFS-client applications.) A volume that supports CIFS cannot support case-sensitive names unless all of its back-end shares also support them. If that is the case, and if your CIFS clients also support them, you can enable case-sensitive naming support in this volume with cifs case-sensitive. Use no cifs case-sensitive to stop the volume from supporting case-sensitive names.
Modes	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	cifs case-sensitive no cifs case-sensitive
Default(s)	no cifs case-sensitive
Guidelines	This command can only function in a CIFS-only namespace. It does not apply to an NFS-only namespace, and is not allowed in a multi-protocol (CIFS and NFS) namespace. You can only enable CIFS-case sensitivity if all the back-end shares behind the volume support it.
Guidelines: Disabling Case Sensitivity	You may want to add a share that cannot support case-sensitivity to a CIFS volume that previously supported it. For those situations, you can disable case sensitivity with the no cifs case-sensitive command. The volume must be offline to disable case sensitivity: first use nsck ... destage to take the volume offline, then run the no cifs case-sensitive command, and then re-enable all of the volumes shares. In a CIFS volume with case sensitivity disabled, two files or directories whose names differ only in case are said to have a case collision. For example, there would be a case collision between the \dir directory and \Dir. If you disable case sensitivity in a running volume, your pre-existing files and directories may have one or more case collisions. After bringing the volumes shares back online, the volume reacts to case collisions based in the settings of certain CLI commands: if no modify is set, any share with a case collision fails its import; if modify is set, the volume uses the renaming rules set by the CLI commands below. import rename-files import sync-attributes import rename-directories Check each shares import report for a list of all renamed or altered files or directories in the share. Use show reports type Imp for a list of all import reports; there is one for each imported share. Look in the import report for files and/or directories labeled CC (Case Collision).
Samples	bstnA(gbl-ns-vol[win-ns~/vol])# cifs case-sensitive sets the current CIFS volume to support case-sensitive naming. A file named myFile can co-exist with a different file named MyFile.   bstnA(gbl-ns-vol[medarcv~/rcrds])# no cifs case-sensitive resets the medarcv~/rcrds volume so that it treats myFile and MyFile as the same file.
Related Commands	namespace -> volume nsck ... report metadata-only

Purpose	In a multi-protocol (CIFS and NFS) volume, CIFS clients can use symlinks created by NFS clients. For example, an NFS client can create a symlink named alink that points to a directory named adir/subdir. Any client can then access the adir/subdir directory through the alink symlink, as though alink was an actual directory. You can use the cifs deny-symlinks command to deny symlink access to the current volumes CIFS clients. This command makes it impossible for CIFS clients to traverse a symlink. Use no cifs deny-symlinks to allow CIFS clients to follow NFS symlinks.
Modes	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	cifs deny-symlinks no cifs deny-symlinks
Default(s)	no cifs deny-symlinks
Guidelines	This command is only meaningful in a multi-protocol namespace. It has no effect on a volume in an NFS-only or CIFS-only namespace. ARX CIFS clients can never see a symlink that points to a file or directory outside their front-end export. For example, consider a CIFS share of the \mydir\subdir directory, where the share is named CIFSVIEW. ARX clients see the contents of \subdir in the root of any drive mapped to CIFSVIEW. If a symlink named lowersub points to \mydir\anotherDir, the clients of the CIFSVIEW share never see the lowersub symlink. The symlink would lead to a directory next to the clients CIFSVIEW share, which may not exist on the client machine, so the managed volume does not display the link to its CIFS clients. You can use the nsck ... report symlinks command to get a list of all the symlinks in a namespace or volume. You can also use the find command to find the target file or directory for a particular symlink. To see how many CIFS clients are using NFS symlinks, along with some related statistics, you can use the show statistics cifs symlinks command.
Samples	bstnA(gbl-ns-vol[mp-ns~/vol])# cifs deny-symlinks prevents all CIFS clients from viewing or using any NFS symlinks in the mp-ns~/vol volume.   bstnA(gbl-ns-vol[insur~/claims])# no cifs deny-symlinks re-instates CIFS symlinks in the insur~/claims volume.
Related Commands	namespace -> volume nsck ... report metadata-only nsck ... report symlinks find show statistics cifs symlinks

Purpose	CIFS client applications can query a managed volume for the name of its file system. By default, the volume chooses a name based on the CIFS capabilities of its back-end shares; for example, it advertises NTFS if and only if all of its back-end shares can support NTFS-related features. Some client applications require specific settings in this string in order to function properly. On the advice of F5 Support, you can use the cifs file-system-name command to manually set the file system name for this volume. Use no cifs file-system-name to return to the automatic default.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	cifs file-system-name name no cifs file-system-name   name (1-16 characters) is the file-system name that this volume advertises to client applications. Use a name that is well-known, such as NTFS (see the Guidelines, below).
Default(s)	the volume calculates an appropriate setting for the string (no cifs file-system-name)
Guidelines	Use this command only under the guidance of F5 personnel. It has the potential to confuse client applications and cause them to malfunction. By default, the volume advertises one of three file-system names, depending on the CIFS options supported by its back-end shares: NTFS - if the volumes shares all support named-streams, persistent-acls, unicode-on-disk, and they all preserve case in their file/directory names (MyFile.txt is not converted to MYFILE.TXT). FAT32 - if the volumes shares support unicode-on-disk and case preservation, but not the others. FAT - if the volume supports none of the above options. Some applications require NTFS to function properly, and do not require all of the above NTFS capabilities. For example, if one of the volumes shares does not support named streams, the volume advertises FAT32. The Robocopy application reads the FAT32 file-system name and assumes that the managed volume cannot support large (4GB+) files. Support for named streams is irrelevant to the application. For Robocopy to create large files in this volume, you must set NTFS for the volume. In any case, use only one of the names above, in uppercase: NTFS, FAT32, or FAT
Sample	bstnA(gbl-ns-vol[insur~/claims])# cifs file-system-name NTFS advertises an NTFS file system for the /claims volume in the insur namespace.
Related Commands	namespace -> volume named-streams persistent-acls unicode-on-disk

Purpose	A CIFS filer or service can send change notifications to its clients on request. A change notification is an event from the CIFS service indicating some change in the file system, such as a renamed file or a new directory. This is a standard offering from CIFS implementations; file-managing applications use this to provide regularly-updated views of remote file systems. A CIFS volume on an ARX may create performance issues with this feature, since it collects change notifications from multiple back-end shares and forwards their aggregate to its clients. The volume and/or its clients can be overwhelmed with change notifications. By default, the volume reduces this traffic by ignoring any changes to a directorys subtree; it only sends notifications of changes in a directorys root. On the advice of F5 Support, you can use the cifs notify-change-mode command to either remove all change-notification traffic or increase it dramatically. Use no cifs notify-change-mode to return to the default, which is sufficient for most volumes.
Modes	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	cifs notify-change-mode {use-subtree-flag | no-changes-sent} no cifs notify-change-mode   use-subtree-flag and no-changes-sent are a required choice: use-subtree-flag causes the CIFS volume to honor a clients request for subtree notifications. By default, the volume silently ignores these client requests and only sends notifications for changes in a directorys root. You should do this only on the advice of F5 Support, as it dramatically increases the change notifications from the back-end filers to the ARX, and from the ARX to its clients. no-changes-sent shuts down change notifications from the volume.
Default(s)	no cifs notify-change-mode
Guidelines	The default should be sufficient for most (if not all) installations. Use this command only on the advice of F5 Support.
Samples	bstnA(gbl-ns-vol[win-ns~/vol])# cifs notify-change-mode no-changes-sent disables CIFS-change notifications from the win-ns~/vol volume.   bstnA(gbl-ns-vol[medarcv~/rcrds])# no cifs notify-change-mode causes the medarcv~/rcrds volume to support limited change notifications. Any client can request change notifications for any given directory, but the volume only sends notifications for changes in the directorys root. If the client requests subtree notifications, too, the volume silently ignores that part of the request.
Related Commands	namespace -> volume

Purpose	The ARX supports CIFS opportunistic locks (oplocks) by default. You can use the cifs oplocks-disable command to deny oplocks to this volumes CIFS clients. Use no cifs oplocks-disable to reinstate oplock support.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	cifs oplocks-disable [auto] no cifs oplocks-disable   auto (optional) disables oplocks on a per-client basis, in response to client timeouts (see the Guidelines, below).
Default(s)	the volume supports oplocks (no cifs oplocks-disable)
Guidelines	This command only applies to a namespace that supports CIFS. The default is sufficient for most installations. Use this command only on the advice of F5 Support. With oplocks enabled, CIFS-client A can reserve an oplock on file X. While the client holds the oplock, no other client application can write to the file; Client A can safely write to a local cache while it holds the oplock. When another client tries to write to file X, the CIFS volume holds the request, tells Client A that its oplock is revoked, takes all writes from Client A, then allows the other client to proceed. When oplocks are disabled, the volume does not grant any oplocks to any CIFS clients. The auto keyword causes the volume to enable or disable oplocks individually for each CIFS client. The volume disables oplocks for a CIFS client that fails to an oplock break command in 10 seconds. (The oplock break command tells the client to finish its writes and release the oplock to another client.) For 10 minutes, oplocks are disabled for the CIFS client. After the 10 minutes expire, the volume re-enables oplocks for the client.
Samples	bstnA(gbl-ns-vol[insur~/claims])# cifs oplocks-disable shuts off oplock support for the /claims volume in the insur namespace.   bstnA(gbl-ns-vol[medarcv~/rcrds])# cifs oplocks-disable auto makes the medarcv~/rcrds volume manage oplocks on a client-by-client basis, automatically.   bstnA(gbl-ns-vol[ns1~/])# no cifs oplocks-disable reinstates the oplock feature in the ns1~/ volume.
Related Commands	namespace -> volume

Purpose	Each NSM processor learns about a managed volumes file and directory paths from the volume software. The volume software runs on an ACM processor. The NSM processor caches all file/directory paths as it learns them, to avoid repetitive queries to the ACM. You can use no cifs path-cache to stop caching these paths at the NSM processors. The affirmative command, cifs path-cache, resumes path caching at all NSM processors.
Modes	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	no cifs path-cache cifs path-cache
Default(s)	cifs path-cache
Guidelines	Use this command only on the advice of F5 Support. You can use show cifs-service path-cache to view the current state of the CIFS-path cache. For path-cache statistics since the last reboot, use show statistics cifs path-cache. The clear statistics cifs path-cache command clears all path-cache statistics. This setting has no effect on a direct volume.
Samples	bstnA(gbl-ns-vol[win-ns~/vol])# no cifs path-cache disables all path caching for the win-ns~/vol volume.   bstnA(gbl-ns-vol[win-ns~/vol])# cifs path-cache enables path caching for the same volume.
Related Commands	namespace -> volume show cifs-service path-cache show statistics cifs path-cache clear statistics cifs path-cache

Purpose	A volume that supports compressed files allows its clients to compress its files and preserves the file compression for policy migrations and shadow copies. If any back-end-CIFS filer does not support compressed files, you must disable the feature for its namespace volume. This applies to volumes in namespaces that support CIFS, not in NFS-only namespaces. Use the no compressed-files command to stop the volume from using compressed files. Use the affirmative form, compressed-files, to reinstate compressed files.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	no compressed-files compressed-files
Default(s)	The compressed-files setting at the first-enabled share.
Guidelines	A Windows client can compress any seldom-used file to conserve on disk space (on Windows XP, right-click the file -> Properties -> General tab -> Advanced... button -> Compress ... checkbox). A volume without compressed-file support does not preserve this compression if the file migrates between back-end shares (with a place-rule), or if the file is copied to a shadow volume (with a shadow-copy-rule). You cannot enable a share if it supports compressed files and its back-end-CIFS filer does not. The enable operation fails with an error that lists all CIFS features that must be disabled, possibly including this one. Use the enable (gbl-ns, gbl-ns-vol) command to enable all shares in a new namespace, or use the enable (gbl-ns-vol-shr) command to enable a new share in an already-enabled namespace. If you remove the share(s) or upgrade the back-end filer(s), you can reinstate this feature for the volume. Use remove-share migrate or remove-share nomigrate to remove a share from a namespace. You can use the show exports command to see all CIFS options for the share.
Samples	bstnA(gbl-ns-vol[medarcv~/lab_equipment])# no compressed-files shuts off compressed files for the /lab_equipment volume in the medarcv namespace.   bstnA(gbl-ns-vol[medarcv~/rcrds])# compressed-files reinstates compressed files for the /rcrds volume in the medarcv namespace.
Related Commands	namespace -> volume enable (gbl-ns, gbl-ns-vol) enable (gbl-ns-vol-shr) show exports

Purpose	Use this command to designate the current share as critical, so that a failover may occur if the share connection fails. Use the no form of the command to make the share non-critical.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	critical no critical
Default(s)	no critical
Guidelines	This command is only meaningful on a switch with a redundant peer. If a critical share fails on the current peer and the redundant peer has no failures, control fails over to the other peer. A peer with no failures has no service-affecting software or hardware faults, and has access to all critical shares and critical routes. For example, if the current switch loses contact with a critical share but its peer has lost contact with the quorum disk, no failover occurs. (This prevents a critical-share failure from causing an unnecessary failover.) The ARX tests for failure with a regular ICMP ping. Every 30 seconds, the ARX sends a ping to the shares filer. If the filer fails to respond, the ARX waits an additional 30 seconds before asking the peer if it is possible to fail over. The pings continue indefinitely at 30-second intervals. If the filer responds before the failover is initiated, the failover does not occur. Use the critical route command to establish a critical route. To make a dedicated metadata share into a critical resource, use the metadata critical command. To show all critical shares and routes, use the show redundancy critical-services command.
Samples	bstnA(gbl-ns-vol-shr[archives~/etc~s1])# critical designates the current share, archives~/etc~s1, as a critical share. If the ARX loses contact with the back-end share and its redundant peer has no serious issues, a failover occurs.   bstnA(gbl-ns-vol-shr[ns~/vol1~shareA])# no critical removes the current share from the list of critical resources.
Related Commands	namespace -> volume -> share critical route metadata critical show redundancy critical-services

Purpose	Use the direct command to indicate that the current volume contains direct-mapped shares. This establishes the volume as a direct volume rather than a managed volume. Use the no form of the command to indicate the volume contains no direct-mapped shares.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	direct no direct
Default(s)	no direct
Guidelines	This command can be executed only when the volume has no filers assigned in any of its shares. You cannot create a direct volume in a namespace that supports NFSv2 (see the documentation for protocol). Use the attach command in the volumes shares to directly attach the volume to various mount points on back-end filers. A direct volume can support up to 4,278,190,080 total inodes, or files. To use an ARX managed volume as the back-end for one of the direct volumes shares, use the managed-volume command.
Sample	bstnA(gbl-ns-vol[wwclim~/temp])# direct indicates the wwclim~/temp volume contains direct-mapped shares.
Related Commands	namespace -> volume attach managed-volume

Purpose	Use the enable command to activate the current share. Use no enable to disable the current share.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	enable [take-ownership] no enable   take-ownership (optional) applies only to a share in a managed volume (as opposed to a direct volume). This causes the managed volume to take ownership of the back-end share. Use this option only if you are sure that the share is not in active use by a managed volume on another ARX. For example, some sites use filer applications to replicate all data from one site to another; if an ARX had managed volumes at the primary site, the ARXs ownership marker (a file) would be copied to the second site. An ARX at the second site could only import the replicated share if you use the take-ownership option.
Important: The take-ownership option could possibly remove a share from another managed volume that is in service. Use this option only for cases where the share is spuriously marked by another ARX. The CLI prompts for confirmation if you use this option; enter yes to proceed.
Default(s)	Disabled
Guidelines	You must enable a share for the volume to import it or otherwise use it. This is true for both managed volumes and direct volumes. We recommend that you enable all of the volumes shares first, then enable the volume with the enable (gbl-ns, gbl-ns-vol) command. This allows the volume to import all of the shares simultaneously, and gives the volumes clients immediate access to all of the shares at once.
Important: For shares backed by NetApp or EMC, you may need to access the filer directly and pre-create some qtrees or EMC quota trees. This rare configuration issue only occurs if: - this is a managed volume, - you want to support both free-space quotas (freespace cifs-quota), and - you also want to support filer-subshares in this volume. In this case, a NetApp share requires one qtree per subshare, and an EMC share must be an EMC File System with one tree quota per subshare. Pre-create the NetApp qtrees and/or EMC quota trees before you enable the share. See the Guidelines: Subshare Replication with Free-Space Quotas section of the filer-subshares documentation.
Guidelines (Cont.)	When a share is first imported into a managed volume, the volume generates an import report. The import reports are accessible through show reports. Their names have the following formats: import.share-id.share-name.job-id.rpt Use show reports report-name to see its contents. See Figure 22.2 on page 22-29 for a sample import report. The no enable command stops using the current share in the volume. All files on the share become inaccessible to clients. This is not generally recommended in a managed volume, where it also shuts down all policy rules in the volume. Use remove-share migrate or remove-share nomigrate to remove the share.
Guidelines: Enabling a New Share in an Exported CIFS Volume	This section only applies to a share that supports CIFS storage. A new filer behind a running CIFS service often requires some configuration at a local Domain Controller (DC). Best practices dictate that a CIFS service is trusted to delegate CIFS connections to all of the filers behind it, and it is not trusted to delegate CIFS to any other filer. This is called constrained delegation. The DCs manage the CIFS services ability to delegate, as well as the back-end filers to whom it can delegate. An authorized Windows administrator must therefore go to a DC and add this new filer to its CIFS services delegate to list. If the filers storage is exported by more than one CIFS service, the administrator must add it to the delegate to list for all of them. After you enable the share, you can use show cifs-service fqdn to list the volumes exported by the fqdn CIFS service. For every service that exports the current volume, you can use probe delegate-to fqdn to check the DC(s) and determine whether or not delegation is properly configured for the new filer. If not, a properly authorized administrator must access the DC and add the new filer to the CIFS services delegate to list. The filer must be joined to the same Windows Domain as the above CIFS service(s), and it must support Kerberos authentication. The show cifs-service fqdn command shows the domain to which the fqdn service is joined.
Guidelines: Changing the Maximum Files in a Direct Share	This guideline only applies to a share in a direct volume. When you enable a share in a direct volume, the volume software records the maximum number of files in the share. To increase that maximum, you must disable the share (with no enable), change the maximum at the back-end filer (through direct access), and then re-enable the direct share (enable).
Samples	bstnA(gbl-ns-vol-shr[archives~/multimedia~lun77])# enable enables the current share.   prtlndA(gbl-ns-vol-shr[insur_bkup~/insurShdw~backInsur])# enable take-ownership This command allows the switch to virtualize shares that are used by other Acopia switches. Allow switch to take ownership of share? [yes/no] yes enables the current share and takes ownership of it.   bstnA(gbl-ns-vol-shr[archives~/radio~xyz])# no enable disables the archives~/radio~xyz share.
Related Commands	namespace -> volume -> share show namespace

Purpose	Use the filer command to bind the current share to a back-end-filer share. Use the no form of this command to remove the binding to any source export/share.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax: filer	filer filer {nfs share-name | cifs share-name}+ [access-list list-name] [cluster cluster-name]   filer (1-64 characters) is the name of the filer. Use show external-filer for a list of configured filers to choose from. You can enter either nfs share-name or cifs share-name to identify a share at the filer. You can enter both (in any order) to specify a multi-protocol share on the filer: nfs share-name (1-900 characters) is an NFS export at the filer. cifs share-name (1-1024 characters) is a CIFS share at the filer. list-name (optional, 1-64 characters) applies an NFS-access list to the NFS export. Use show nfs-access-list for a list of all configured NFS access lists. cluster-name (optional, 1-64 characters) is only relevant if the ARX is part of a disaster-recovery (DR) configuration. In a DR configuration, there is an active ARX cluster with one set of filers and a backup cluster with a mirrored set of filers. This determines which cluster uses this filer. Run the filer command twice per share if you use DR: once to designate the filer for the active cluster, and again to determine the filer at the backup cluster. Use show cluster for a list of configured clusters. If you omit this, the command assumes that this is the local cluster.
Syntax: no filer	no filer [cluster cluster-name] no filer relocate-dirs target-share [remove-file-entries [verbose] [offline]]   cluster-name (optional) is only relevant if the ARX is part of a disaster-recovery (DR) configuration. This specifies the cluster where the filer binding is removed. If you specify a remote cluster, the filer binding is simply removed from the remote clusters configuration and none of the remaining options are relevant. If you omit this option, the CLI removes the binding from the local cluster. relocate-dirs is required if you are disconnecting from an already-imported share in a managed volume. This is never required for a direct volume or a replica-snap share. target-share is another share in the same managed volume. The volume migrates all master directories in the current share to this target. You can enter the optional flags (remove-file-entries, offline, and verbose) in any order. As above, these options only apply to managed volumes and do not apply to replica-snap shares: remove-file-entries removes all files from volume metadata that still reside on this back-end share. verbose (optional, if you choose remove-file-entries) causes the operation to list all removed files in its removeShare report. offline (optional, if you choose remove-file-entries) is only for back-end shares that are offline or otherwise unreachable. This forces the disconnect without scanning the back-end for its directory attributes. Relocated master directories therefore have all of their file attributes set to 0 (zero).
Default(s)	None
Guidelines	The filers export/share must support all of the namespaces protocols (for example, a namespace that supports NFSv2 and NFSv3 cannot import a filer that supports only NFSv3). The show exports command shows the supported protocol(s) for each export/share, and the show global-config namespace command shows the protocol(s) supported by a namespace. Use show external-filer to list all filers. Never import more than one instance of a given back-end share. If the filer uses aliases for its shares, the ARX assumes that each alias is a different share. In a direct volume, you can use a managed volume as a filer instead. Use the managed-volume command to do this.
Guidelines: Importing a NetApp Share with Multiple Qtrees	If you choose a NetApp share with multiple qtrees, all the qtrees must have the same security style. Also, the qtrees must all use either NTFS or Unix style; managed volumes do not support qtrees with a Mixed security style. A volume with such a NetApp share cannot support a shadow-copy-rule, the shadow command, or the migrate retain-files option in a place-rule.
Guidelines: Removing the Filer Binding	In a managed volume, you can remove the filer binding with the simple no filer command before the share is first imported. The share import is triggered by a combination of enable (gbl-ns-vol-shr) for the share and enable (gbl-ns, gbl-ns-vol) for either the volume or the namespace. A direct volume does not import its shares, so you can always detach its filers with the simple no filer syntax. The same applies to replica-snap shares in a managed volume. After the managed volume imports the share, you can use a place-rule to remove all files from the share. Then you use the relocate-dirs argument in no filer to relocate the shares master directories to some other share in the same volume. (A volume often has multiple copies of its directories in each share, so that it can migrate files between them; a master directory is the copy where the volume puts all new files.) The volume scans the current back-end share for the file attributes of these directories, to be duplicated at the target-share. If this is impossible because the back-end share is offline, use the offline flag (along with remove-file-entries) to create new instances of the directories with zeroed-out file attributes. The CLI creates a removeShare report to show the progress of the no filer command. Each report is named removeShare.share-name.rpt, where share-name is the ARX-share name (not the name of the share at the filer). The no filer command fails if any of the client-visible files in the managed volume are on the share; the remove-file-entries flag removes the files from the volume metadata and allows the no filer operation to succeed. The number of files removed appears in the removeShare report. The additional verbose flag adds the names of each removed file into the report. The additional offline flag, described above, applies to unreachable filers. In a direct volume, you can use no filer, without any options, before or after you enable the share. This removes all of the shares files and directories from client view. To remove the share configuration, you can use no share. As an alternative to no filer or no share in a managed volume, you can use remove-share migrate to remove an imported managed-volume share, remove-share nomigrate to remove a managed-volume share that failed to import, or remove-share offline to remove a share that is unreachable.
Samples	bstnA(gbl-ns-vol-shr[wwmed~/acct~bills2])# filer das3 nfs /data/acct2 binds the bills2 share to an NFS filer share.   bstnA(gbl-ns-vol-shr[mpns~/vol~stor4])# filer nas6 nfs /vol/vol1 cifs VOL1 binds the stor4 share to a multi-protocol share.   bstnA(gbl-ns-vol-shr[ns1~/vol~test])# no filer relocate-dirs share4 removes the filer binding for test, migrating all of its master directories to share4 in the ns1~/vol volume.
Related Commands	namespace -> volume -> share show external-filer show exports show global-config namespace no share managed-volume

Purpose	A managed volume that supports CIFS can optionally support subshares and their share-level ACLs. A subshare is a CIFS share inside an imported CIFS share. Through a volume that supports subshares, a properly-configured cifs service can pass its clients from a front-end subshare to the corresponding back-end subshare. The back-end filer can then apply the subshares ACL to the clients actions. Use the filer-subshares command to support subshares at this volume. The no form of this command removes subshare support from this managed volume. A volume without subshare support always connects to the root of the back-end share, thereby using the ACL defined there, whether or not the client connects to a front-end subshare.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	filer-subshares [native-names-only] no filer-subshares   native-names-only (optional) causes a subshare to be degraded if it encounters any name collisions. A subshare name collision occurs when the volume attempts to replicate the subshare on a filer that already supports the same share name for a different directory. For example, suppose filer A has these two shares: e:\exports as ESHARE and e:\exports\dirA\books as BOOKS. This is a subshare of ESHARE. Further suppose that filer B has these shares: d:\exports as MYSTUFF and c:\Users\juser\Documents as BOOKS. This is not a subshare of MYSTUFF. If a managed volume imports both ESHARE and MYSTUFF, it finds the BOOKS subshare under ESHARE. It must replicate BOOKS on filer B at the same relative path, d:\exports\dirA\books. However, BOOKS is already defined on filer B for a directory on the C drive. The default solution to this issue is to generate a special subshare name, such as _acopia_BOOKS_2$. Use the native-names-only option to forbid any such generated subshare names. The volume generates a full report on subshare replication (described below) during import; if this replication fails due to a subshare-name collision like this, the report shows the subshare name(s) that collided.
Default(s)	no filer-subshares
Guidelines	This command only applies to a managed volume that supports CIFS. The ARX is a proxy between front-end clients and back-end shares; it passes clients through to the back end for authentication. Share-level ACLs are created and enforced at the back-end filers. You can use show exports ... paths to probe for all shares on a given filer as well as the directory path behind each share. This shows you all of the share-to-subshare relationships on the filer. Subshares require special configuration and processing on the ARX. After you use the filer-subshares command on a volume, you can use export (gbl-cifs) ... filer-subshare to export each of the subshares to your CIFS clients. When a client connects to one of these subshares, the volume passes the client connection directly to an equivalent back-end-filer subshare. The filer then uses its subshare ACL to determine the clients access privileges. Without the subshare configuration, the volume connects the client to the root of the share, and the filer uses the root shares ACL.
Guidelines: Subshare Replication	When you enable (gbl-ns, gbl-ns-vol) a volume with filer-subshares, the volume probes all its filer shares for subshares, and then it replicates the subshares and ACLs between those shares. The volume must ensure that all instances of a subshare have identical ACLs, so that a client has the same access privileges no matter which back-end subshare holds the desired file. For the replication to succeed, the volume must be set to modify and each of its shares must have the import sync-attributes flag raised. The goal of subshare replication is to make all subshare definitions match as follows: share name, directory path, relative to the root of the share, and ACL. The volume requires admin-level permissions to read or replicate the directory paths and subshares on the back-end filers. This is a higher level of access than you typically need for proxy-user credentials. You may need to change to more-privileged credentials behind the namespaces proxy-user, or configure the namespace with a new proxy-user (gbl-ns) altogether. If synchronization is needed for a subshare but impossible due to a configuration issue (no modify, no import sync-attributes, and/or insufficient proxy-user permissions), the corresponding front-end subshare will be considered degraded. Clients cannot connect to a degraded subshare. For a replica-snap share, which is typically read-only, the subshare replication process cannot create directories on the share. Therefore, it cannot occur when the replica-snap share is enabled. Instead, the process waits for the snapshot replica-snap-rule to create the subshare directories, and then it defines the share name and ACL for each of them.
Guidelines: Subshare Replication with Free-Space Quotas	The volume-level freespace cifs-quota command makes a CIFS volume advertise free space in terms of each clients back-end storage quota. That is, if three back-end subshares each have a quota of 1G, clients with that quota see up to 3G of free space (1G for each of the three shares) instead of the actual free space. You set these free-space quotas at the back-end filers. The quotas are not replicated with other subshare data; if you use storage quotas on your back-end filers, replicate the storage quotas manually to all the back-end filers behind this managed volume. For NetApp filers and EMC servers, manually replicate the subshares as qtrees and/or EMC tree quotas before you enable the volume. Do this at every NetApp and EMC share behind this managed volume. Use the same directory name, relative path, and share name for all of them. No special directories are required to set quotas on Windows servers, so you can add quotas after subshare replication on those devices.
Guidelines: Subshare-Name Collisions	Replicated back-end subshares use the same name as the source subshare, called the native subshare name, whenever possible. The volume cannot use a native subshare name if any other CIFS share on the back-end filer is already using that name. This is called a subshare-name collision. For subshare-name collisions, the managed volume names the subshare with the following syntax: _acopia_subshare_id$ where subshare is the native name of the original subshare. id is a unique integer to identify the subshare. This is unique for every subshare behind the ARX and its redundant peer. $, at the end of the share name, hides the subshare name from most network clients. You can use the native-names-only option to prevent any such generated names. This means that a subshare-name collision puts the front-end subshare in a degraded state. CIFS clients cannot connect to a degraded front-end subshare.
Guidelines: Finding and Correcting Subshare Collisions	A managed volume with filer subshares generates a sync subshares report when it and its shares are enabled. This report describes the results of the subshare-replication process. The report name has the prefix, syncSshrNewStorageReport. Use show reports report-name to see its contents. A sample report appears below; see Figure 22.3 on page 22-38. Inconsistent subshares are flagged in this report, if any are found; you can access the filer directly to change the subshare definition or ACL, then use sync subshares from-namespace to retry the subshare-replication process.
Guidelines: Subshare-ACL Collisions	When two import shares have matching subshares with different share-level ACLs, they collide. For example, two shares could contain directories named myDir\yourDir at their roots, both shared as YOURDIR but with slightly different ACLs. The ACLs must match at all instances of the subshare, so the volume uses the directory that was chosen as master to choose the ACL. The master directory is the one that is first imported. Before you import the shares, you can use the import priority command to choose a particular share (typically the Tier-1 share) to win directory mastership wherever there is such a collision. The volume copies the ACL from the master-directory subshare to all of the matching subshares. An ACL collision does not prevent import, or require further action.
Guidelines: Windows Server Clusters	A Windows Server Cluster is a redundant configuration of Windows servers, called nodes. Subshare replication has a limitation when used on a Windows-server cluster: it can only replicate the subshares on the clusters currently-active node. The replicated subshares and their ACLs only exist on the active node, and cannot be used after a cluster failover. If you activate filer subshares in a volume backed by a server cluster, manually duplicate the subshares and ACLs on all nodes in the cluster. Subshare replication occurs when you enable (gbl-ns-vol-shr) one of the clusters shares in the current ARX volume. After the replication is complete, duplicate the subshares and ACLs at the clusters administrative interface; this ensures that they are on all nodes. Use the same subshare names created by the replication process, such as Y2005 (a native subshare name) or _acopia_Y2004_4$ (a generated subshare name).
Guidelines: Exporting the Subshare(s)	To find and export all the subshares from the volume to your front-end CIFS service, use sync subshares from-namespace. While any of a volumes subshares are shared through a front-end CIFS service, you cannot use no filer-subshares in the volume.
Guidelines: Adding New Subshares	To add a new subshare in a running volume that already supports them: Choose an existing directory to be exported as a subshare. If none exists, create one now: If you want to support CIFS quotas (freespace cifs-quota) and the volume is backed by a NetApp filer or EMC server, go directly to the back-end filer(s) and manually create qtree(s) or quota tree(s) for the subshare. Use the same directory name and relative path for all of them. Then run sync directories to incorporate the new directory into the volume metadata. If you are not supporting quotas from NetApp or EMC, connect to the front-end export (gbl-cifs) as a client and create its directory. Use find to get the master directory for the new subshare path. This tells you which filer share contains the master directory. Access that filer share directly and create the share-level ACL, share definition, and/or directory attributes for the subshare path. Use the sync subshares from-namespace command to export the directory as a subshare, and to replicate the subshare on all of the volumes filers that do not already have it. This also copies the ACL and attributes from the master directory to all stripe directories in the volume. If the volume is backed by any Windows Servers and it supports freespace cifs-quota, access the Server(s) directly and set a path-based quota on the subshare(s). If the volume is backed by any Windows Server Clusters, manually duplicate the subshares and ACLs from the clusters active node to the clusters remaining node(s). You cannot enable filer-subshares in a volume with already-enabled shares.
Samples	bstnA(gbl-ns-vol[medarcv~/rcrds])# filer-subshares native-names-only configures the /rcrds volume to support CIFS subshares and share-level ACLs. The native-names-only option tells the volume not to generate subshare names (such as _acopia_mysubshare_1) if subshare names collide; instead, let the replication fail and put the front-end subshare into a degraded state. This command raises a flag only, to be enforced when you enable the volume and its shares.   bstnA(gbl-ns-vol[ns3~/vol1])# no filer-subshares removes CIFS-subshare support from the /vol1 volume.
Related Commands	namespace -> volume import priority show exports ... paths export (gbl-cifs) ... filer-subshare sync subshares from-namespace sync subshares from-service freespace cifs-quota

Purpose	If you used freespace calculate manual to manually calculate free space for this volume, you can use the freespace adjust command to adjust the free space that is advertised for the current share. Use no freespace adjust to remove any free-space adjustment.
Modes	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	freespace adjust [-]adjustment[k|M|G|T] no freespace adjust   - (optional) makes the adjustment negative. adjustment is the change in advertised free space. k|M|G|T chooses the unit of measure: kilobytes, Megabytes, Gigabytes, or Terabytes. A kilobyte is 1,024 bytes, a megabyte is 1,024 kilobytes (1,048,576 bytes), and so on.
Default(s)	no freespace adjust k|M|G|T - if none of these is used, the adjustment is measured in bytes.
Guidelines	By default, the volume calculates its free space automatically: it takes the sum of all free space on all shares, but it only counts one of the shares from a given back-end storage volume. Use the freespace calculation manual command to allow manual adjustments in the current volume, then use this command to adjust the free space for each chosen share. You can also use freespace ignore to ignore the share in the free-space calculation. If you use this command together with freespace ignore on a given share, this command sets the total free space advertised by the share. Some back-end CIFS filers (such as Windows Servers) can support free-space quotas, and these can have an effect on the free-space adjustment. You can use the freespace cifs-quota command to discover the free space available to a client at each back-end share, add up the clients available free space from all those shares, and pass the sum back to the CIFS client. This command, freespace adjust, then adjusts the current shares numbers based on the clients available space, not based on the total size of the share. Use the show global-config namespace command to see if this command is set for the share. CIFS clients only see the results of this command if they connect after you invoke it.
Samples	bstnA(gbl-ns-vol-shr[ns1~/vol~shr4])# freespace adjust -1G changes the free space that is counted for shr4; this advertises 1 Gigabyte less than the actual free space.   bstnA(gbl-ns-vol-shr[wwmed~/acct~bills])# no freespace adjust uses the actual free space for bills share.
Related Commands	namespace -> volume -> share freespace calculation manual freespace ignore freespace cifs-quota show global-config namespace

Purpose	Some sites restrict each of their clients to a single back-end share, using the ARX for occasional migrations only (that is, to migrate their entire directory tree to another share all at once). This creates a situation where the client can only use the free space on their current back-end share, not on all the shares behind the managed volume. You can use freespace calculate dir-master-only for this situation, which shows clients only the free space on their currently-assigned back-end share. If you use that command, you can also use freespace apparent-size to change the free space that is advertised for the current share. Use no freespace apparent-size to report the full size of the current share to the volumes clients.
Modes	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	freespace apparent-size size[k|M|G|T] no freespace apparent-size   size is the full size to advertise for this share. After the share is imported, you can use the show namespace command to find its actual space. k|M|G|T chooses the unit of measure: kilobytes, Megabytes, Gigabytes, or Terabytes. A kilobyte is 1,024 bytes, a megabyte is 1,024 kilobytes (1,048,576 bytes), and so on.
Default(s)	no freespace apparent-size k|M|G|T - if none of these is used, the adjustment is measured in bytes.
Guidelines	By default, the volume calculates its free space automatically: it takes the sum of all free space on all shares. Use the freespace calculation dir-master-only command to advertise only the free space on a single back-end share to any client. The single back-end share is the one with the master for the clients front-end-share path; all back-end stripe directories are excluded. Then you can optionally use this command to set the advertised free space for each share. If the back-end share uses up the free space you advertise with this command, but is not actually full, clients see 0 (zero) free space. Use the show global-config namespace command to see if this command is set for the share.
Samples	bstnA(gbl-ns-vol-shr[insur~/claims~shr1-next])# freespace apparent-size 2460M changes the free space that is advertised for shr1-next; this advertises free space as though the shares total size is 2460 Megabytes (2.4 Gigabytes).   stoweA(gbl-ns-vol-shr[lodges~/skiPatrol~stoweMtn])# no freespace apparent-size uses the actual free space size for stoweMtn share.
Related Commands	namespace -> volume -> share freespace calculation dir-master-only show global-config namespace

Purpose	The volumes free space, as seen by clients, is the sum of all free space in its back-end shares. This is misleading in installations where clients only access a single back-end share behind the volume; such clients are restricted to that single share, and should therefore only see the free space from that share. The single back-end share is said to hold the front-end shares master instance; replica shares on other back-end filers are called stripes. To show clients the free space in only the master back-end share, use the freespace calculation dir-master-only command. Use the no form of the command to show clients the sum of all free space on all back-end shares behind this volume.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	freespace calculation dir-master-only no freespace calculation dir-master-only
Default(s)	no freespace calculation dir-master-only
Guidelines	This command is useful in a managed volume with home directories, or a managed volume that is migrating files once (from one share to another). This only affects the client view of the volumes free space. It has no effect on the free space perceived by the policy engine. A direct volume does not support this type of free-space calculation. The master share is the back-end share that holds the master instance of the front-end shares directory. This is the root of the export (gbl-cifs) to which the client connected. This could be the root of the entire volume or it could be a CIFS subshare. You may want to advertise a fixed size for each share, perhaps to ensure that the free-space seen by a client is consistent if his or her directory tree migrates from one share to another. For each share, you can set an apparent space size with the freespace apparent-size command. Use the show global-config namespace command to see the volumes configuration settings for free space.
Guidelines: Alternative Free-Space Reporting	The freespace calculation manual command is an alternative form of free-space calculation where you can manually adjust the free-space numbers from each share. If you set the volume for manual free-space calculation, you can exclude shares with the freespace ignore command. You can also adjust the free-space number for a share (whether or not its actual free space is ignored) with the freespace adjust command.
Samples	bstnA(gbl-ns-vol[insur~/claims])# freespace calculation dir-master-only changes the /claims volume so that it only shows the free space from one back-end share rather than all of them.   bstnA(gbl-ns-vol[wwmed~/acct])# no freespace calculation dir-master-only returns the /acct volume to the default. This volume reports the total free space to its clients, summing up the free space in all of its back-end shares.
Related Commands	namespace -> volume freespace apparent-size

Purpose	The volumes free space, as seen by clients, is the sum of all free space in its shares. By default, the volume finds the back-end storage volume for each of its shares and, if two or more of its shares draw from the same back-end storage volume, it counts the free space from only one of them. Use the freespace calculation manual command to remove this automation, permitting you to manually decide which shares to ignore. Use the no form of the command to automatically detect multiple shares from the same back-end storage volume.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	freespace calculation manual no freespace calculation manual
Default(s)	no freespace calculation manual
Guidelines	An NFS volume uses a shares file-system ID (FSID) to identify the storage volume behind the share. A CIFS volume uses the shares Volume Serial Number. By default, only one share is counted if two or more shares have matching IDs. If you set the volume for manual free-space calculation, you can exclude shares with the freespace ignore command. You can also adjust the free-space number for a share (whether or not its actual free space is ignored) with the freespace adjust command. Some back-end CIFS filers (such as Windows Servers) can support free-space quotas, and these can affect the free-space calculation. You can use the freespace cifs-quota command to discover the free space available to a client at each back-end share, add up the clients available free space from all those shares, and pass the sum back to the CIFS client. The freespace adjust command then adjusts a shares free-space numbers based on the clients quota, not based on the total size of the share. Use the show global-config namespace command to see the volumes configuration settings for free space.
Guidelines: Alternative Free-Space Reporting	The freespace calculation dir-master-only command is an alternative form of free-space calculation where the volume only shows the free space in one back-end share behind the volume. It chooses the share that holds the master instance of the clients current directory. This is useful for volumes where a clients directory tree is exclusively on one back-end share at any given time. If you set the volume for this free-space calculation, you can also set the client-visible space on each of the volumes shares with the freespace apparent-size command. You cannot use freespace adjust or freespace ignore with the freespace calculation dir-master-only command.
Samples	bstnA(gbl-ns-vol[ns1~/])# freespace calculation manual includes all shares, allowing you to manually ignore some shares.   bstnA(gbl-ns-vol[wwmed~/acct])# no freespace calculation manual reverts to automatic free-space calculations. The automatic calculation notes the back-end shares that draw from the same storage pool, and each back-end storage pool only once.
Related Commands	namespace -> volume freespace ignore freespace adjust freespace cifs-quota

Purpose	A managed volumes free space, as seen by clients, is the sum of all free space in its back-end shares. By default, this does not take into account any storage quotas on any back-end CIFS servers; if a 100G back-end share has a quota of 1G, the client sees 100G of free space when the share is empty. You can use the freespace cifs-quota command to take the back-end quotas into account, so that CIFS clients with a 1G quota only see 1G of space and connections to a CIFS subshare with a 5G quota see only 5G of space. With this option enabled, clients see the sum of the quota-based free space on the volumes back-end shares, not the sum of the full free space. Use the no form of the command to show all clients the full free space, ignoring all back-end quotas.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	freespace cifs-quota no freespace cifs-quota
Default(s)	no freespace cifs-quota
Guidelines	This command is only useful in a managed volume that supports CIFS. It is not supported in a direct volume, or one that supports only NFS (see protocol). Back-end filers can support one or two forms of storage quota: path-based quotas, which affect a particular directory path. user-based quotas, which allow each client to use only a limited amount of storage in a particular storage pool. This command, freespace cifs-quota, makes both of these quota types visible to the ARX volumes clients. If a given client is allotted a total of 4G on the volumes back-end filers, due to path-based quotas and/or the clients user-based quotas at those filers, the client only sees 4G of space. Use the show global-config namespace command to see the volumes configuration settings for free space. CIFS clients only see the results of this command if they connect after you invoke it.
Guidelines: Relationship of Front-End Shares to Back-End Quotas	Path-based quotas are applied to back-end paths, so the free space that the client sees depends on the front-end CIFS share to which they connect. There are two major forms of front-end CIFS share: An export (gbl-cifs) is a full share of the entire volume, and An export (gbl-cifs) ... filer-subshare is a subshare. If a CIFS client connects to a full share (or any path within a full share), the client sees the free-space quotas set at the imported path (or root) of the volumes back-end shares. If the client connects to a subshare, the client sees the free-space quotas set at its back-end subshare paths. When each subshare is dedicated to a single client (as with a home-directory application), you can use path-based quotas at each back-end subshare. Then the freespace cifs-quota command causes the ARX volume to advertise those quotas to its clients.
Note: In all cases, we recommend setting specific path-based quotas at each back-end share or subshare to which your CIFS clients connect. For NetApp, this means that each share or subshare must be its own qtree. For EMC, the share or subshares must reside in an EMC File System with quotas set at the import share or at each subshare. For Windows, set a path-based quota at the import share or at each subshare.
Guidelines: NetApp and EMC with Filer Subshares	Free-space quotas (this command) and filer-subshares are difficult to use together in a volume backed by either NetApp or EMC. A NetApp only supports path-based quotas on its qtrees, and an EMC server only supports them in a quota tree inside a File System. Each qtree or quota tree gets a single quota. As mentioned above, each subshare requires a path-based quota for proper free space reporting. Therefore, each subshare path must be backed by one qtree or quota tree. This is required for CIFS clients to see the space that they are allowed to use. The ARX volume automatically replicates its subshare directories to all of its back-end filers. The replication process cannot safely presume that you want a full qtree or quota tree behind these replicated directories, so it can only create the directory itself. Therefore, the subshare-replication process creates directories on NetApp and EMC that cannot support path-based quotas. For NetApp or EMC, pre-create the qtrees and/or quota trees instead of relying on the ARX volumes subshare-replication process. Do this before you import any storage from the back-end filer(s), as described in the Guidelines: Subshare Replication with Free-Space Quotas section of the filer-subshares documentation. If subshares are already configured as plain directories on your back-end NetApp or EMC, and you want to convert them to qtrees or EMC quota trees, contact F5 for guidance.
Guidelines: Windows Servers with Filer Subshares	You must also set path-based quotas on all Windows servers where subshare-replication occurs. The subshare-replication process does not replicate Windows-quota settings along with other subshare settings. Unlike NetApp and EMC, you can set the quotas on Windows servers after subshare replication is complete; you do not need to pre-create any special directories.
Guidelines: Manually Adjusting the Reported Free Space	You can also manually ignore the free space on some of the volumes back-end shares, or adjust the advertised free space for one or more shares. Use the freespace calculation manual command in the volume, then use freespace ignore and/or freespace adjust in each share. The adjustment from freespace adjust is applied to the back-end quota, not to the total size of the back-end share.
Guidelines: Back-End Shares That Draw from the Same Storage Pool	An ARX volume may import two or more shares that are affected by the same free-space number, and this creates errors in free-space reporting. Whenever the freespace cifs-quota feature is enabled, the ARX volume presumes that a path-based quota is set on all of its back-end shares; it therefore counts the space from each share separately. For example, suppose shares HUEY, DEWEY, and LOUIE all draw from drive E on the same Windows server, and an ARX volume imports all three of them. The volume also adds together all of their free space. This creates an incorrect sum if there is no quota (all three shares report the full space of the E drive), there is a user-based quota (all shares report the full space allowed to the client), or all three shares inherit the same path-based quota from a common ancestor, such as E:\. Specific path-based quotas for each share, recommended earlier, helps to solve this problem. Additionally, avoid any user-based quotas or common path-based quotas altogether. If this is not possible, use freespace ignore to ignore each imported share from a common storage pool except one. For example, ignore the freespace on any two of the three shares (such as HUEY and DEWEY).
Guidelines: Alternative Free-Space Reporting	The freespace calculation dir-master-only command is an alternative form of free-space calculation where the volume only shows the free space in one back-end share behind the volume. It chooses the master back-end share for the front-end share to which the client connected. This is useful for volumes where a clients directory tree is exclusively on one back-end share at any given time. If you use this free-space calculation technique, you can also set the client-visible space on each of the volumes shares with the freespace apparent-size command.
Samples	stoweA(gbl-ns-vol[lodges~/skiPatrol])# freespace cifs-quota changes the /skiPatrol volume so that it detects path-based and/or user-based quotas on its back-end shares, and reports only the free space that is allotted to each client.   provA(gbl-ns-vol[provMed~/rns])# no freespace cifs-quota returns the /rns volume to the default. This volume reports the total free space to its clients, without requesting quota-based free space from its back-end filers. If the back-end filers do not support any CIFS quotas, this setting reduces traffic between the managed volume and its filers.
Related Commands	namespace -> volume filer-subshares freespace calculation manual freespace ignore freespace adjust

Purpose	If you used freespace calculate manual to manually calculate free space for this volume, you can use the freespace ignore command to exclude the current share from the free-space calculation. Use no freespace ignore to include the free space from the current share.
Modes	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	freespace ignore no freespace ignore
Default(s)	no freespace ignore
Guidelines	By default, the volume calculates its free space automatically: it takes the sum of all free space on all shares, and it excludes all but one share from any given back-end storage volume. Use the freespace calculation manual command to allow manual exclusions in the current volume, then use this command to ignore each chosen share. You can also use freespace adjust to adjust the amount of free-space that is counted for this share. This can be an alternative to ignoring the shares free space (for example, adjust the space by -100G instead of ignoring it altogether), or you can use it to set your own free-space value for the share (ignore the shares actual space, then adjust the shares free space to +50G). Use the show global-config namespace command to see if this command is set for the share.
Samples	bstnA(gbl-ns-vol-shr[ns1~/vol~shr4])# freespace ignore ignores the free space from shr4.   bstnA(gbl-ns-vol-shr[wwmed~/acct~bills])# no freespace ignore includes the free space from the bills share.
Related Commands	namespace -> volume -> share freespace calculation manual freespace adjust show global-config namespace

Purpose	In some cases, a back-end-CIFS filer does not recognize a Security ID (SID) on a migrated file. CIFS filers typically return an error and reject the file with the unknown SID; the volume therefore assumes that the migration failed and keeps the file on its original share. Some file servers, however, can be configured to return an error and accept the file anyway. EMC Celerra servers have shown this behavior in lab testing. You can use the ignore-sid-errors command to ignore these errors from such a file server. To react to SID errors by canceling the file migration, use no ignore-sid-errors.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	ignore-sid-errors no ignore-sid-errors
Default(s)	no ignore-sid-errors
Guidelines	This command does not apply to an NFS-only namespace. SID errors occur for a SID that is unknown at the destination file server. The SID may be unknown because it came from another file server with Local Groups or Local Users. You can use sid-translation to translate all local SIDs (after some preparation at the filer servers). However, this translation could fail if the filer servers are not fully prepared to support Local Groups. The command causes the share to ignore certain SID errors from its back-end file server and assume that the migration to the file server succeeded. The SID errors, in response to the CIFS set security descriptor request, are STATUS_INVALID_SID, STATUS_INVALID_OWNER, and STATUS_INVALID_PRIMARY_GROUP. When most filers return these errors, they also reject the file. Use this only for file servers that accept the file in spite of the error.
Important: If you use the ignore-sid-errors command, be sure that the filer is configured to accept the file (or directory) itself in spite of any SID errors. If the filer returns a SID error for a file and then drops it, the file is lost if the ARX share is set to ignore-sid-errors.
Samples	bstnA(gbl-ns-vol-shr[medarcv~/rcrds~bulk])# ignore-sid-errors causes the volume to ignore any SID errors from the file server behind the bulk share.   bstnA(gbl-ns-vol-shr[insur~/claims~shr1-old])# no ignore-sid-errors causes the shr1-old share to acknowledge any SID errors from its filer. If the policy engine gets a SID error when it tries to migrate a file or directory, the policy engine cancels the migration.
Related Commands	namespace -> volume -> share sid-translation

Purpose	A managed volume imports files and directories as its clients randomly access them, making file and directory mastership also random. For example, suppose a client accesses /bigDir/latest.txt from a volume with two shares, A and B. Both shares contain a /bigDir directory and share B contains the /bigDir/latest.txt file. This causes the volume to import the share B instance of /bigDir first, so that share B wins the directory conflict. The directory on share B becomes the master directory. The master directory keeps its name and attributes, but the stripe directory in share A may need to have its attributes or name changed for a successful import. You can use the import priority command to set a priority for the current share, so that you determine which shares win these import conflicts. If two shares have different priorities, the higher-priority share wins the conflict. The volume imports its shares in their priority order; the volume waits for all shares of priority A to complete their imports before it begins importing the share(s) of priority B. Use the no import priority command to reduce the share to the lowest priority.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	import priority number no import priority   number (1-65535 characters) is the priority for the current share. The highest priority is 1 (one); a share with a priority of 1 wins any import conflict with any lower-priority share.
Default(s)	65535
Guidelines	This command is strongly recommended for any volume with tiered shares, where one share or set of shares is considered faster and/or more-reliable than the rest. The master instances of all directories should reside on the volumes reliable Tier 1 shares, so that clients can reliably access them. An import priority of 1 on the volumes Tier 1 shares ensures that, wherever there is a directory collision, the Tier 1 share gets the master directory. If a single share has the highest priority in the volume, it wins every import conflict and does not require any other import commands (such as import rename-directories, import rename-files, or import sync-attributes). For any given collision, those commands are only relevant for the lower-priority share. Tiering is implemented with two or more file-placement rules (place-rule) that move higher-priority files to the Tier 1 shares and lower-priority files to other shares. Best practices dictate that you also create a place-rule that puts all the volumes master directories onto its Tier 1 shares, not just the directories that collided on import. To do this, create a filename-fileset that recursively matches everything in the volume (path exact / and recurse), and use the from (gbl-ns-vol-plc) command to have that fileset match directories and promote them. The volume imports any shares with the same priority in parallel.
Guidelines: Import Priority Only Applies to the Current Volume	If multiple volumes are importing their shares at the same time, the import priorities in one volume have no effect on the import priorities in the other volume. For example, if volume /usrs has one or more shares at priority 1 and volume /var has shares at priority 100 (the highest priority in the volume), the priority-100 shares in /var may import at the same time as the priority-1 shares in /usrs.
Guidelines: Share Roots	The first-configured share is assigned the master for the volumes root directory, and the import priority does not change this. To control directory mastership at the volumes root directory, use a place-rule that moves all master directories to your chosen share or share-farm, as described above. Such a place rule ensures that all master directories always reside on the share or share farm where you want them.
Samples	bstnA(gbl-ns-vol-shr[medarcv~/lab_equipment~equip])# import priority 1 sets the highest priority for the equip share. If any files or directories in this share collide with those of a lower-priority share, this share wins the conflict and gets the master instance of the file or directory.   bstnA(gbl-ns-vol-shr[ns1~/vol~shr4])# no import priority resets the shr4 share to the lowest possible priority.
Related Commands	namespace -> volume -> share place-rule import rename-directories import rename-files import sync-attributes

Purpose	There are some cases where it is necessary for a managed volume to rename a directory on import: It collides with an already-imported directory. That is, it has the same name as a directory from an already-imported share, but different file attributes. It collides with an already-imported file with the same name. If the managed volume is allowed to modify files and directories during import, it renames these directories by default. Use the no import rename-directories command to prevent these directory renames in the current share, potentially causing this shares import to fail for directories that collide. Use import rename-directories to permit the managed volume to rename directories in this share.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	no import rename-directories [unmapped-unicode] import rename-directories   unmapped-unicode (optional) causes the import to rename directories with Unicode-only characters in their names. This occurs at multi-protocol (CIFS and NFS) sites where character-encoding nfs was set at a non-Unicode standard (such as UTF-8), but CIFS users named their directories with Unicode characters. This is off by default to protect against unexpected renames in a large multi-protocol volume.
Default(s)	import rename-directories
Guidelines	In a managed volume, two same-named directories from different shares are aggregated by default: the volume presents a single directory to its clients, with all the files from both directories. The directories collide, however, if their file attributes (such as permission settings and group ownership) are different, or if the directorys name is the same as an already-imported file. The gbl-ns-vol modify command configures the volume to rename collided directories. The no import rename-directories command disallows directory renames in this particular share, and instead causes one of two reactions to a directory collision: for a collision with a file: fail the import for this share. for a collision with a directory: if import sync-attributes is set, synchronize the attributes of this shares directory with the already-imported directory. Otherwise, fail the import for this share. To change the rules for modifying files in this share, you can use the import rename-files command. This option is only relevant in the second-imported share and any subsequently-imported shares. If two shares are imported together with different import priorities (see import priority), the share with the higher priority always imports first.
Guidelines: Unmapped Unicode	If a multi-protocol filer uses single-byte character encoding for its NFS names, it typically permits its CIFS clients to use multi-byte characters in their directory names. The multi-byte characters are not mappable from CIFS to the NFS-character encoding; the filer typically creates a filer-generated name (FGN) that NFS clients can use to access the directory. On some filers, the NFS FGN bears no apparent resemblance to the CIFS-side name. A multi-protocol volume does not allow CIFS names with non-mappable characters, so this naming problem causes an import failure by default. If you set the unmapped-unicode option, the volume can rename any such directories on import. Shares with this problem typically fail their initial import because of the default. You can use show reports import-report to see which directories have non-mappable characters, then decide to either manually rename the directories at the filer or allow the volume to do it on the next import. Then retry the import.
Guidelines: Renaming Format	For cases where directory renames are allowed (import rename-directories, the default), the managed volume renames directories using the following syntax: dirName_shareName-importId[-index][.ext]. dirName is the base name of the directory, not including any extension it may have. If it has any characters that are non-mappable between CIFS and NFS, it contains (U+nnnn) in place of each non-mappable character. The nnnn is the Unicode number for the character, shown in hexadecimal format. The name is truncated if it exceeds 256 characters. For example, dir(U+30D2)(U+30AA)_myshare-2. shareName identifies the namespace share. importId is an internal identifier for the import job. -index only appears if multiple files or directories map to this name. It is unique for each such file or directory (for example, renamedDir_1, renamedDir_1-1, renamedDir_1-2, and so forth). .ext is the original extension for the directory, if there was one.
Guidelines: A no modify Import	You can run a mock import of each share to review all directory-naming collisions before actually importing the share. Before you enable a share and start its import, you can disable all volume modifications with no modify. This prevents the volume from changing anything in its shares, and also prevents client access to the volume. Then enable the share to invoke the no modify import (with enable (gbl-ns-vol-shr)). After the no modify import finishes, review the shares import report for naming collisions (as well as any other import issues) and manually correct each issue at the back-end filer. Use show reports type Imp to list all import reports, and show reports report-name to read one. If there were no issues, you can run the modify command to activate the volume and the import is finished. Otherwise, remove the share from the volume (with remove-share nomigrate), then add the share back into the volume to retry the import.
Guidelines: Recovery from Import Failure	If an actual import fails because a directory rename was disallowed, you can use remove-share nomigrate to remove the share from the volume. After the share is removed, you can fix the collisions directly on the filer and then re-import the share into the volume.
Samples	bstnA(gbl-ns-vol-shr[wwmed~/acct~bills])# no import rename-directories disables the renaming of directories in the bills share during an import. If a directory in this share collides with a file in an already-imported share, this share import fails. If it collides with a directory, the share import only succeeds if the import sync-attributes command is set to allow the volume to synchronize the directory attributes. If it has any character that is unsupported by the character-encoding nfs setting, the import fails.   bstnA(gbl-ns-vol-shr[ns1~/vol~shr4])# import rename-directories enables the renaming of directories in the shr4 share during an import.   bstnA(gbl-ns-vol-shr[insur~/claims~shr1-old])# import rename-directories unmapped-unicode permits the insur~/claims~shr1-old share to rename all directories with non-mappable characters in their names.
Related Commands	enable (gbl-ns-vol-shr) import priority import rename-files import sync-attributes modify

Purpose	This command applies only to a managed volume. When a file from the current share has the same name as a file or directory from an already-imported share, the file is said to collide. If the managed volume is allowed to modify files and directories during import, it renames collided files by default. Use the no import rename-files command to prevent these file renames in the current share, causing this shares import to fail for files that collide. Use import rename-files to permit the volume to rename files in this share.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	no import rename-files import rename-files
Default(s)	import rename-files
Guidelines	If the managed volume is allowed to modify files that collide, it renames those files by default. You can use the no import rename-files command to change this default for the current share; this causes the current share to fail its import if any files collide. If the import fails, you can use remove-share nomigrate to remove the share from the volume. After the share is removed, you can fix the collisions directly on the filer and then re-import the share into the volume. You can also use the import rename-directories and import sync-attributes commands to set the rules for directory collisions in this share. This option is only relevant in the second-imported share and any subsequently-imported shares. If two shares are imported together with different import priorities (see import priority), the share with the higher priority always imports first.
Guidelines: Renaming Format	For cases where file renames are allowed (import rename-files, the default), the managed volume renames directories using the following syntax: fileName_shareName-importId[-index][.ext]. fileName is the base name of the file, not including any extension it may have. shareName identifies the namespace share. importId is an internal identifier for the import job. -index only appears if multiple files or directories map to this name. It is unique for each such file or directory (for example, renamedFile_1.doc, renamedFile_1-1.doc, renamedFile_1-2.doc, and so forth). .ext is the original extension for the file, if there was one.
Guidelines: A no modify Import	You can run a mock import of each share to review all file-naming collisions before actually importing the share. Before you enable a share and start its import, you can disable all volume modifications with no modify. This prevents the volume from changing anything in its shares, and also prevents client access to the volume. Then enable the share to invoke the no modify import (with enable (gbl-ns-vol-shr)). After the no modify import finishes, review the shares import report for naming collisions (as well as any other import issues) and manually correct each issue at the back-end filer. Use show reports type Imp to list all import reports, and show reports report-name to read one. If there were no issues, you can run the modify command to activate the volume and the import is finished. Otherwise, remove the share from the volume (with remove-share nomigrate), then add the share back into the volume to retry the import.
Samples	bstnA(gbl-ns-vol-shr[wwmed~/acct~bills])# no import rename-files disables the renaming of files in the bills share during an import. If a file in the bills share collides with an already-imported file or directory, the volume does not import the bills share.   bstnA(gbl-ns-vol-shr[ns1~/vol~shr4])# import rename-files enables the renaming of files in the shr4 share during an import.
Related Commands	enable (gbl-ns-vol-shr) import priority import rename-directories import sync-attributes modify

Purpose	A managed volume, by default, performs a strict check on each directory before importing it: the share import fails if there is any evidence that the directory is already imported by another managed volume. This is an important precaution; no two managed volumes should ever control the same back-end directory. However, you can skip the directory check to increase the speed of the import. Use import skip-managed-check to prevent the volume for checking this shares directories. Use the no import skip-managed-check command to revert to the safer import option.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	import skip-managed-check no import skip-managed-check
Default(s)	no import skip-managed-check
Guidelines	You should only skip the managed-directory check if you are sure that the back-end share is not managed by another ARX volume. For example, you can skip this check for a new filer, the initial cut-in of the ARX, or before an nsck ... rebuild of an existing volume.
Samples	bstnA(gbl-ns-vol-shr[medarcv~/lab_equipment~equip])# import skip-managed-check skips the directory check for a future import of the equip share. This makes imports faster.   bstnA(gbl-ns-vol-shr[ns1~/vol~shr4])# no import skip-managed-check authorizes the slower directory checks for the shr4 share.
Related Commands	namespace -> volume -> share enable (gbl-ns-vol-shr) nsck ... rebuild

Purpose	This only applies to a managed volume. When a directory from the current share has the same name as a directory from an already-imported share, but different file attributes, the directory is said to collide. If the volume is allowed to modify files and directories during import, it renames collided directories by default. Use the import sync-attributes command to allow the managed volume to instead synchronize the directories attributes, rather than renaming them. Use the no form of the command to disallow attribute synchronization for directories.
Modes	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	import sync-attributes no import sync-attributes
Default(s)	no import sync-attributes
Guidelines	In a managed volume, two same-named directories from different shares are aggregated by default: the volume presents a single directory to its clients, with all the files from both directories. The directories collide, however, if their file attributes (such as permission settings and group ownership) are different. The gbl-ns-vol modify command, along with the default for import rename-directories, configures the volume to rename collided directories. This command provides an alternative for the current share: synchronize the directory attributes instead of renaming. For the root directory of each share, renaming is not an option. You can use this option to synchronize all root-share attributes automatically, or you can synchronize the attributes manually at the filers (before the import). As an alternative, you can disable all volume modifications with no modify, review each shares import report for attribute collisions (as well as any other import issues), manually correct these issues at the filer, then retry the import with no enable (gbl-ns-vol-shr) followed by enable. (Use show reports type Imp to list all import reports.) If a directory collides with a file, attribute synchronization is not enough to resolve the conflict. The managed volume must rename the directory (see import rename-directories) or the share import fails. The no form of the command causes one of two reactions to a directory collision: rename the directory (if import rename-directories is set for this share) or fail the import (if no import rename-directories is set).
Note: For heterogeneous multi-protocol namespaces, always enable synchronization with the import sync-attributes command. Both CIFS and NFS attributes are compared in multi-protocol namespaces, greatly increasing the likelihood of directory collisions.
Guidelines (Cont.)	If the import fails, you can use remove-share nomigrate to remove the share from the managed volume. After the share is removed, you can fix the collisions directly on the filer and then re-import the share into the volume. This option is particularly important for CIFS-subshare support, and is very helpful for Access-Based Enumeration (ABE). These synchronize directory-attribute settings, such as subshare ACLs and ABE settings, between the volumes filers. You can use the filer-subshares command to set up subshares for the current volume. Use the cifs access-based-enum command to set up ABE. To change the rules for modifying files in this share, you can use the import rename-files command.
Samples	bstnA(gbl-ns-vol-shr[ns1~/vol~shr4])# import sync-attributes allows the volume to synchronize directory attributes in the shr4 share.   bstnA(gbl-ns-vol-shr[wwmed~/acct~bills])# no import sync-attributes prevents the /acct volume from synchronizing directory attributes in the bills share.
Related Commands	import priority import rename-directories import rename-files

Purpose	Use the managed-volume command to assign a local, managed volume as the back-end filer for the current share. This only applies to shares in direct volumes. Use the no form of the command to remove the managed volume from the share.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	managed-volume namespace volume [access-list list-name] no managed-volume   name (1-30 characters) is the managed volumes namespace. volume (1-1024 characters) identifies the managed volume. list-name (optional, 1-64 characters) is the NFS-access list to associate with the share.
Default(s)	None.
Guidelines	A direct volume has the option to use a managed volume to stand in as a virtual filer for one of its shares. The managed-volume command is analogous to the filer command, which assigns an external-filer share to the current namespace share. Before you use this command in an NFS volume, you must disable the managed-volumes auto reserve files feature. A direct volume requires that any NFS share has a static, unchanging limit on its number of files. If the direct volume supports CIFS, the volume that you use as a virtual filer must be in the same namespace.
Sample	bstnA(gbl-ns-vol-shr[medco~/vol~sales])# managed-volume wwmed22 /04accts assigns the wwmed22~/04accts managed volume as the filer for the sales share.
Related Commands	namespace -> volume -> share direct filer no auto reserve files

Purpose	Each ARX volume shares its memory, CPU time, and other resources with the other volumes in its volume group. On the ARX-500, memory and CPU cycles are less plentiful; the maximum volume groups are therefore set at a lower value on that platform. Raising the number of volume groups could create a resource-contention issue on an ARX-500. On the advice of F5 Support, you can use the max-volume-groups command to raise the maximum to the upper limit. Use the no form of the command to return to the default maximum for volume groups.
Mode	gbl
Security Role(s)	storage-engineer or crypto-officer
Syntax	max-volume-groups no max-volume-groups
Default(s)	2 volume groups
Valid Platforms	ARX-500
Guidelines	This command doubles the maximum volume groups. The default is sufficient for most installations. Use this command only under the guidance of F5 personnel. You can only change this maximum while all volumes are disabled. Use no enable in gbl-ns mode to disable all volumes in a namespace (see the documentation for enable (gbl-ns, gbl-ns-vol)). You cannot reduce the number to a point where current volume-group assignment would be impossible; for example, if a volume is already assigned to volume-group 3, you cannot use no max-volume-groups because it would reduce the maximum to 2 groups. Each volume group uses the memory set by the metadata cache-size command. The ACM processors require at least that much memory for each volume group. The show processors command shows the memory resident to each processor on your system. Use the volume-group command to assign a volume to a group. The show volume-group command shows all volume-to-group assignments.
Samples	canbyA(gbl)# max-volume-groups allows the maximum possible volume groups on the current switch, an ARX-500. This should only be done on the advice of F5 personnel.   canbyA(gbl)# no max-volume-groups resets the maximum number of volume groups back to the recommended default.
Related Commands	volume-group show volume-group metadata cache-size show processors

Purpose	If this switch has a redundant peer, you can use the metadata critical command to declare the metadata for the current managed volume as a critical resource. If an active switch loses access to this volumes metadata share, a failover may occur. Use the no form of the command to remove the critical-resource status from the volumes metadata share.
Modes	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	metadata critical no metadata critical
Default(s)	None
Guidelines	This command marks the volumes current metadata share as a critical resource. If the volume loses contact with its metadata share, the switch where the volume is running may fail over to the peer switch. (The failover occurs only if the peer switch has access to all of its critical resources.) Use the show redundancy critical-services command to see a list of all critical resources on this switch. The ARX tests for failure with a regular ICMP ping. Every 30 seconds, the ARX sends a ping to the metadata shares filer. If the filer fails to respond, the ARX waits an additional 30 seconds before asking the peer if it is possible to fail over. The pings continue indefinitely at 30-second intervals. If the filer responds before the failover is initiated, the failover does not occur. If this switch has a redundant peer, this is recommended for all volumes. This command is irrelevant unless redundancy is configured. See redundancy.
Sample	bstnA(gbl-ns-vol[wwmed~/acct])# metadata critical declares that the metadata share for wwmed~/acct is a critical resource.
Related Commands	namespace -> volume metadata share redundancy show redundancy critical-services

Purpose	Use the metadata share command to make a dedicated metadata share available for the current managed volume, or for all managed volumes in the current namespace. Use the no form of the command to remove the metadata share from the current managed volume or namespace.
Modes	gbl-ns gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	metadata share filer {nfs3|nfs3tcp|cifs} path [cluster cl-name] no metadata share filer {nfs3 | nfs3tcp | cifs} path [cluster cl-name]   filer (1-64) is the name of an external filer; use show external-filer to list all of them. nfs3 | nfs3tcp | cifs chooses the protocol for file-access. This can be outside the set of protocols for the namespace. path (1-900 for NFS, 1-1024 for CIFS) is the share path on the filer (for example, /arx_meta). cl-name (optional, 1-64 characters) is only relevant if the ARX is part of a disaster-recovery (DR) configuration. In a DR configuration, there is an active ARX cluster with one set of filers and a backup cluster with a mirrored set of filers. This determines which cluster uses the filer. Run the metadata share command twice per volume if you use DR: once to designate the metadata shares host at the active cluster, and again to determine the metadata host at the backup cluster. Use show cluster for a list of configured clusters. If you omit this option, the CLI applies the change to the local cluster.
Default(s)	None
Guidelines	A CIFS namespace can use a CIFS or NFS metadata-only share, but an NFS namespace is limited to metadata-only shares that also support NFS. An NFS namespace does not have the proxy-user (gbl-ns) credentials that it needs to access a CIFS metadata-only share. If this switch has a redundant peer, use the gbl-ns-vol metadata critical command to declare the volumes metadata-only share as a critical resource. If possible, use one metadata share per managed volume. Multiple managed volumes and/or namespaces can use the same metadata-only share, but this is not recommended. A metadata share should reside on an extremely fast and reliable filer. Ideally, it should reside in its own file system on the same filer where you store the ARX volumes Tier 1 shares. The show statistics metadata command shows the latency between the ARX and its metadata shares. You can use the nsck ... migrate-metadata command to migrate a volumes metadata to a new filer, even after the volume has imported all of its back-end shares. This takes the volume offline during the migration. It is a safe operation in that it reverts the volume back to its original metadata share if it is interrupted. For the best volume performance, configure all NFS-metadata shares with the sync and no_wdelay options. These options cause the back-end NFS service to synchronously write to disk without any caching, to improve both reliability and speed. You set these options at the back-end filer, in the configuration for the NFS export. This is not an issue with CIFS-metadata shares, which perform synchronous writes to disk on request. Do not store your metadata on /vol/vol0 on a NetApp filer. This is where the NetApp filer keeps its operating system; it is not intended for fast access.
Sample	bstnA(gbl-ns[wwmed])# metadata share nas1 nfs3 /vol/vol1/meta1 sets a metadata-only share to hold all managed-volume metadata for the wwmed namespace.
Related Commands	metadata critical show external-filer show global-config namespace nsck ... migrate-metadata show statistics metadata

Purpose	When a managed volume imports files, the import fails if there are any file collisions (that is, if the same file name and path exist on two or more shares). Further, clients cannot modify any files in the volume; the volume is read-only after the import. To allow managed-volume modifications, use the modify command. Use the no form of the command to prevent all modifications to imported files.
Modes	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	modify no modify
Default(s)	no modify
Guidelines	This command does not apply to direct volumes (see direct); only metadata-based managed volumes. The CLI prompts you with a question about nsck rebuild. The nsck ... rebuild command takes the volume offline and re-imports with a single command. Answer yes to turn modify on after a rebuild, or answer no to leave it off. A no answer makes the volume read-only after any re-import. If you answer no, you can use the reimport-modify command to achieve the same effect. If the modify command is in effect when the volume is enabled, it renames collided files according to the following syntax: pathname_share-jobid.ext where pathname is the original pathname minus any extension that the file may have had, share is the name of the namespace share that imported the file, jobid is a unique ID number for this import job, and ext is the files original extension. Directories are only renamed if they have the same name as a previously-imported file, or if they have different file attributes (such as permissions settings) than an already-imported directory. A directory is renamed according to the same conventions as a file. Whether or not you enabled modifications before import, each shares import report shows any and all duplicate files and directories in the share. Use show reports to get a list of import reports. Import reports are named import.share-id.share-name.job-id.rpt. Use show reports import-report to view the contents of an import report. Duplicate files and directories are each called out in a separate line starting with Duplicate.
Guidelines (Cont.)	If you enable a volume without modify enabled, clients cannot write to the volume. This creates an opportunity to check the import reports and resolve any file conflicts at your back-end filers. If there where no collisions, use the modify command to enable the volume for client writes. If there were collisions, correct them at the back-end and/or accept them. Then use the nsck ... destage command to take the volume offline, allow modifications with modify, then use enable (gbl-ns-vol-shr) on each of the volumes shares.
Guidelines: A no modify Import	You can opt to test an import before committing it with a no modify import. This means importing to the managed volume with the modify flag down, then checking all of the import reports for collisions or other issues. Use show reports type Imp to list all import reports, and show reports report-name to read one. If no issues occurred, you can use the modify command after the import to allow write access to clients.
Guidelines: Per-Share Exceptions	You can protect certain shares in the managed volume from file and/or directory renaming. Use the no import rename-files command to disallow file renames in a particular share. Use no import rename-directories to disallow directory renames. To allow the volume to synchronize the attributes of matching directories instead of renaming them, use import sync-attributes; if the volume is allowed to synchronize attributes or rename directories, it synchronizes the directory attributes. The above preference only applies to directories that collide with other directories. For a directory that collides with an already-imported file, the conflict cannot be resolved with an attribute change. Shares in multi-protocol volumes have an additional import option for directories: import rename-directories unmapped-unicode. This allows the volume to rename directories whose names contain non-mappable characters; that is, multi-byte characters that are supported by CIFS but not by the setting for character-encoding nfs.
Samples	bstnA(gbl-ns-vol[wwmed~/acct])# modify Automatically re-enable volume modify mode during nsck rebuild? [yes/no] yes allows the wwmed~/acct volume to modify its back-end shares.   bstnA(gbl-ns-vol[ns1~/])# no modify disallows modifications for the / volume in the ns1 namespace.
Related Commands	namespace -> volume enable (gbl-ns-vol-shr) show reports nsck ... destage nsck ... rebuild reimport-modify import rename-files import rename-directories import sync-attributes

Purpose	A named stream (or Alternate Data Stream) is a hidden file with meta-information about the main file, such as a summary description or a thumb-nail graphic. If any back-end-CIFS filer does not support named streams, you must disable the feature for its namespace volume. This applies to volumes in namespaces that support CIFS, not in NFS-only namespaces. Use the no named-streams command to stop the volume from using named streams. Use the affirmative form, named-streams, to reinstate named streams.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	no named-streams named-streams
Default(s)	The volume probes the filer behind its first-enabled share and uses the named-streams setting from there.
Guidelines	The Windows Explorer application uses named streams for the Properties -> Summary information; a volume that does not support named streams may not be able to provide any information for the Summary tab. Similarly, a volume without named streams may not support thumb-nail views of its graphics files. You cannot enable a share if its volume supports named streams and its back-end-CIFS filer does not. The enable operation fails with an error that lists all CIFS features that must be disabled, possibly including this one. Use the enable (gbl-ns, gbl-ns-vol) command to enable all shares in a new namespace, or use the enable (gbl-ns-vol-shr) command to enable a new share in an already-enabled namespace. Use the enable (gbl-ns-vol-shr) command to enable a share. If you remove the share(s) or upgrade the back-end filer(s), you can reinstate this feature for the volume. See the ARX CLI Maintenance Guide for instructions on removing a share from a namespace. You can use the show exports command to see all CIFS options for the share. CIFS clients only see the results of this command if they connect after you invoke it.
Guidelines: Advertised File-System Type	This CIFS option, together with three others, determines the File-System type (NTFS or a FAT file system) that the managed volume advertises to its CIFS clients. Client applications may query the file-system type and use it to customize the way it presents files; for example, if the managed volume advertises that it is a FAT file system, a client application may show old-style file-access times for the volumes files. The volume advertises one of three file-system types, depending on the CIFS options supported by its back-end shares: NTFS - if the volume supports named-streams, persistent-acls, unicode-on-disk, and all of the volumes back-end shares preserve case in their file/directory names (MyFile.txt is not converted to MYFILE.TXT). FAT32 - if the volume supports unicode-on-disk and case preservation, but not the others. FAT - if the volume supports none of the above options. On the advice of F5 Support, you can use the cifs file-system-name command to manually set this file-system name.
Samples	bstnA(gbl-ns-vol[medarcv~/usr])# no named-streams shuts off named streams for the /usr volume in the medarcv namespace.   bstnA(gbl-ns-vol[ns1~/])# named-streams reinstates named streams for the / volume in the ns1 namespace.
Related Commands	namespace -> volume enable (gbl-ns, gbl-ns-vol) enable (gbl-ns-vol-shr) show exports

Purpose	Use the nfs-param command to change the NFS read size or write size between the current volume and its back-end shares. Use the no form of the command to revert to the default.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	nfs-param {rsize | wsize} {1024 | 2048 | 4096 | 8192 | 16384 | 32768 | 65536} no nfs-param {rsize | wsize}   rsize | wsize determines if this is the NFS-read size or write size. 1024 | ... 65536 is the size of reads or writes, in bytes.
Default(s)	8192
Guidelines	The nfs-param command sets the size of NFS reads or writes from a volume to its back-end shares. This parameter applies only to volumes that support NFS. Confirm that all filers behind the volume can support the read and/or write size that you choose.
Samples	bstnA(gbl-ns-vol[wwmed~/acct])# nfs-param rsize 16384 bstnA(gbl-ns-vol[wwmed~/acct])# nfs-param wsize 16384 sets the same read and write sizes for the wwmed~/acct volume.   bstnA(gbl-ns-vol[ns1~/])# no nfs-param rsize reverts to the default NFS-read size in ns1~/.
Related Commands	namespace -> volume

Purpose	A volume with persistent Access-Control Lists (ACLs) can display the ACLs of its files and directories to its clients. If any of the volumes back-end-CIFS filers do not also support persistent ACLs, you must disable this feature for the volume. This applies to volumes in namespaces that support CIFS, not volumes in NFS-only namespaces. Use the no persistent-acls command to stop the volume from supporting persistent ACLs. Use the affirmative form, persistent-acls, to reinstate persistent ACLs.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	no persistent-acls persistent-acls
Default(s)	The volume probes the filer behind its first-enabled share and uses the persistent-acls setting from there.
Guidelines	This is only recommended for volumes whose back-end filers all share this limitation. We do not recommend mixing shares that support ACLs with shares that cannot. This controls the CIFS-client view of ACLs in the volume. If a Windows client accesses the Properties for any of the volumes files or directories, the Security tab does not appear unless the volume has the persistent-acls setting. You cannot enable a share if its volume supports persistent ACLs and its back-end-CIFS filer does not. The enable operation fails with an error that lists all CIFS features that must be disabled, possibly including this one. Use the enable (gbl-ns-vol-shr) command to enable a share. A volume with no persistent-acls does not copy ACLs from one back-end share to another when it performs migrations. This applies to all migrations, including migrations between two filers that support persistent ACLs. This may be surprising in a volume backed by filers that cannot support ACLs and other filers that can support them. As stated above, we do not recommend mixing ACL-supporting filers with non-ACL-supporting filers behind the same managed volume. If you remove the share(s) or upgrade the back-end filer(s), you can reinstate this feature for the volume. See the ARX CLI Maintenance Guide for instructions on removing a share from a namespace. You can use the show exports command to see all CIFS options for the share, including persistent ACLs.
Guidelines: Advertised File-System Type	This CIFS option, together with three others, determines the File-System type (NTFS or a FAT file system) that the managed volume advertises to its CIFS clients. Client applications may query the file-system type and use it to customize the way it presents files; for example, if the managed volume advertises that it is a FAT file system, a client application may show old-style file-access times for the volumes files. The volume advertises one of three file-system types, depending on the CIFS options supported by its back-end shares: NTFS - if the volume supports named-streams, persistent-acls, unicode-on-disk, and all of the volumes back-end shares preserve case in their file/directory names (MyFile.txt is not converted to MYFILE.TXT). FAT32 - if the volume supports unicode-on-disk and case preservation, but not the others. FAT - if the volume supports none of the above options. On the advice of F5 Support, you can use the cifs file-system-name command to manually set this file-system name.
Samples	bstnA(gbl-ns-vol[medarcv~/usr])# no persistent-acls shuts off persistent ACLs for the /usr volume in the medarcv namespace.   bstnA(gbl-ns-vol[ns1~/])# persistent-acls reinstates persistent ACLs for the / volume in the ns1 namespace.
Related Commands	namespace -> volume enable (gbl-ns-vol-shr) show exports

Purpose	An nsck ... destage or nsck ... rebuild shuts off the volumes modify setting as it takes the volume offline. The modify flag stays down when the shares reimport, so the volume does not modify any re-imported files and clients cannot modify the volume. To keep the modify flag up during a re-import, use the reimport-modify command. Use the no form of the command to prevent all modifications to re-imported shares.
Modes	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	reimport-modify no reimport-modify
Default(s)	no reimport-modify
Guidelines	This command does not apply to direct volumes (see direct); only metadata-based managed volumes. Raise this flag before you use nsck to rebuild or otherwise take the volume offline. The flag is only effective for future rebuilds. The CLI prompts for confirmation before raising the flag; answer yes to continue. The modify command determines whether or not modifications occur; this command determines whether or not to re-instate the volumes modify status after the volume is taken offline. This is an extra security measure to ensure that the system avoids any unexpected file renames. When you invoke the modify command, a prompt requests whether or not you want to set this flag at the same time. Whether or not you enabled modifications before import, each shares import report shows any and all duplicate files and directories in the share. Use show reports to get a list of import reports. Import reports are named import.share-id.share-name.job-id.rpt. Use show reports import-report to view the contents of an import report. Duplicate files and directories are each called out in a separate line starting with Duplicate.
Samples	bstnA(gbl-ns-vol[wwmed~/acct])# reimport-modify   Automatically re-enable volume modify mode during NSCK rebuild? [yes/no] yes allows the wwmed~/acct volume to modify its back-end shares after nsck brings it back online.   bstnA(gbl-ns-vol[ns1~/])# no reimport-modify causes nsck to turn off the modify flag if it takes the / volume offline.
Related Commands	namespace -> volume enable (gbl-ns-vol-shr) show reports nsck ... destage nsck ... rebuild

Purpose	You can designate a managed-volume share as a repository for snapshots, where the back-end filer behind the share holds snapshots from another share in the volume. You can use filer-replication methods to duplicate the files and directories from one filer to another, and you can take snapshots at the second filer without using disk space on the first. Use the replica-snap command to indicate that the current share is dedicated to snapshot storage in this way. This indicates that the managed volume should only present the back-end shares snapshots, and ignore any non-snapshot data. The managed volumes clients can then access these snapshots and restore previous versions of their files as needed. Use the no replica-snap command to change the current share to a standard client-data share.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	replica-snap no replica-snap
Default(s)	no replica-snap
Guidelines	This command has no effect in a direct volume. You can only run this command when the share is disabled (no enable (gbl-ns-vol-shr)). If the managed volume has already imported the shares primary storage, you must destage the volume to use the share (see nsck ... destage). Typically, the command is applied to new shares. You cannot use no replica-snap after the share is enabled, but you can use no share to remove a replica-snap share. This removes all of the shares snapshots from client view. After you designate the share as a replica-snap share, you create a replica-snap-rule to create managed snapshots on it. You can use the gbl-ns-vol snapshot replica-snap-rule command to create this rule. As mentioned above, clients see the snapshots from this share instead of the shares files and directories, and access those snapshots through their usual method (such as the Previous Versions tab). To present any snapshots created previously, you can use the snapshot manage command.
Important: The managed volume cannot write to most replica-snap shares, so it cannot check a replica-snap share to see if another ARX owns it (see the documentation for enable (gbl-ns-vol-shr) ... take-ownership). Do not use the same replica-snap share behind two different ARXes, unless they are a redundant pair.
Guidelines (Cont.)	If your managed volume uses tiered storage where recently-changed files reside on tier-1 shares and unchanged files reside on tier 2, we recommend one or more replica-snap shares per tier-1 share. The tier-2 shares have files that are unchanged, so they do not require snapshots. (You can use the place-rule command to configure tiered storage.)
Guidelines: Some Filer-Replication Applications Overwrite ARX Snapshots	Some filer-replication applications are volume-level, and copy the entire contents of the back-end share to the replica-snap share, including the filer snapshots. This would overwrite any snapshots that the ARX takes at the replica-snap share, and defeat the snapshot replica-snap-rule. Do not use volume-level replication to copy the source shares contents to the replica-snap share.
Guidelines: Filer Latency	Slow responses from a replica-snap share may cause slow responses for client access to files, too. The filer host for your replica-snap shares should not have an excessively long file-access latency.
Samples	bstnA(gbl-ns-vol-shr[medarcv~/lab_equipment~equipSnap])# replica-snap designates the equipSnap share as a replica-snap share. The managed volume only presents snapshots from this share to its clients.   bstnA(gbl-ns-vol-shr[ns1~/vol~shr6])# no replica-snap resets the shr6 share to be a standard file-storage share.
Related Commands	namespace -> volume -> share enable (gbl-ns-vol-shr) snapshot replica-snap-rule snapshot manage nsck ... destage

Purpose	A managed volume requires one file credit for each of its files and directories. By default, the volume automatically increases its file credits as its number of files increases, but there are rare circumstances where you must manually set a volumes file credits. After you turn off auto reserve files for such a volume, you can use the reserve files command to manually set its file credits. You can also use this command with auto-reserve enabled, though the auto-reserve feature may later change the number of reserved files. Use the no form of the command to revert to a static default for the managed volume.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	reserve files files no reserve files   files (4,096 to 128,000,000 (ARX-500) or to 256M (all other platforms)) is the new number of files to reserve for the volume. The maximums on your chassis may be lower due to your software license; use show active-license to see the limits imposed by your software license.
Default(s)	4,000,000 (4M) files if auto reserve files is set 64M files if no auto reserve files is set
Guidelines	Each file and directory in a managed volume (as opposed to a direct volume) uses one file credit. By default, the managed volume automatically takes more file credits as it grows. This automatic growth is the auto reserve files feature. The reserve files command sets the current number of reserved files if the auto-reserve feature is enabled; the auto reserve feature may then increase the number of file credits from there. This command is more effective in a volume where you must turn off the auto-reserve feature; it sets a permanent file-credit reservation in this case. You must disable the feature (with no auto reserve files) in a volume used as a filer by an NFS-supporting direct volume. The documentation for auto reserve files discusses this further. Each volume group supports a maximum of 384 Million (M) file credits. The ARX-500 can support 2 volume groups, and the ARX-2000 supports 12. The ARX-4000 supports 16 volume groups, but each volume group on the ARX-4000 supports a lower maximum (256M). This is the ceiling for the sum of all reserved files for all volumes in the volume group. You can use the show volume-group command to list the current number of reserved files for each volume; see the File credits section of the output.
Sample	bstnA(gbl-ns-vol[archives~/multimedia])# reserve files 5000000 reserves 5000000 files for the /multimedia volume.
Related Commands	namespace -> volume auto reserve files show volume-group

Purpose	Use the restart namespace ... volume command to restart processing in a specific volume. This also restarts all other volumes that run in the same volume group.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	restart namespace name volume volume [dump-core]   name (1-30 characters) identifies the namespace. volume (1-1024 characters) is the volume to restart. All volumes in the same volume group will also restart. Use to show volume-group see the assignments of volumes to volume groups. dump-core (optional) causes the namespace process to write out its memory contents in a core-memory file. F5 personnel can examine this core file to diagnose problems with the namespace. This slows the restart; use this option only on the advice of F5 personnel.
Default(s)	None.
Guidelines	The CLI prompts for confirmation before restarting the namespace volume(s). If any front-end services export any of the affected volumes, the prompt lists the services. Enter yes to proceed. This restarts all of the volumes in the chosen volumes group. A volume group can fail over from one chassis to another in a redundant configuration. It is also a failure domain for a group of volumes in the same namespace; if one of the volumes restarts, they all restart together. Use the show volume-group command to show all volume groups and their volumes. Before a volume is enabled, you can use volume-group to assign it to a group.
Sample	bstnA# restart namespace wwmed volume /acct   The Volume Group hosting namespace 'wwmed', volume '/acct' is in use by NFS global service 'ac1.medarch.org'.   These services will experience a brief outage as the Volume Group hosting the namespace 'wwmed', volume '/acct' is restarted.   Do you wish to proceed? [yes/no] yes restarts the wwmed~/acct volume, along with any other volumes in its volume group.
Related Commands	show volume-group volume-group

Purpose	Use the no form of the command to delete a managed-volume share.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	share name name (1-64 characters) is the name you choose for the share.   no share name no share name relocate-dirs target-share [remove-file-entries [verbose] [offline]] name (1-64 characters) identifies the share to remove. relocate-dirs is required if you are removing an already-imported share from a managed volume. This is never required in a direct volume or a replica-snap share. target-share (1-64 characters) is another share in the same managed volume. The volume migrates all master directories in the current share to this target. You can enter the optional flags (remove-file-entries, offline, and verbose) in any order. As above, these options only apply to managed volumes and never apply to replica-snap shares: remove-file-entries removes all files from volume metadata that still reside on this back-end share. verbose (optional, if you choose remove-file-entries) causes the operation to list all removed files in its removeShare report. offline (optional, if you choose remove-file-entries) is only for back-end shares that are offline or otherwise unreachable. This forces the disconnect without scanning the back-end for its directory attributes. Relocated master directories therefore have all of their file attributes set to 0 (zero).
Default(s)	None
Guidelines	A share maps to a CIFS share or NFS export on back-end storage. Use the share command to add a share in a managed volume or a direct volume (see direct). The CLI prompts for confirmation before creating a new share; enter yes to continue. (You can use terminal expert to eliminate confirmation prompts for creating new objects.) This places you in gbl-ns-vol-shr mode, where you must use the filer command to identify a filer and export/share, and then use the enable (gbl-ns-vol-shr) command to import the export/share. In a direct volume, you also use the attach command to map one or more attach-point directories in the share to physical directories on the back-end filer.
Guidelines: no share	You can remove the share with the simple no share command before it is first imported. There is no import for a share in a direct volume or for a replica-snap share, so you can use this simple form any time in those cases. After a managed-volume share has been imported, you can use a place-rule to migrate all of its files to other shares in the volume. If the volume supports snapshots (with a snapshot rule, notification rule, or similar rule), we recommend waiting until all retained snapshots have aged out before removing the volume. After the last of the current snapshots is gone, none of the snapshots on this share have any record of any files in the volume. At that point, you can safely remove the share.
	After the files (and, possibly, snapshots) are cleared, you use the relocate-dirs argument in no share to relocate the shares master directories, too. (A volume typically has multiple copies of its directories in each share, so that it can migrate files between them; a master directory is the first-imported (or only) instance of a directory in a volume.) The volume scans the back-end share for the file attributes of these directories, to be duplicated at the target-share. If this is impossible because the back-end share is offline, use the offline flag (along with the remove-file-entries flag) to create new instances of the directories with zeroed-out file attributes. The CLI creates a removeShare report to show the progress of the no share command. Each report is named removeShare.share-name.rpt, where share-name is the ARX-share name (not the name of the share at the filer). The no share command fails if any of the client-visible files in the volume are on the share; the remove-file-entries flag removes the files from the volume metadata and allows the no share operation to succeed. The number of files removed appears in the removeShare report. The additional verbose flag adds the names of each removed file into the report. The additional offline flag, described above, applies to unreachable filers. As an alternative to no share in a managed volume, you can use remove-share migrate to remove an imported managed-volume share, remove-share nomigrate to remove a managed-volume share that failed to import, or remove-share offline to remove a share that is unreachable.
Samples	bstnA(gbl-ns-vol[archives~/multimedia])# share lun77 This will create a new share.   Create share 'lun77'? [yes/no] yes bstnA(gbl-ns-vol-shr[archives~/multimedia~lun77])# creates a share named lun77 in the current managed volume.   bstnA(gbl-ns-vol[archives~/multimedia])# no share nas15 deletes the nas15 share from the volume.   bstnA(gbl-ns-vol[ns1~/])# no share test relocate-dirs share4 removes the test share, migrating all of its master directories to share4 in the ns1~/ volume.
Related Commands	namespace -> volume show namespace show global-config namespace show namespace status filer enable (gbl-ns-vol-shr) place-rule remove-share migrate remove-share nomigrate

Purpose	Use the show share status command to view the current status of all namespace shares on the ARX.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show share status
Guidelines	The output contains a small table for every volume on the ARX. This information is an summary of the data from show namespace. Each volume starts with a single-line summary. The summary contains the following fields: NS identifies the namespace. Vol is the path name of the volume. MD is a high-level status of the volumes metadata share. This appears in used/free format, where used is the amount of space used for the volumes metadata, and free is the space remaining on the metadata share. You can ignore these numbers for a direct volume, which does not use a metadata share. I/VG is the volumes Instance ID (used internally) and volume-group number, separated by a slash (/). Files shows the number of files used and free, along with the maximum file allowable in volume. The maximum is labeled (automatic) for a volume with auto reserve files enabled.
	Below each summary line is a table of the volumes shares, one row for each share. Each row contains two fields: Share Name is the name established by the share command. Status is the same share status documented for the show namespace command (see Guidelines: Share-Import Status, Guidelines: Disable/Removal Status, and Table 21.1 on page 21-49). You can use this to watch the progress of a share import.
Sample	bstnA# show share status shows the share status for all configured volumes. For sample output, see Figure 22.4 on page 22-84.
Related Commands	show namespace status show namespace

Purpose	Use the show sid-translation command to view the translation of a user or group name to a numeric security ID (SID), or from SID to name. This shows the translation for every share in the current volume.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	show sid-translation {user | group | sid}   user | group | sid chooses the entity to translate: user (1-256 characters) is a Windows user name. group (1-256 characters) is a Windows group name. sid (1-256 characters) is a numeric SID; this does a reverse translation to the corresponding user or group name.
Guidelines	This command does not apply to an NFS-only namespace. The output shows the SID-to-name translation from each share in the current volume: Share is the name of the namespace share. SID is the globally-unique ID to identify the principal (user or group) below. Name is the name of the requested user, group, or SID. In parenthesis is the type of this principal: user, group, domain, alias (a locally-defined principal), well-known group (such as everyone), deleted account, invalid, or unknown. If any of the shares have unique translations, some or all of the shares are configured for Local Groups. If the volume migrates a file to or from a share with Local Groups, the volume must translate the SID to a name on the source share and then translate it back on the destination share.
	For any share whose filer uses Local Groups, use the gbl-ns-vol-shr sid-translation command to tell the volume to translate all of its SIDs.
Sample	bstnA(gbl-ns-vol[medarcv~/rcrds])# show sid-translation jqpublic SID Translations:   Share rx SID: S-1-5-21-448539723-1844237615-725345543-1217 Name: MEDARCH\jqpublic (user)   Share charts SID: S-1-5-21-448539723-1844237615-725345543-1217 Name: MEDARCH\jqpublic (user)   Share bulk SID: S-1-5-21-448539723-1844237615-725345543-1217 Name: MEDARCH\jqpublic (user)
Related Commands	namespace -> volume -> share sid-translation

Purpose	A volume is permanently assigned to a volume group when it is enabled. The volume group shares a memory pool as well as CPU cycles and other resources. Use the show volume-group command to view the current volume-group assignments.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show volume-group [id] [detailed] [legacy]   id (optional, 1-255) identifies a particular volume group. If you omit the number, this command displays all volume groups. detailed (optional) adds details to the output: the current CPU and memory usage for each processor behind the volume group. legacy (optional) presents the same output using terminology from former ARX releases, where volume groups were called VPU domains, and there were two or more of them in each VPU.
Guidelines	This applies to the current switch only, not both switches in a redundant pair. To see the volume groups in the redundant peer, log into that peer and run the command from its CLI. System Credits is a table of system-wide limits for the ARX: Share credits lists the number of shares configured in the system, share credits remaining, and the total number of shares allowed. These are managed-volume shares, not direct-volume shares. Direct Share credits lists the number of direct shares in the system, direct-share credits remaining in this ARX, and the total number of direct shares allowed in the ARX. Direct shares are the shares in a direct volume; a direct volume is declared with the direct command. Volume credits lists the number of volumes currently in the system, volume credits remaining, and the total number of volumes allowed. File credits lists the number of files currently in the system, file credits remaining, and the total number of files allowed. These credits only apply to a to the managed volumes on the system. A volume automatically sets its file-credit reservation if it has auto reserve files enabled. You can manually set the number of file credits with the reserve files command. The n credits remain is not a guarantee for any given volume in the system. Other volumes in other volume groups draw from the same pool of file credits. If the systems file credits are sufficiently low, all volumes in the system share the same credits; if volume A uses 100 file credits, volumes B and C each lose 100 remaining credits, too.
Guidelines (Cont.)	Volume Group n is a table to describe one of the volume groups on this system. One of these tables appears per volume group: Physical Processor shows the actual CPU where the volume group is running. If you used the detailed keyword, this also shows current CPU and memory usage. State is one of the following: off means that there is no physical CPU to back this volume group. empty means that there are no volumes assigned to the group. Normal indicates that there is room for more namespaces or volumes on this volume group. If credits have run out for one or more of these categories, one or more qualifiers appears here: - partially used indicates there is room for at least one more volume. - maximum instances means that you can add no more volume groups to the namespace. Both volume groups have a namespace assigned to them. - maximum volume capacity means that you cannot add any more volumes to the group. Degraded means that too many volume groups are sharing the same memory and processor resources. This only occurs after a failover between redundant peers. Unrunnable is very rare. This appears only if multiple hardware failures reduce the hardware resources to the level where there is not enough memory and/or CPU cycles to continue running the current volume group. Error is an unexpected error; please contact Customer Support if you see this. Share credits lists the number of managed-volume shares configured in the volume group, share credits remaining, and the total number of shares allowed. Direct Share credits lists the number of direct shares in the volume group, direct-share credits remaining, and the total number of direct shares allowed in the volume group. Direct shares are the shares in a direct volume; a direct volume is declared with the direct command. Volume credits lists the number of volumes currently in the volume group, volume credits remaining, and the total number of volumes allowed. File credits lists the number of files currently in the volume group, file credits remaining, and the total number of files allowed. These credits only apply to the managed volumes on the system. A volume automatically sets its file-credit reservation if it has auto reserve files enabled. You can manually set the number of file credits with the reserve files command. Then there is a table of namespaces and volumes assigned to the volume group, showing the state of each volume. If you select the legacy option, an additional column shows the VPU and VPU-domain number of the volume group; these are offered for users of former ARX releases that used this terminology. Use the volume-group command to assign a volume to a group. Use the nsck ... migrate-volume command to re-assign a volume from one group to another.
Samples	bstnA# show volume-group shows all volume groups on the system. See Figure 22.5 on page 22-89.   bstnA# show volume-group 1 focuses on volume group 1. See Figure 22.6 on page 22-90.   stkbrgA# show volume-group 1 detailed shows volume group 1 on another chassis, with CPU and memory usage. See Figure 22.7 on page 22-91.
Related Commands	volume-group nsck ... migrate-volume auto reserve files reserve files

Purpose	One or more of your back-end CIFS filers may be configured for Local Groups and users. These filers use local Security IDs (SIDs) for their group/user names instead of those issued by the Domain Controller (DC). To migrate a file to or from a share with Local Groups, the volume must translate the group SIDs in the files Access Control List (ACL). Use the sid-translation command to enable SID translation for the current share. To disable SID translation for this share, use no sid-translation.
Mode	gbl-ns-vol-shr
Security Role(s)	storage-engineer or crypto-officer
Syntax	sid-translation no sid-translation
Default(s)	no sid-translation
Guidelines	This command does not apply to an NFS-only namespace. Whenever the volume migrates a file to or from a share tagged for SID translation, it translates each SID to a group name (at the source share), then translates the group name back to a SID (at the destination share). This ensures that the final SID is one that is properly configured at the destination filer. All filers behind the volume should support all of each others local-group names. If a file tagged with local-group name, staff, migrates to another filer without any definition for a staff group, the volume copies the group SID without translating it. The SID is invalid on the filer, though it will be valid if it migrates back later. While the file remains on that filer, all Access Control Entries (ACEs) using that SID are ignored. To avoid these translation failures, duplicate all local group names and user names on all of the filers behind the volume.
	Some filers return SID errors for unknown SIDs. This can occur if SID translation fails, due to one filer lacking a local-group or local-user name that is present on the other filers. By default, the policy engine cancels the migration if it receives a SID-translation error. Some file servers (for example, EMC Celerra servers) return errors for unknown SIDs but accept the file or directory anyway. You can use the ignore-sid-errors command to ignore the SID errors from these file servers. Use the gbl-ns-vol show sid-translation command to translate SIDs to names or names to SIDs for every share in the volume.
Samples	bstnA(gbl-ns-vol-shr[medarcv~/rcrds~bulk])# sid-translation causes the volume to translate SIDs for all files migrated to the bulk share.   bstnA(gbl-ns-vol-shr[insur~/claims~shr1-next])# sid-translation causes the volume to translate SIDs for all files migrated to the shr1-next share.
Related Commands	namespace -> volume -> share ignore-sid-errors show sid-translation

Purpose	Some applications create holes in files with no data (that is, all zeros); a volume that supports sparse files like these does not use any disk space for those holes. If any back-end-CIFS filer does not support sparse files, you must disable the feature for its namespace volume. This applies to volumes in namespaces that support CIFS, not in NFS-only namespaces. Use the no sparse-files command to stop the volume from using sparse files. Use the affirmative form, sparse-files, to reinstate sparse files.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	no sparse-files sparse-files
Default(s)	The sparse-files setting at the first-enabled share.
Guidelines	If the volume does not support sparse files, files with large blocks of zeros (or holes) use up disk space as though the holes are filled with substantive data. You cannot enable a share if it supports sparse files and its back-end-CIFS filer does not. The enable operation fails with an error that lists all CIFS features that must be disabled, possibly including this one. Use the enable (gbl-ns-vol-shr) command to enable a share. If you remove the share(s) or upgrade the back-end filer(s), you can reinstate this feature for the volume. See the ARX CLI Maintenance Guide for instructions on removing a share from a namespace. You can use the show exports command to see all CIFS options for the share.
Samples	bstnA(gbl-ns-vol[medarcv~/lab_equipment])# no sparse-files shuts off sparse files for the /lab_equipment volume in the medarcv namespace.   bstnA(gbl-ns-vol[ns1~/])# sparse-files reinstates sparse files for the / volume in the ns1 namespace.
Related Commands	namespace -> volume enable (gbl-ns-vol-shr) show exports

Purpose	A volume that supports unicode on disk can support file names with any of the multi-byte characters (such as Korean or Japanese characters) supported by the Unicode character set. If any back-end-CIFS filer does not support Unicode file names on disk, you must disable the feature for its namespace volume. This applies to volumes in namespaces that support CIFS, not in NFS-only namespaces. Use the no unicode-on-disk command to stop the volume from using Unicode file names on disk. Use the affirmative form, unicode-on-disk, to reinstate Unicode file names on disk.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	no unicode-on-disk unicode-on-disk
Default(s)	The volume probes the filer behind its first-enabled share and uses the unicode-on-disk setting from there.
Guidelines	A Windows client cannot use multi-byte Unicode characters in any file or directory names unless the volume supports unicode on disk. You cannot enable a share if it supports Unicode file names on disk and its back-end-CIFS filer does not. The enable operation fails with an error that lists all CIFS features that must be disabled, possibly including this one. Use the enable (gbl-ns-vol-shr) command to enable a share. If you remove the share(s) or upgrade the back-end filer(s), you can reinstate this feature for the volume. See the ARX CLI Maintenance Guide for instructions on removing a share from a namespace. You can use the show exports command to see all CIFS options for the share.
Guidelines: Advertised File-System Type	This CIFS option, together with three others, determines the File-System type (NTFS or a FAT file system) that the managed volume advertises to its CIFS clients. Client applications may query the file-system type and use it to customize the way it presents files; for example, if the managed volume advertises that it is a FAT file system, a client application may show old-style file-access times for the volumes files. The volume advertises one of three file-system types, depending on the CIFS options supported by its back-end shares: NTFS - if the volume supports named-streams, persistent-acls, unicode-on-disk, and all of the volumes back-end shares preserve case in their file/directory names (MyFile.txt is not converted to MYFILE.TXT). FAT32 - if the volume supports unicode-on-disk and case preservation, but not the others. FAT - if the volume supports none of the above options. On the advice of F5 Support, you can use the cifs file-system-name command to manually set this file-system name.
Samples	bstnA(gbl-ns-vol[medarcv~/usr])# no unicode-on-disk shuts off Unicode file names on disk for the /usr volume in the medarcv namespace.   bstnA(gbl-ns-vol[ns1~/])# unicode-on-disk reinstates Unicode file names on disk for the / volume in the ns1 namespace.
Related Commands	namespace -> volume enable (gbl-ns-vol-shr) show exports

Purpose	Use the volume command to create a new volume or edit an existing one. A volume appears to clients as a discrete file system in the namespace. If it is a managed volume, it contains imported shares from various back-end filers. A direct volume contains attach points to the filers behind it. Use the no form of the command to delete a volume.
Mode	gbl-ns
Security Role(s)	storage-engineer or crypto-officer
Syntax	volume path no volume path   path (1-256 characters) is a directory path you choose for the managed volume (for example, /multimedia). This is the root directory for the managed volume.
Default(s)	None
Guidelines	The CLI prompts for confirmation before creating a new volume; enter yes to continue. (You can use terminal expert to eliminate confirmation prompts for creating new objects.) This places you in gbl-ns-vol mode, from which you include one or more exports or shares from back-end filers. From gbl-ns-vol mode, you must use the share command to create at least one share in the current volume; each share connects to one export/share from a back-end filer. The remaining configuration options are dependant on the type of volume you are configuring. A managed volume imports the files and directories from its shares, manages metadata for all of them, and supports policies that migrate the files. A direct volume has virtual subpaths that attach to directories on the filer; this does not manage metadata or support any policy.
Guidelines: Managed Volumes	In a managed volume, the files are imported from each filer export/share to the root path of the managed volume. A file in the root of the imported export/share also appears in the root of the managed volume. This introduces the possibility of naming collisions. If your first filer share has a file named myFile.txt in its root, you cannot import another filer share to the same managed volume if it also has a myFile.txt file in its root. Optionally, you can allow the volume to rename the second file: use the modify command to do this. A managed volume offers the option to group the shares into share farms; you can then apply capacity-balancing policies to each share farm. Use the share (gbl-ns-vol-sfarm) command to create a share farm in the current managed volume.
Guidelines: Direct Volumes	In a direct volume, the path is a read-only directory that contains the volumes attach points. Each attach point is a directory that directly connects a client to a back-end share. Use the direct command to make a volume into a direct volume. After you create a share with the share command, use attach to attach a directory from the volume to a back-end filer.
Guidelines: no volume	To prepare for removing a volume, all of the volumes contents must be removed first. That is, it must be deactivated (nsck ... destage), it can contain no rules (various commands), share farms (no share-farm), filesets (various commands), or shares (use remove-share migrate or no share). Additionally, no front-end service can be exporting the volume (no cifs or no nfs), and no CIFS service for this namespace can have browsing enabled. (You can work around this problem by disabling the volume with no enable (gbl-ns, gbl-ns-vol)). The remove namespace ... volume command performs all of the above steps for you. Best practices dictate that you use that command instead.
Samples	bstnA(gbl-ns[archives])# volume /multimedia This will create a new volume.   Create volume '/multimedia'? [yes/no] yes bstnA(gbl-ns-vol[archives~/multimedia])# creates a managed volume at /multimedia.   bstnA(gbl-ns[archives])# no volume /radio deletes the /radio volume.
Related Commands	namespace share share (gbl-ns-vol-sfarm) modify direct attach remove namespace show global-config namespace show namespace show namespace mapping show namespace status

Purpose	A volume group shares a single memory pool along with CPU-processing time and other resources. If certain catastrophic failures cause a single volume to fail, they can stop processing for all other volumes in the same group. You should therefore group your volumes carefully, to insulate volumes from one another as needed. Use the volume-group command to explicitly choose the volumes group rather than allowing a default assignment. Use no volume-group to allow default-group assignment.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	volume-group id no volume-group   id is the group ID you assign to the current volume. All the volumes in a given group must belong to the same namespace. On an installation with many volumes in a small number of namespaces, you have the option to divide each namespaces volumes among multiple volume groups. On the ARX-500 you are limited to half of your potential volume groups. This ensures that the volume software has enough memory to function in most cases, but it reduces the potential number of failure domains that you can use. On those platforms, you can increase the maximum number of volume groups with max-volume-groups.
Default(s)	Internal software chooses a default volume-group assignment for each volume. We recommend choosing volume groups explicitly with this command or nsck ... migrate-volume instead of using the default.
Guidelines	On every platform except the ARX-2000 or ARX-4000, each volume group can hold up to 64 volumes. An ARX-2000 volume group can hold up to 48 volumes, and an ARX-4000 volume group can hold up to 32 volumes. The namespace software assigns a volume to its group when the volume is enabled (see enable (gbl-ns, gbl-ns-vol)). If necessary, you can use the nsck ... migrate-volume command to can change the volume-group assignment after the volume is enabled. Use the show volume-group command to view the current volume-group assignments on the current switch. It is possible for default volume-group assignments to artificially limit the maximum number of namespaces on your system. Use this command to make explicit volume-group assignments before the volumes are enabled.
Guidelines: Splitting a Namespace	If a volume has a catastrophic metadata failure (such as losing contact with the back-end filer), all other volumes in the same volume group become unusable. To mitigate this potential problem, you can divide a namespaces volumes into multiple independent groups. If one volume has a catastrophic failure in one group, volumes in the other group(s) are unaffected. On the ARX-500 you are limited to half of your potential volume groups. This ensures that the volume software has enough memory to function in most cases, but it reduces the potential number of failure domains that you can use. On those platforms, you can increase the maximum number of volume groups with max-volume-groups. The number of volume groups affects the memory usage for volume processing (see metadata cache-size), so you should only change this on the advice of F5 personnel.
Samples	bstnA(gbl-ns[archives])# volume /multimedia bstnA(gbl-ns-vol[archives~/multimedia])# volume-group 1 bstnA(gbl-ns-vol[archives~/multimedia])# exit bstnA(gbl-ns[archives])# volume /radio bstnA(gbl-ns-vol[archives~/radio])# volume-group 1 bstnA(gbl-ns-vol[archives~/radio])# ... assigns two volumes to volume group 1. That volume group is now dedicated to volumes from the archives namespace.   bstnA(gbl-ns[ns3])# volume /vol1 bstnA(gbl-ns-vol[ns3~/vol1])# volume-group 2 bstnA(gbl-ns-vol[ns3~/vol1])# exit bstnA(gbl-ns[ns3])# volume /vol2 bstnA(gbl-ns-vol[ns3~/vol1])# volume-group 3 bstnA(gbl-ns-vol[ns3~/vol1])# ... assigns two volumes to different volume groups. If /vol1 has a catastrophic metadata failure, /vol2 is unaffected. This also means that both volume groups are dedicated to the ns3 namespace.   bstnA(gbl-ns[archives])# volume /multimedia bstnA(gbl-ns-vol[archives~/multimedia])# no volume-group bstnA(gbl-ns-vol[archives~/multimedia])# ... commits the /multimedia volume to default-group assignment.
Related Commands	namespace -> volume show volume-group enable (gbl-ns, gbl-ns-vol) nsck ... migrate-volume share (gbl-ns-vol-sfarm) max-volume-groups

Purpose	Use the wait-for shares-online command to wait until all shares in a volume are enabled, and have started their imports.
Mode	(any)
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	wait-for shares-online namespace volume [timeout timeout]   namespace (1-30 characters) identifies the namespace. volume (1-1024 characters) is the name of the volume. timeout (optional, 1-2096) is the timeout value in seconds.
Default(s)	timeout - 0 (zero, meaning that the command should wait indefinitely)
Guidelines	This command is useful in CLI scripts. When enabling a volume (enable (gbl-ns, gbl-ns-vol)) or all of its shares, you can use the wait-for shares-online command to wait for the volumes shares to be enabled. This command waits for all shares in the given volume. Once this command returns, clients can access the shares and use them. The volume continues to import the shares as the clients access them. If you set a timeout and it expires before all of the shares are online, the command exits with a warning.
Sample	bstnA(gbl-ns-vol[ns77~/vol31])# wait-for shares-online ns77 /vol31 timeout 60 waits for all shares from the ns77~/vol31 volume to come online. If 60 seconds expire before this happens, the command exits with a warning.
Related Commands	enable (gbl-ns-vol-shr)

Purpose	After disabling a volume or namespace, you can use the wait-for volume disable command to wait for the volume(s) to go offline.
Mode	(any)
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	wait-for volume-disable namespace [volume] [timeout timeout]   namespace (1-30 characters) identifies the namespace. volume (optional, 1-1024 characters) is a particular volume. timeout (optional, 1-2096) is the timeout value in seconds.
Default(s)	timeout - 0 (zero, meaning that the command should wait indefinitely)
Guidelines	This command is useful in CLI scripts. When disabling a volume or a namespace (no enable (gbl-ns, gbl-ns-vol)), you can use the wait-for volume-disable command to wait for one or all volumes to go offline. If you set a timeout and it expires before all the chosen volumes are enabled, the command exits with a warning.
Sample	bstnA(gbl-ns[medarcv])# wait-for volume-disable medarcv waits for all volumes in the medarcv namespace to be disabled. There is no timeout specified, so the CLI blocks until all volumes are offline.
Related Commands	enable (gbl-ns, gbl-ns-vol) wait-for volume-enable

Purpose	Use the wait-for volume enable command to wait for one or more volumes to come online.
Mode	(any)
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	wait-for volume-enable namespace [volume] [timeout timeout]   namespace (1-30 characters) identifies the namespace. volume (optional, 1-1024 characters) is a particular volume. timeout (optional, 1-2096) is the timeout value in seconds.
Default(s)	timeout - 0 (zero, meaning that the command should wait indefinitely)
Guidelines	This command is useful in CLI scripts. When enabling a volume or a namespace (enable (gbl-ns, gbl-ns-vol)), you can use the wait-for volume-enable command to wait for one or all volumes to come online. To wait for all of the shares in a single volume, you can use wait-for shares-online instead. If you set a timeout and it expires before all the chosen volumes are enabled, the command exits with a warning.
Sample	bstnA> wait-for volume-enable wwmed timeout 120 waits for all volumes in the wwmed namespace to be enabled. If 120 seconds pass before the last volume comes online, the command exits with a warning.
Related Commands	enable (gbl-ns, gbl-ns-vol) wait-for shares-online wait-for volume-disable