Purpose	You can use the nsck ... migrate-metadata command to move a managed volumes metadata from one back-end share to another. Use this command to cancel a metadata migration that is currently in progress.
Modes	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, crypto-officer, or backup-operator
Syntax	cancel migrate-metadata namespace volume volume   namespace (1-30 characters) and volume (1-1024 characters) specify the volume whose metadata is migrating between back-end shares. The nsck utility performs metadata migrations; use the show nsck command for a list of volumes where the nsck utility is running.
Default(s)	None
Guidelines	The CLI prompts for confirmation before canceling the metadata migration; enter yes to continue. This stops the volumes metadata from migrating and returns the volume to service. The managed volume uses its original metadata share after the cancellation. If the migration is complete and the volume is in the process of restarting with the new metadata share, this command fails. Use the nsck ... migrate-metadata command to start a metadata migration.
Sample	bstnA# cancel migrate-metadata insur volume /claims Are you sure you want to cancel this migration? [yes/no] yes Metadata migration cancelled successfully. bstnA# cancels the migration in progress for the insur~/claims volume.
Related Commands	nsck ... migrate-metadata show nsck

Purpose	You can use the nsck ... migrate-volume command to move an ARX volume from one volume-group to another. Use this command to cancel a volume migration that is currently in progress.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	cancel migrate-volume namespace volume volume   namespace (1-30 characters) and volume (1-1024 characters) specify the volume that is migrating between volume groups.
Default(s)	None
Guidelines	The CLI prompts for confirmation before canceling the volume migration; enter yes to continue. This stops the volume from migrating and returns the volume to service in its original volume group. The cancellation may take a long time in a large volume. If the migration has already progressed to the point where the volume is restarting in its new volume group, this command fails. If necessary, you can re-run the nsck ... migrate-volume command to send the volume back to the original group. You can use show volume-group to show the current volume group for every volume. Use the show nsck command to monitor the progress of a volume migration.
Sample	bstnA# cancel migrate-volume medarcv volume /rcrds Are you sure you want to cancel this migration? [yes/no] yes ... bstnA# cancels the migration in progress for the medarcv~/rcrds volume.
Related Commands	nsck ... migrate-volume show volume-group show nsck

Purpose	To stop an nsck-report job (nsck ... report metadata-only or nsck ... report inconsistencies), use the cancel nsck report command.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	cancel nsck report nsck-id   nsck-id (1-2,147,483,647) identifies one nsck-report job that is currently running. The job ID appears if you run show nsck without any options.
Guidelines	This command prompts for confirmation before stopping the report; enter yes to continue. This command has no effect on nsck jobs that do more than produce a report, such as those invoked by nsck ... destage or nsck ... rebuild.
Samples	bstnA# cancel nsck report 22 Cancel the nsck metadata-only report operation 'metadata_only.21.rpt'? [yes/no] yes bstnA# cancels a metadata-only report.
Related Commands	show nsck nsck ... report inconsistencies nsck ... report metadata-only

Purpose	If a file or directory changes on a back-end filer without the managed volumes awareness, the volume metadata is inconsistent for that file. A sync operation discovers which files or directories are inconsistent and re-synchronizes them with the metadata; the cancel sync command stops a sync operation.
Modes	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	cancel sync {files | directories} namespace volume volume path dir-path   files | directories chooses the type of sync operation to cancel. namespace (1-30 characters) is the namespace where the sync is occurring. Use the show sync command for a list of namespaces that are being synchronized. volume (1-1024 characters) specifies the managed volume where the sync is occurring. dir-path (1-1024 characters) specifies the directory that is being synchronized within the volume, if any. This path is relative to the volume root, above. Use forward slashes (/) for NFS or CIFS paths.
Default(s)	None
Guidelines	The CLI prompts for confirmation before canceling the sync operation; enter yes to continue. Use the sync files command to find files with metadata inconsistencies and repair them, or the sync directories command to find new directories on the filer that are not recorded in the metadata. Sync operations happen in the background while you continue to use the CLI; you can use the wait-for sync command to block the CLI until the sync is complete. To show all sync operations, use show sync.
Sample	bstnA# cancel sync files wwmed volume /acct path /jsmith Cancel specified sync operations? [yes/no] yes bstnA# cancels the sync-files operation in progress for the /jsmith directory in the wwmed~/acct volume.
Related Commands	sync files sync directories wait-for sync show sync

Purpose	Use this command to clear a pending or complete nsck job, or to clear all such nsck jobs.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	clear nsck [nsck-id]   nsck-id (optional, 1-2,147,483,647) identifies the nsck job to clear. The job ID appears in the report name for the nsck job. If you do not include an ID, the command clears all nsck jobs.
Default(s)	None
Guidelines	The CLI prompts for confirmation before executing the command. Use the show nsck command to view all nsck jobs that have run on this switch. After you issue this command, show nsck does not show any pending or complete nsck jobs. This command does not delete any nsck report files, which you can view with the show reports command.
Sample(s)	bstnA# clear nsck 4 Clear NSCK ID 4? [yes/no] yes clears the nsck job for nsck ID #4.
Related Commands	show nsck show reports

Purpose	The ARX holds its sync-operation records indefinitely, so that you can see the results of every sync operation through show sync. Use the clear sync command to remove sync operations from this running history.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	clear sync {files | directories} clear sync {files | directories} namespace clear sync {files | directories} namespace volume vol-path clear sync {files | directories} namespace volume vol-path path path   files | directories is a required choice. This selects the type of sync-operation records to clear. The namespace, vol-path, and path arguments mimic the ones used in the sync files and sync directories commands. These identify one or more sync operations; if you omit all of them, the command clears all sync-files or sync-directories operations from the switch. namespace (1-30 characters) specifies a namespace where one or more sync operations have occurred. vol-path (optional, 1-1024 characters) specifies a volume. Use forward slashes (/) for all volumes, including CIFS. path (optional, 1-1024 characters) identifies a particular path that has been synchronized. As with volumes, use forward slashes in all paths.
Default(s)	None
Guidelines	The CLI prompts for confirmation before deleting any sync records. Enter yes to continue. Use show sync to show all recorded sync operations. This command clears them; after you run it, the show sync command no longer displays the cleared operation(s). The sync files and sync directories commands each start a sync operation (which runs in the background while you continue to use the CLI), cancel sync cancels a running sync, and wait-for sync blocks the CLI until a running sync completes.
Samples	bstnA# clear sync files wwmed Clear sync records? [yes/no] yes bstnA# clears all sync-files operations from the wwmed namespace.   bstnA# clear sync directories Clear sync records? [yes/no] yes bstnA# clears all sync-directories operations on the switch. The show sync directories command displays nothing after you do this.
Related Commands	sync files sync directories show sync cancel sync wait-for sync

Purpose	Use the nsck destage command to release all back-end shares from a managed volume. Once destaged, you can access the volumes filer(s) directly without risking any metadata inconsistencies.
Mode	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	nsck name destage [force] nsck name destage volume-group id [force] nsck name destage volume volname[force]   name (1-30 characters) is the name of the namespace where the destage occurs. Use the show namespace command to see a list of configured namespaces. destage directs the nsck utility to destage the namespace metadata and prepare it for re-import. volume-group id (optional) chooses all of the volumes in the given volume group. A volume group shares CPU and memory resources, and 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. 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. This command destages all of the volumes assigned to the group that you choose. volume volname (optional, 1-256 characters) is the volume to destage (for example, /var). force (optional) indicates that you want to force the destage even if another nsck job is currently under way. You can force any nsck job with this option except nsck ... migrate-metadata or nsck ... migrate-volume; you must cancel those jobs explicitly (with cancel migrate-metadata or cancel migrate-volume) before you can destage the volume.
Default(s)	None.
Guidelines	This applies to a managed volume only, not to a direct volume.
	The CLI asks for confirmation before releasing any volumes shares; enter yes to continue. This stops all client access to any of the destaged volumes. Once the filer or share(s) have been removed and/or restored to health, you can use the enable shares command to re-import all shares into a managed volume (see enable (gbl-ns, gbl-ns-vol)). After the re-import, all NFS clients must unmount and remount any of the volumes front-end NFS exports (export (gbl-nfs)).
Note: Nsck turns off a volumes modify flag before it destages the volume, making the volume read-only (see modify). Before you run the nsck ... destage command, you can avoid this by running the gbl-ns-vol reimport-modify command.
Guidelines: Correcting a Problem at an NFS-Metadata Share	If a volumes metadata share supports NFS and that NFS mount is hung, all of the volumes in the same volume group will eventually become unusable. The show volume-group command shows the volume-group assignments for your volumes. You can use the volume-group clause in this command to destage those specific volume groups, then reload the ARX to initiate a failover. The destaged volumes must re-import after this failover, but no other volumes are affected. NFS clients must un-mount and re-mount the NFS front-end exports for these volumes; CIFS clients are unaffected by the re-import. This re-establishes storage service on the peer ARX with minimal disruption to clients.
Sample	bstnA# nsck archives destage volume /mktg   Volume /mktg is in use by CIFS global service 'fs10.medarch.org'.   This operation will remove entries for all shares in the volume from the namespace metadata. To reimport a destaged share, enable the share.   % WARNING: Volume /mktg in namespace wwmed is in use by global services.   Destaging the volume will disrupt all clients using this volume.   Destage the volume anyway? [yes/no] yes bstnA# ... destages the /mktg volume in the archives namespace.
Related Commands	show namespace show reports show external-filer enable (gbl-ns-vol-shr)

Purpose	Use the nsck migrate-metadata command to move a managed-volumes metadata from one share to another.
Mode	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	nsck name migrate-metadata volume volname target filer-name {nfs3 | nfs3tcp | cifs} path   name (1-30 characters) is the name of the namespace. migrate-metadata is required. volume volname (1-256 characters) is the chosen managed volume. target filer-name (1-64 characters) is the new filer or file server for the volumes metadata. Use the show external-filer command for a list of configured filers. nfs3 | nfs3tcp | cifs is the protocol for accessing the above filer (NFSv3 over UDP, NFSv3 over TCP, or CIFS). This can be different from the protocol(s) for the managed volume, though you cannot choose a CIFS share for a managed volume in an NFS-only namespace. path (1-1024 characters) is the path to the back-end filer share, or a CIFS-share name (possibly with a sub-path). Use forward slashes (/) for Unix exports or CIFS shares.
Default(s)	None.
Guidelines	This applies to a managed volume only, not to a direct volume. This stops client access to the managed volume while the metadata migration proceeds. The CLI asks for confirmation before moving the volumes metadata; enter yes to continue. The migration occurs in stages for maximum protection of the volumes metadata. It copies all metadata to the new share, verifies its integrity, and brings the volume back online before it deletes the metadata from the old share. If the job is canceled or if it fails before the final transition, the managed volume comes back online with its original metadata share. Very large volumes may take a long time for their metadata to migrate. The command returns immediately, providing you with the name of a detailed report. You can continue using the CLI while the migration occurs in the background. The show nsck command shows the current status of one or more nsck operations.
	The migration report is named migrate_metadata.nsck-job-id.rpt. Use show reports to list all reports, including this one. To follow the progress of the migration, you can use tail reports report-name follow. For a sample report, see Figure 37.1 on page 37-13. To cancel the metadata migration (and return the volume to service with its original metadata share), use cancel migrate-metadata. The metadata share command establishes a metadata share for a managed volume. If you decide later to move the metadata to a new share, you can use this command (nsck ... migrate-metadata) to perform the metadata migration.
Sample	bstnA# nsck wwmed migrate-metadata volume /acct target nas3 nfs3 /exports/meta7   Volume /acct is in use by NFS global service 'ac1.engsmoke.acopianet.com'. Volume /acct in namespace wwmed is in use or being browsed by global services.   Migrating metadata for this volume will disrupt all clients accessing this volume through these services. No other volume will be affected by this procedure.   Proceed with metadata migration? [yes/no] yes Starting metadata migration for wwmed:/acct. 2162688 bytes to be transferred. Detailed status contained in report: migrate_metadata.39.rpt on switch bstnA   migrates metadata for the wwmed~/acct volume to a share on the nas3 filer. See Figure 37.1 for a sample report.
Related Commands	metadata share cancel migrate-metadata show external-filer show reports

Purpose	Every ARX volume resides in a volume group, where it shares CPU and memory resources with the other volumes in the same group. Each volume group is a single failure domain, where certain catastrophic failures affect the other volumes in the same group but do not affect any volumes outside the group. As your deployment grows, you may want to redistribute your volumes to mitigate possible down time. Use the nsck migrate-volume command to move a volume from one volume-group to another.
Mode	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	nsck name migrate-volume volname volume-group id [check-limits]   name (1-30 characters) is the name of the namespace. migrate-volume volname (1-256 characters) is the volume to migrate. volume-group id chooses the destination volume group. Use the show volume-group command to show all currently-existing volume groups and their volumes. Choose a volume group from the same namespace as the source volume, or choose a new one. This volume group must be able to support the new volume without exceeding any of its licensed limits. To confirm that the migration meets all these criteria, you can use the check-limits option (below). check-limits verifies that the volume migration is possible without actually migrating the volume. You can use this option to run a test before you perform the migration. This checks the licensed limits at the destination volume group and any other possible obstacles for a successful migration.
Default(s)	None.
Guidelines	This command stops client access to the volume until the migration is complete. The CLI lists all affected front-end services and asks for confirmation; enter yes to continue. A volume cannot migrate while it is importing files from its back-end shares. (You invoke volume import with the enable (gbl-ns, gbl-ns-vol) command.) The import must be complete before you move the volume to another volume group. If you run multiple volume migrations at the same time, they must all be to different volume groups. A volume group can only accept one migrating volume at a time. Very large volumes may take a long time to migrate. The command returns immediately, providing you with the name of a detailed report. You can continue using the CLI while the migration occurs in the background. The show nsck command shows the current status of the migration, along with the status of all other nsck operations. After the nsck job is complete, the front-end service(s) require a few additional seconds before they allow client access to the volume. The migration report is named migrate_volume_group.nsck-job-id.rpt. Use show reports to list all reports, including this one. To follow the progress of the migration, you can use tail reports report-name follow. For a sample report, see Figure 37.2 on page 37-15. To cancel the volume migration (and return the volume to service in its original volume group), use cancel migrate-volume.
Samples	bstnA# nsck medarcv migrate-volume /test_results volume-group 3 check-limits % INFO: Volume-group migration limit checking passed.   confirms that it is possible to migrate the medarcv~/test_results volume to volume group 3.   bstnA# nsck medarcv migrate-volume /test_results volume-group 3   Volume /test_results is in use by CIFS global service 'ac1.medarch.org'. Volume /test_results in namespace medarcv is in use or being browsed by global services.   Migrating the volume to a different Volume-Group will disrupt all clients accessing this volume through these services. No other volume will be affected by this procedure.   Proceed with volume migration? [yes/no] yes Scheduling report: migrate_volume_group.40.rpt on switch bstnA   migrates medarcv~/test_results to volume group 3. See Figure 37.2 for a sample report. This is a direct volume, so the report does not include any information about metadata.
Related Commands	volume-group cancel migrate-volume show volume-group show reports

Purpose	The namespace-check (nsck) utility finds and repairs inconsistencies between a managed volumes metadata and actual files on back-end storage. An nsck rebuild operation deletes all metadata and re-imports all shares. Use the nsck rebuild command to re-initialize all managed volumes in a namespace, or a particular volume.
Mode	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	nsck name rebuild [volume volname] [force]   name (1-30 characters) is the name of the namespace to rebuild. Use the show namespace command to see a list of configured namespaces. volume volname (optional, 1-256 characters) limits the rebuild to the chosen volume (for example, /home). force (optional) indicates that you want to force the destage even if another nsck job is currently under way. You can force any nsck job with this option except nsck ... migrate-metadata or nsck ... migrate-volume; you must cancel those jobs explicitly (with cancel migrate-metadata or cancel migrate-volume) before you can rebuild the volume.
Default(s)	None.
Guidelines: Determining if a Rebuild is Necessary	If clients get front-end-service (NFS or CIFS) failures for a particular managed volume, the volumes metadata might be inconsistent the files on the back end. As further indication of inconsistency, search through the syslog file for DB_RUNRECOVERY messages. Use show logs to view the current syslog, or use grep syslog to search the syslog for certain patterns. Use show logs to view all log files, including backups, in the logs directory. You can use the nsck ... report inconsistencies command to check the namespace, volume, or share for inconsistencies without changing any metadata. To attempt to repair inconsistencies, you can use the sync files command to synchronize the metadata with actual files, or the sync directories command to find any new directories and add them to the metadata. If a sync fails, nsck ... rebuild is a last resort. This operation stops all volume processing, rebuilds all metadata, and re-syncs all filer subshares; this causes a complete service interruption.
Guidelines: Modify Flag	Each managed volume has a modify flag that you can set with the gbl-ns-vol modify command. This flag, if raised, allows the volume to rename any imported files or directories with the same pathname as previously-imported files. If lowered, such files and directories are not imported and clients cannot write to the volume. The nsck ... rebuild command lowers this flag for each managed volume that it rebuilds. By default, it keeps the flag lowered after the rebuild is over. This is a safety feature to avoid renamed files when they might not be expected. To allow modifications, you can run the gbl-ns-vol reimport-modify command for each desired volume. This command tells nsck to re-instate the modify flag after the rebuild.
Guidelines: Directory Mastership After the Rebuild	If your volume has tiered shares, where some shares reside on faster and/or more reliable filers than others, we recommend placing all of your master directories onto your Tier 1 shares. Whenever two or more directories have the same name and path, one is considered master and the others are called stripes. The volumes clients cannot access a directory if its master instance is unavailable from the back end, so it is important to keep the masters on reliable filers. Use a place-rule to select all directories in the volume, place them onto one or more Tier 1 shares, and promote them to master. The rebuild process follows all directory-place rules during the re-import. Additionally, set all of your Tier 1 shares to import priority 1, to force the volume to scan those shares before the lower-priority shares. This ensures that all master directories for the volume are on Tier 1 shares.
Guidelines: Running the Command	The CLI prompts for confirmation before disabling the namespace or volume: you must answer yes to proceed with the rebuild operation. The optional force flag is useful for working through a hung nsck job. An nsck job may hang if one of the back-end shares or filers goes offline at the wrong time. All NFS clients that use the volume(s) must unmount and remount after the rebuild is finished.
Samples	bstnA# nsck ns rebuild Reimport all shares in the namespace ns? [yes/no] yes bstnA# rebuilds the ns namespace.   bstnA# nsck archives rebuild force forces a rebuild in the archives namespace.   bstnA# nsck archives rebuild volume /etc rebuilds the /etc volume in the archives namespace.
Related Commands	grep nsck ... report inconsistencies sync files show namespace show logs place-rule

Purpose	A managed volumes metadata is its background information about its files and directories, such as their physical locations on back-end filers. You can use the nsck report dir-structure command to get a report of a volumes directory structure from its metadata. This is faster than the full nsck ... report metadata-only command, and the report provides a quick overview of the volumes directory layout.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	nsck name report dir-structure [path] [norecurse] [summary] [outputfile outputfile]   name (1-30 characters) is the namespace on which to report. Use the show namespace command for a list of configured namespaces. path (optional, 1-256 characters) narrows the scope of the report to a specific virtual path in the namespace (for example, /home/jrandom). If you omit this, the command generates one report per volume. norecurse (optional) specifies to not recurse into subdirectories during the report. The directory listing therefore only includes the root of the volume, or the path if you chose that option. summary (optional) removes the table of directories from the report. outputfile outputfile (optional; 1-255 characters) specifies a prefix for a customized file name (for example, jrandom_dir.rpt), as opposed to the default. Use the show reports command to display the file in the maintenance directory.
Default(s)	path - the root of the namespace (all volumes). outputfile outputfile - dir_structure.nsck-id.rpt. The nsck-id is a unique number assigned to each nsck job.
Guidelines	The name of the nsck report appears after you issue the command. Use tail to follow the report as it is written. Use show reports file-name to read the report. You can search through the report with grep. To copy or delete it, use the copy or delete commands. The non-summary report shows the configuration options chosen by this command, the back-end shares that hold the directories, a table of directories, where each directory appears in one row, a summary of the directory structure (maximum and average entries, files, links, and so forth amongst these directories), and a listing of total files, directories, and other high-level information. The summary report omits the table of directories. If you want to cancel the report before it finishes, use the cancel nsck report command. For a full report of all files and directories in a managed volume, use the nsck ... report metadata-only command.
Samples	bstnA# nsck medarv report dir-structure /rcrds Scheduling report: dir_structure.34.rpt on switch bstnA bstnA# ... shows the directory structure for the medarcv~/rcrds volume. The report appears in dir_structure.34.rpt. A sample appears below in Figure 37.3 on page 37-19.   bstnA# nsck insur report dir-structure Scheduling report: dir_structure.43.rpt on switch bstnA bstnA# ... shows the directory structure for all volumes in the insur namespace. This produces a single report, , for the namespaces single volume. A sample appears in Figure 37.4 on page 37-20.
Related Commands	show namespace show reports cancel nsck report tail grep copy ftp copy scp copy {nfs|cifs} copy tftp delete

Purpose	A managed volumes metadata is its background information about its files and directories, such as their physical locations on back-end filers. If a client has direct access to one of the volumes back-end shares (that is, access that does not go through the volume), the volumes metadata is likely to be inconsistent. Metadata inconsistencies can also occur in a multi-protocol (NFS and CIFS) volume without any client intervention: on a multi-protocol filer, a file or directory name may differ between NFS and CIFS. Use the nsck report inconsistencies command to find (but not repair) any inconsistencies in a namespaces metadata, or to prove that there are none.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	nsck name report inconsistencies [path] [share share-name] [norecurse] [nofilehandles] [multi-protocol] [outputfile outputfile]   name (1-30 characters) is the namespace on which to report. Use the show namespace command for a list of configured namespaces. path (optional, 1-256 characters) narrows the scope of the report to a specific virtual path in the namespace (for example, /home/jrandom). share share-name (optional, 1-64 characters) limits the report to a single share in the volume. norecurse (optional) specifies to not recurse into subdirectories during the report. nofilehandles (optional) specifies to not validate file handles during the report. multi-protocol (optional) focuses the report on inconsistencies between NFS names and CIFS names. This only applies to a volume in a multi-protocol (NFS and CIFS) namespace.
	outputfile outputfile (optional; 1-255 characters) specifies a prefix for a customized file name (for example, jrandom_inconsistencies.rpt), as opposed to the default. Use the show reports command to display the file in the maintenance directory.
Default(s)	path - the root of the namespace (all volumes). outputfile outputfile - inconsistencies.nsck-id.rpt. The nsck-id is a unique number assigned to each nsck job. share-name - all shares in the volume.
Guidelines	The name of the nsck report appears after you issue the command. Use tail to follow the report as it is written. Use show reports file-name to read the report. You can search through the report with grep. To copy or delete it, use the copy or delete commands. The report shows various types of inconsistency: Metadata disagrees with actual files or directories on the back-end filers, A file or directory name matches an alternate 8.3 name on a back-end-CIFS share, or A file or directory name matches a filer-generated name (FGN) on a back-end share that supports both CIFS and NFS. The ARX CLI Maintenance Guide discusses all of these inconsistency types in detail, and describes methods for addressing each inconsistency type. If this operation finds any metadata inconsistencies, you can use sync files to synchronize the metadata with the filer. If you want to cancel the report before it finishes, use the cancel nsck report command.
Guidelines: Transitional States	This report also describes any network issues, filer issues, or other unusual problems that temporarily prevent a full listing. These are denoted by the following codes: MF - The file is being migrated from one share to another, so it is in a transitional state. If there is an additional FF (Found-File) entry for the same file, the FF indicates that it found an extra copy of the file while it existed (for an instant) on both the source share and the destination share. You can probably disregard the FF state for that file. Run the report later for an accurate assessment of its metadata consistency. NL - The nsck software could not lock the parent directory, typically due to heavy client activity. Without this lock, numerous changes (such as file additions, edits, and deletions) can be underway, making it possible to mistakenly assume an inconsistency. Run the report later on this directory to get an accurate measure of its inconsistencies. You can use the optional path in this command to focus on a particular path in the volume. FE - The nsck software lost contact with the filer during the report. Check for connectivity issues with this filer. Once the problem is corrected, run the report again. FO -The filer is offline. Address the problem at the filer and rerun this report. DC - A client issued a delete-on-last-close command for this file, but the filer deleted it early. EMC Celerra servers have shown this behavior in lab testing. The client application has already announced its intention to delete the file, so this condition is cleared when the client application closes the file.
Samples	bstnA# nsck wwmed report inconsistencies Scheduling report: inconsistencies.2.rpt on switch bstnA bstnA# ... shows the metadata for all managed volumes in the wwmed namespace. The report appears in inconsistencies.2.rpt. A successful sample appears below in Figure 37.5 on page 37-24.   bstnA# nsck medarcv report inconsistencies outputfile medarcv5-6 Scheduling report: medarcv5-6.3.rpt on switch bstnA bstnA# ... checks the medarcv namespace and puts the report in a file, medarcv5-6.3.rpt.   bstnA# nsck insur report inconsistencies /claims Scheduling report: inconsistencies.25.rpt on switch bstnA bstnA# ... shows the metadata for /claims in the insur namespace. The report appears in inconsistencies.25.rpt. An unsuccessful sample appears in Figure 37.6 on page 37-25.
Related Commands	show namespace sync files show reports cancel nsck report tail grep copy ftp copy scp copy {nfs|cifs} copy tftp delete

Purpose	A managed volumes metadata is its background information about its files and directories, such as their physical locations on back-end filers. Use the nsck report metadata-only command to show a namespaces or volumes metadata.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	nsck name report metadata-only [path] [share share-name] [norecurse] [outputfile outputfile]   name (1-30 characters) specifies a namespace on which to report. Use the show namespace command for a list of configured namespaces. path (optional, 1-256 characters) narrows the scope of the report to a specific managed volume or path in the namespace (for example, /eng/share). share share-name (optional, 1-64 characters) limits the report to a single share in the volume. norecurse (optional) specifies to not recurse into subdirectories during the report. outputfile outputfile (optional, 1-255 characters) specifies a prefix for a customized file name (for example, jrandom_inconsistencies.rpt), as opposed to the default. Use the show reports command to display the file in the maintenance directory.
Default(s)	path - the root of the namespace (all managed volumes). share-name - all shares in the volume. outputfile outputfile - metadata_only
Guidelines	When a share is first imported into a managed volume, a report similar to this one is generated. You can compare that report to this one to see the effects of policy on your file locations. The import reports are accessible through show reports. Their names have the following formats: import.share-id.share-name.job-id.rpt Use the find command to show the physical location of a single file. The name of the nsck report appears after you issue the command. Use tail to follow the report as it is written. Use show reports file-name to read the report. You can search through the report with grep. To copy or delete it, use the copy or delete commands. If you want to cancel the report before it finishes, use the cancel nsck report command. You can use the nsck ... report dir-structure command for a faster report that focuses on the volumes directory structure.
Guidelines: Report Content	The report lists all files (labeled FL) and directories (labeled DR) recorded in the volumes metadata. An SL indicates that the file or directory is actually a symbolic link, or symlink. Most of the other labels indicate a naming issue; you can examine these thoroughly with the nsck ... report inconsistencies command. The NL condition is typically transitory: it indicates that the nsck software is currently unable to get a lock on the parent directory for the given file or directory. This typically indicates high client activity (such as file creates and deletes) in the parent directory, which may lead to temporarily-inaccurate metadata readings in the report. The volume updates its metadata as soon as it is able to get the lock.
Guidelines: File Tracking	This identifies the back-end locations of all the volumes files as of now; for file locations in the past, you can use file tracking. This can be useful for finding the correct filer-backup tape for a lost or compromised file. The file-tracking feature requires some configuration before you can make any file queries. Specifically, a managed volume requires a snapshot rule to regularly copy its configuration and metadata to a file-history archive. After some copies of metadata have been archived, you can use the show file-history virtual-service command to query file locations at different dates.
Samples	bstnA# nsck wwmed report metadata-only Scheduling report: metadata_only.5.rpt on switch bstnA bstnA# ... shows the metadata for the wwmed namespace. The report appears in metadata_only.5.rpt. A sample report appears in Figure 37.7 on page 37-29.   bstnA# nsck archives report metadata-only /arch checks the virtual path, /arch, in the archives namespace. Note that this path could span multiple volumes.   bstnA# nsck archives report metadata-only /arch share fs6 checks only the files from /arch that are stored on the fs6 share.   bstnA# nsck acopia3 report metadata-only outputfile 6-5mdata Scheduling report: 6-5mdata.15.rpt on switch bstnA bstnA# ... checks the acopia3 namespace and puts the report in a file, 6-5mdata.15.rpt.
Related Commands	show namespace show reports nsck ... report dir-structure cancel nsck report find tail grep copy ftp copy scp copy {nfs|cifs} copy tftp delete

Purpose	A managed volumes metadata is its background information about its files and directories, such as their physical locations on back-end filers. The metadata also contains a flag for all NFS symbolic link (symlink) files. A multi-protocol (CIFS and NFS) volume uses this flag to support symlink de referencing for its CIFS clients. Use the nsck report symlinks command to show all of the NFS symlinks that are identified in the current volumes metadata.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	nsck name report symlinks [path] [share share-name] [norecurse] [outputfile outputfile]   name (1-30 characters) specifies a namespace on which to report. Use the show namespace command for a list of configured namespaces. path (optional, 1-256 characters) narrows the scope of the report to a specific managed volume or path in the namespace (for example, /claims/common for the /common directory in the /claims volume). share share-name (optional, 1-64 characters) limits the report to a single share in the volume. norecurse (optional) specifies to not recurse into subdirectories during the report. outputfile outputfile (optional, 1-255 characters) specifies a prefix for a customized file name (for example, jrandom_symlinks.rpt), as opposed to the default. Use the show reports command to display the file in the maintenance directory.
Default(s)	path - the root of the namespace (all managed volumes). share-name - all shares in the volume. outputfile outputfile - symlinks
Guidelines	The name of the nsck report appears after you issue the command. Use tail to follow the report as it is written. Use show reports file-name to read the report. You can search through the report with grep. To copy or delete it, use the copy or delete commands. If you want to cancel the report before it finishes, use the cancel nsck report command.
Guidelines: Report Content	The report lists all symlinks (labeled SL) recorded in the volumes metadata. For each symlink, one of the following codes provides some more information: RF indicates that the symlink resolves to (or points to) a file. RD shows that the symlink resolves to a directory. RS means that the symlink resolves to another symlink. RX indicates a symlink error: the symlink points to a non-existent file or directory. ER indicates an error in querying the filer for symlink information. The report includes specific error information in parentheses. The NL condition is typically transitory: it indicates that the nsck software is currently unable to get a lock on the parent directory for the given file or directory. This typically indicates high client activity (such as file creates and deletes) in the parent directory, which may lead to temporarily-inaccurate metadata readings in the report. The volume updates its metadata as soon as it is able to get the lock.
Sample	bstnA# nsck insur report symlinks outputfile insur_symlinks Scheduling report: insur_symlinks._claims.rpt on switch bstnA bstnA# ... shows all symlinks in the insur namespace. The report appears in insur_symlinks._claims.rpt. A sample report appears in Figure 37.8.
Related Commands	cifs deny-symlinks show namespace show reports cancel nsck report find tail grep copy ftp copy scp copy {nfs|cifs} copy tftp delete

Purpose	If someone goes around a managed volume to directly create a directory on a back-end filer, the volume metadata does not include the new directory. The volumes clients therefore cannot see or use the new directory. (This may be necessary for directories with special features that can only be provisioned at the filer itself, such as disk quotas.) Use the nsck ... sync directories command to find any new subdirectories under a known directory. This is equivalent to the sync directories command.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	nsck namespace sync directories dir-path [share share-name]   namespace (1-30 characters) specifies the namespace to sync. Use the show namespace command for a list of configured namespaces. dir-path (1-256 characters) narrows the scope of the sync operation to a specific managed volume and path (for example, /vol/var/log). The path must describe a valid volume in the namespace, or one of its subdirectories. Use forward slashes (/) for NFS or CIFS paths. share share-name (optional, 1-64 characters) limits the sync and repair to a single share in the volume.
Default(s)	share share-name is unspecified, so all shares in the volume are synchronized and repaired.
Guidelines	This invokes the same software used by the sync directories command. Follow the Guidelines for that command.
Sample	bstnA# nsck medarcv sync directories /lab_equipment path / Scheduling sync directories operation on switch bstnA, report name: sync.9._lab_equipment.rpt bstnA# checks for unrecorded directories in the root of the medarcv~/lab_equipment volume.
Related Commands	sync directories show sync wait-for sync cancel sync clear sync nsck ... report inconsistencies show namespace show reports nsck ... rebuild

Purpose	If a file changes on a back-end filer without the managed volumes awareness, the volume metadata is inconsistent for that file. Use the nsck ... sync files command to report on metadata inconsistencies and repair them. This is equivalent to the sync files command.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	nsck namespace sync files dir-path [share share-name] [recurse] [rename-files]   namespace (1-30 characters) specifies the namespace to sync. Use the show namespace command for a list of configured namespaces. dir-path (1-256 characters) narrows the scope of the sync operation to a specific managed volume and path (for example, /vol/var/log). The path must describe a valid volume in the namespace, or one of its subdirectories. Use forward slashes (/) for NFS or CIFS paths. share share-name (optional, 1-64 characters) limits the sync and repair to a single share in the volume. recurse (optional) causes the sync operation to descend into subdirectories. rename-files (optional) determines that, if a file-collision is discovered, the sync operation can rename the newly-discovered file. All collisions and renames are included in the sync report.
Default(s)	recurse is off; the sync only examines the dir-path without descending into any child directories. rename-files is off; collisions are noted in the sync report, and the metadata is not repaired. share share-name is unspecified, so all shares in the volume are synchronized and repaired.
Guidelines	This invokes the same software used by the sync files command. Follow the Guidelines for that command.
Sample	bstnA# nsck wwmed sync files /acct recurse Scheduling sync files operation on switch bstnA, report name: sync.1._acct.rpt bstnA# repairs the top-level directory in the wwmed~/acct volume. This descends into child directories but does not repair any renamed files that have collided with known files.
Related Commands	sync files show sync wait-for sync cancel sync nsck ... report inconsistencies show namespace show reports nsck ... rebuild

Purpose	Use the show nsck command to show the current state of all nsck report, nsck rebuild, and sync operations.
Modes	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show nsck [nsck-id | namespace name | all]   nsck-id (optional) identifies one nsck or sync job to show. The job ID appears if you run show nsck without any options. name (optional, 1-30 characters) shows the nsck and/or sync job(s) in one namespace. all (optional) shows a detailed view of all nsck and sync jobs.
Default(s)	None.
Guidelines	If you do not include any of the options, the command displays the nsck and sync records for all namespaces. The show nsck command shows the operation ID (Op ID), the type of operation (Op Type), the namespace and path where the operation is running, and the current Status of the operation. Possible status lines appear below. The show nsck all and show nsck nsck-id commands add detail to the output, including the name of the job report and the switch where the report resides. The latter is useful in redundant pairs, where a report could be generated on either peer. The report data from the nsck commands is stored in a .rpt file in the reports directory. Use show reports to view files from this directory. Use the clear nsck command to clear one nsck job (or all nsck jobs). The clear sync command clears sync jobs.
Guidelines: Possible Status Conditions	Complete indicates a successful nsck operation. Pending shows that the nsck operation is starting. Rebuild in progress shows that the nsck operation is rebuilding a namespace or managed volume (nsck ... rebuild). Destage in progress appears for the nsck ... destage command. Report in progress indicates that the nsck job is writing a report, such as an inconsistencies report (nsck ... report inconsistencies) or metadata report (nsck ... report metadata-only). Cancelled means that someone stopped the nsck operation. Migrate in progress (x%) indicates that someone is migrating a managed-volumes metadata from one metadata share to another. The percentage shows the progress of the migration. Cancel in progress appears if someone stopped the metadata migration. Synchronizing appears for the sync files command. Pending Cancel and then Canceling appears if someone stopped the synchronization job with the cancel sync command.
Guidelines: Possible Errors	Any of these Status comments indicate that the nsck job failed. Error: Path not found - A virtual tree has a file or directory that is missing from its physical counterpart. Error: Out of memory - The namespace software ran out of memory during the nsck operation. Error: Temporary database - The namespace software encountered an error creating, opening, or deleting a temporary database. Error: Resolving database entry - An error occurred while resolving an entry in the operations temporary database. Error: Bad storage type - The namespace software could not determine whether a file-system entry was a file or a directory. Error: Attributes not found - The namespace software failed to access file attributes from one of the back-end-directory trees. Error: Incomplete - The switch rebooted before the nsck job was finished.
	Error: Incomplete at force time - An nsck ... rebuild force interrupted the nsck job. Error: Bad report type specified - The user specified an invalid report name in the nsck command. Error: Migration failed - The metadata migration failed. All metadata still resides on its original share. You can use the nsck ... migrate-metadata command to invoke a metadata migration. Error: Unable to open report - This is an internal error. Contact customer support.
Samples	bstnA# show nsck displays the state of the latest nsck and sync operations for all namespaces. Figure 37.9 on page 37-38 shows sample output.   bstnA# show nsck namespace medarcv displays the state of the latest nsck/sync operations for the medarcv namespace. Figure 37.10 on page 37-39 shows sample output.   bstnA# show nsck 1 shows details about the nsck operation with ID 1. See Figure 37.11 on page 37-39 for sample output.
Related Commands	clear nsck nsck ... report dir-structure nsck ... report inconsistencies nsck ... report metadata-only nsck ... migrate-metadata nsck ... destage nsck ... rebuild show reports

Purpose	Use the show sync command to show the results of all sync operations.
Modes	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show sync {files | directories} show sync {files | directories} namespace show sync {files | directories} namespace volume vol-path show sync {files | directories} namespace volume vol-path path path   files | directories is a required choice. This selects the type of sync operation to show. namespace (optional, 1-30 characters) is the name of a namespace. Use show namespace for a list of all configured namespaces. If you omit this (and all other options), the output includes all recorded sync-files or sync-directories operations. vol-path (optional, 1-1024 characters) focuses on a particular volume. Use forward slashes (/) for all volumes, including CIFS. path (optional, 1-1024 characters) narrows the focus further, to a particular path within the volume. As with volumes, use forward slashes in all paths.
Default(s)	None.
Guidelines	This command shows all sync operations, past and present. They are organized by namespace, volume, and in-volume path where the sync ran: Namespace is a namespace where at least one sync operation occurred. Volume is one volume where someone invoked a sync. Path is the path where a sync operation occurred. This contains details about the operation: Options are recurse and/or rename-files. This does not appear unless the user selected one of these options. They are options in the sync files command only. Type appears only for auto-sync operations. An auto-sync occurs only in a volume that is enabled to run them with auto sync files. A client triggers an auto-sync operation by getting an error that indicates metadata inconsistency. The value for this field is Automatic. Status is Pending, Syncronizing, Pending Cancel, Canceling, Success, or Failed. A typical sync operation goes from Pending to Syncronizing to Success. Use the cancel sync command to cancel the sync operation. For details on the sync operations progress, you can look at the sync report, described below. Report Name is the name of a detailed report about the sync operation. You can use the show reports command to view the report. Share only appears if the share was specified (see the documentation for sync files or sync directories).
Guidelines (Cont.)	Lost Items are the files or directories that were recorded in metadata but are missing from the back-end filer. Found Items are the reverse: these were found on the filer and needed to be added to the metadata. Synchronized Items is the total repaired files and directories. Ideally, this should be the sum of the lost and found items above. Processed Items is the total number of files and directories processed. This output grows with every run of the sync files or sync directories command. Use clear sync to clear all sync operations from this output (without deleting any of the detailed sync reports; use delete reports to remove those).
Samples	bstnA# show sync files displays the state of all sync-files operations for all namespaces. Figure 37.12 shows sample output.   bstnA# show sync directories displays the state of all sync-directories operations. Figure 37.13 on page 37-42 shows sample output.   bstnA# show sync files medarcv volume /rcrds displays the state of all sync-files operations for a CIFS volume, medarcv~/rcrds. Figure 37.14 on page 37-42 shows sample output.
Related Commands	sync files sync directories clear sync cancel sync

Purpose	If a directory appears on a back-end filer without the managed volumes awareness, the volume metadata is out-of-sync for that directory. This may occur for new directories that cannot be created from a client interface, such as NetApp qtrees. To use one of these special directories in a managed volume, you can create it on the back-end filer itself and then use the sync directories command to find it and add it to the volumes metadata.
Modes	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	sync directories namespace volume volume path path [share share-name]   namespace (1-30 characters) specifies the namespace to sync. Use the show namespace command for a list of configured namespaces. volume (1-1024 characters) specifies the namespace volume. All of the namespaces volumes appear in the show namespace output. path (1-1024 characters) chooses a specific directory in the volume (for example, var/log). The sync operation looks for new directories under this path; it does not descend into any already-known subdirectories. This path is relative to the volume root, above. Use forward slashes (/) for NFS or CIFS paths. share share-name (optional, 1-64 characters) limits the sync and repair to a single share in the volume.
Default(s)	all shares in the volume are synchronized and repaired.
Guidelines	In general, no changes should occur on a filer share that is imported into a managed volume, except changes that go through that volume. However, some directories require features that can only be applied directly on the back-end filer, such as NetApp qtrees. Use this command after one or more empty directories were added behind a managed volume. As mentioned above, only empty directories can be found with the sync utility. To find all new directories where they exist, use nsck ... report inconsistencies. This command, sync directories, finds all new subdirectories under a known directory. Very large directories may take a long time to synchronize. The command returns immediately, providing you with the name of a detailed report. You can continue using the CLI while the synchronization occurs in the background. 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. Each sync operation generates a report named sync.sync-job-id.volume.rpt, shown after you issue the command. Use show reports to list all reports, including this sync report. To follow the progress of the sync operation, you can use tail reports report-name follow. If the sync/repair fails, use the nsck ... rebuild command to rebuild the volume (drop all volume metadata and re-import all back-end shares).
Guidelines: Directory Mastership After the Sync	The sync directories command uses the share priority set by the import priority command. That is, if two or more shares have the synchronized directory, and no other instance of that directory is already imported, the import priority determines which share has the master instance of the directory. Whenever there are two or more instances of a volume directory on the volumes back-end shares, one of them is master and the rest are called stripes. The stripe directory conforms to the attributes of the master.
Sample	bstnA# sync directories medarcv volume /lab_equipment path /acme share leased Scheduling sync directories operation on switch bstnA, report name: sync.4._lab_equipment.rpt bstnA# finds any new subdirectories under a particular directory and on a particular share: the /acme directory in the medarcv~/lab_equipment~leased share. Figure 37.15 shows a sample report, where one new directory, /filters, was found and synchronized.
Related Commands	show sync wait-for sync cancel sync nsck ... report inconsistencies show namespace show reports nsck ... rebuild

Purpose	If a file changes on a back-end filer without the managed volumes awareness, the volume metadata is inconsistent for that file. Use the sync files command to report on metadata inconsistencies and repair them.
Modes	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	sync files namespace volume volume path path [share share-name] [recurse] [rename-files]   namespace (1-30 characters) specifies the namespace to sync. Use the show namespace command for a list of configured namespaces. volume (1-1024 characters) specifies the managed volume. All of the namespaces volumes appear in the show namespace output. path (1-1024 characters) narrows the scope of the repair to a specific path in the volume (for example, var/log). This path is relative to the volume root, above. Use forward slashes (/) for NFS or CIFS paths. share share-name (optional, 1-64 characters) limits the sync and repair to a single share in the volume. You can enter the final two options in any order, or you can omit them: recurse causes the sync operation to descend into subdirectories. rename-files determines that, if a file-collision is discovered, the sync operation can rename the newly-discovered file. All collisions and renames are included in the sync report, described below.
Default(s)	recurse is off; the sync only examines the dir-path without descending into any child directories. rename-files is off; collisions are noted in the sync report, and the metadata is not repaired. all shares in the managed volume are synchronized and repaired.
Guidelines	In general, no changes should occur on a filer share that is imported into a managed volume, except changes that go through that volume. However, some situations make this impossible: On reboot recovery, some filers replace files that were deleted shortly before the reboot. A filer-integrated Anti-Virus application may rename, remove, or create files on the filer itself. Some customers prefer to perform restore operations directly on their back-end filers.
Guidelines (Cont.)	Whenever a client tries to access a file that has been removed by one of the above operations, the client system reports an internal error. For CIFS operations, messages appear in the syslog (labeled UNXFINDNONE, UNXNOPATH, UNXOPENTYPE and/or UNXCRETYPE.), and the volume software sends an SNMP trap (vcifsNotfound or vcifsTypeMismatch). Use grep to search the syslog for a string. If a CIFS-only volume is configured to launch synchronizations automatically (with auto sync files), the manual sync files command is unnecessary. Use this command after any of the above operations (filer reboot, filer restore, or virus detection at the filer). You can also use this in response to client complaints. To confirm any inconsistencies and find all directories where they exist, use nsck ... report inconsistencies. Very large directories may take a long time to synchronize. The command returns immediately, providing you with the name of a detailed report. You can continue using the CLI while the synchronization occurs in the background. 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. Each sync operation generates a report named sync.sync-job-id.volume.rpt, shown after you issue the command. Use show reports to list all reports, including this sync report. To follow the progress of the sync operation, you can use tail reports report-name follow. If the sync/repair fails, use the nsck ... rebuild command to rebuild the managed volume (drop all volume metadata and re-import all back-end shares).
Guidelines: Discovering Symlinks	This command also probes for NFS symbolic links (or symlinks) in a multi-protocol namespace. NFS symlinks are recorded in a multi-protocol volumes metadata so that the volume can support them for its CIFS clients. (You can disable this CIFS-side de referencing with the cifs deny-symlinks command, if desired). Symlink discovery is unnecessary for most installations because symlinks are correctly flagged during import, and whenever an NFS client creates a new symlink. It is only necessary after a software upgrade adds CIFS symlink support to an existing multi-protocol volume, or if an NFS client created symlinks directly on a back-end filer.
Guidelines: Directory-Stripe Synchronization	Before the sync operation can sync any file, it must first verify that the files parent directory has synchronized attributes (permissions, ACLs, ownership, and so on). The parent directorys attributes must be identical for all instances of the directory, in all of the shares behind the managed volume. If any of the managed volumes shares are nearly out of space, this attribute-sync process may fail; this is because CIFS ACLs may be part of the directory attributes, and they require disk space. This directory-attribute sync may result in SC or SI flags in the report: SC indicates that a previously unsynchronized directory was successfully synchronized by this command. The managed-volume software does this in the background, so it is rare to see this in the report for a manual sync operation. SI indicates that the sync operation attempted to sync a directorys attributes, and the directory-attribute synchronization failed. This indicates that one of the managed volumes shares is out of space. You can use show namespace to find the full share. You can access the filer directly to add more space, or use a place-rule with a source share to drain some files off of the full share. Then the managed-volume software synchronizes the directory attributes in the background, and this condition clears.
Guidelines: File Mastership After the Sync	The sync files command uses the share priority set by the import priority command. That is, if two or more shares have the same file at the same path, and no other instance of that file is already imported, the share with the better import priority wins the master instance of the file. The volume renames the other file(s) or fails the sync operation, as determined by the rename-files flag. This is only relevant if you synchronize multiple shares. If you synchronize a single share, its files can only collide with already-imported files. An already-imported file is always master over a newly-imported file.
Samples	bstnA# sync files wwmed volume /acct path / Scheduling sync files operation on switch bstnA, report name: sync.1._acct.rpt bstnA# repairs the top-level directory in the wwmed~/acct volume. This does not descend into child directories, nor does it repair any renamed files that have collided with known files.   bstnA# sync files wwmed volume /acct path /jsmith recurse Scheduling sync files operation on switch bstnA, report name: sync.2._acct.rpt bstnA# recursively repairs the entire /jsmith directory in the wwmed~/acct volume.   bstnA# sync files medarcv volume /rcrds path / recurse rename-files Scheduling sync files operation on switch bstnA, report name: sync.3._rcrds.rpt recursively repairs the root directory (/) in a CIFS volume, medarcv~/rcrds. Figure 37.16 on page 37-48 shows a sample report, where a missing file, /copyRandomx.exe, was found and synchronized. Two additional files were also newly-discovered and synchronized.
Related Commands	show sync wait-for sync cancel sync nsck ... report inconsistencies show namespace show reports nsck ... rebuild

Purpose	A subshare is a CIFS share (along with its ACL) that is nested under an imported CIFS share. Use the sync subshares from namespace command to discover all of the CIFS subshares behind a managed volume and then share them from a front-end service. This synchronizes the CIFS subshares between back-end filers and the front-end service.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	sync subshares from-namespace ns volume vol to-service fqdn [expose-hidden] [tentative]   ns (1-30 characters) is the namespace for the sync operation. The namespace must support CIFS. vol (1-1024 characters) specifies a managed volume with subshares. This command finds all CIFS subshares in all of the back-end shares behind this volume. It also replicates any subshares that are not already identical on those back-end shares. The command replicates the subshare name, directory path (relative to the share root), and ACL on each back-end filer that needs it. fqdn (1-255 characters) is the target CIFS service to export all of the subshares found in the above volume. expose-hidden (optional) causes the command to use a different front-end name for any subshares that are hidden on their back-end filers. A CIFS share is hidden from Windows-network views by adding a dollar-sign ($) to the end of the share name (for example, mybooks$). This option causes the operation to use an exposed front-end subshare for all such hidden subshares, without the dollar suffix (mybooks). Clients of the CIFS service can therefore see the shares. This option does not expose any hidden subshares that may have been generated by the ARX, such as _acopia_mybooks_4$. tentative (optional) finds all of the subshares behind the volume and prints them in a report, but does not share them from the CIFS service.
Default(s)	None.
Guidelines	This operation is only effective in volumes that support CIFS and filer subshares. Subshares require special processing and configuration in order to be supported by the ARX. By default, if a CIFS client connects to a subshare on the ARX, the managed volume connects to the root of the filer share and then changes to the subshare directory from there. Since the volume connects to the root share, the ACL at that share is used to determine client-access privileges. This bypasses any share-level ACL that may be defined for the filer subshare. You can configure a managed volume so that it passes a client connection from a front-end subshare directly to the back-end subshare, thereby allowing the filer to enforce its subshare ACLs. Use the gbl-ns-vol filer-subshares command to prepare a CIFS volume for subshare support, and then use this command to share all filer subshares out through a front-end CIFS service. (You can also use the export (gbl-cifs) ... filer-subshare command to share out a single subshare at a time.) This command replicates all subshares, so that they have the same share names, ACLs, and directory names on all of the volumes shares. The subshare-replication process creates a sync report with the results. The name of the report appears after you issue the command. Use show reports report-name to see it. To add a new subshare to a running CIFS service, follow the procedure outlined in the Guidelines of the filer-subshares command.
Guidelines: Preparation for NetApp/EMCs Where You Want Free-Space Quotas	If the volume is backed by any NetApp filers or EMC servers and you plan to support free-space quotas on them (see freespace cifs-quota), prepare the subshares directly on the filer before you invoke this command. The subshare-replication process does not create NetApp qtrees or EMC quota trees, and those special directories are required to support free-space quotas. Before you run subshare replication with this command, access the filers directly and (on a NetApp) create one qtree per subshare, or (on an EMC) ensure that the imported share is a File System with one quota tree per subshare. See the Guidelines: Subshare Replication with Free-Space Quotas section of the filer-subshares documentation. Then invoke this command to synchronize their share-level ACLs and other attributes.
Guidelines: Naming for Replicated Subshares	This operation replicates subshares between filers as needed. Subshare replication also occurs during share import, so it is not typically necessary for this command to repeat it. For cases where it is necessary, the volume replicates every subshare name, directory path (relative to the import-share root) and ACL. Replicated 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 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. To prevent any such generated names on a volumes filers, you can use the native-names-only option in the filer-subshares command. The native-names-only option causes subshare replication to fail.
Guidelines: Repairing a Failed Subshare Replication	If this replication process fails for any subshare, the front-end subshare is degraded: clients cannot access the files in the unsynchronized back-end subshare(s). The show cifs-service all command shows the current status of the subshare-replication process, and whether or not any subshare is degraded. You can use this commands sync report to understand the problem, resolve the problem at the filer, and then use sync subshares from-service to re-run the subshare replication.
Sample	bstnA# sync subshares from-namespace medarcv volume /rcrds to-service ac1.medarch.org expose-hidden   % INFO: Sync subshares operation completed. See report 'syncSshrVolToService_20100706010239.rpt' for more detail.   replicates all subshares in the medarcv~/rcrds volume, then shares them out to clients through the ac1.medarch.org service. Figure 37.17 on page 37-53 shows a sample report.
Related Commands	filer-subshares export (gbl-cifs) ... filer-subshare show namespace show reports sync subshares from-service

Purpose	A subshare is a CIFS share (along with its ACL) that is nested under an imported CIFS share. Use the sync subshares from-service command to send CIFS subshares from a front-end CIFS service to all of the filers behind it. This is useful for repairing a degraded subshare.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	sync subshares from-service fqdn to-namespace ns volume vol [tentative]   fqdn (1-255 characters) is the FQDN for a CIFS service with subshares. Use the show cifs-service subshares all command for a complete list of CIFS services with subshares. ns (1-30 characters) is the namespace behind the above service. vol (1-1024 characters) is a particular managed volume with subshares. If the CIFS service exports any subshares from this volume, this command replicates the subshare definitions at all filers behind the volume. tentative (optional) prints a report about all of the changes the command would make, but does not replicate any subshare information from filer to filer.
Default(s)	None.
Guidelines	This operation is only effective in volumes that support CIFS and filer subshares. When you configure subshare support at the volume (with filer-subshares) and the volumes front-end export (with export (gbl-cifs) ... filer-subshare), a client that connects to the front-end subshare passes through the volume to the back-end subshare, so that the back-end filer can impose its subshare ACL. Without subshare support, a client that connects to a front-end subshare is passed through to the root of the back-end share, and the filer uses the root shares ACL. The ACL must be identical on all back-end instances of a subshare, so that clients have the same access rules no matter which back-end subshare they need. You can use this command, sync subshares from-service, to correct a possible problem with subshares. When you first enable a managed volume with subshare support, it discovers and replicates all of the subshares on its back-end shares. After you export a subshare through a front-end service at some fqdn, the show cifs-service fqdn command indicates whether or not this subshare-replication process succeeded. If the subshare is degraded, you can get a detailed report about the problem by running this sync command with its tentative flag. Then you can correct the problem at the back-end filers and run this sync command again, this time without the tentative flag, to retry the replication. The command creates a sync report with the results. The name of the report appears after you issue the command. Use show reports report-name to see it. To export subshares that are currently defined at the back-end filers, use the sync subshares from-namespace command. This is the reverse of the current command; it sends subshare definitions from the back-end filers to the front-end service.
Guidelines: Preparation for NetApp/EMCs Where You Want Free-Space Quotas	If the volume is backed by any NetApp filers or EMC servers and you plan to support free-space quotas on them (see freespace cifs-quota), prepare the subshares directly on the filer before you invoke this command. The subshare-replication process does not create NetApp qtrees or EMC quota trees, and those special directories are required to support free-space quotas. Before you run subshare replication with this command, access the filers directly and (on a NetApp) create one qtree per subshare, or (on an EMC) ensure that the imported share is a File System with one quota tree per subshare. See the Guidelines: Subshare Replication with Free-Space Quotas section of the filer-subshares documentation. Then invoke this command to synchronize their share-level ACLs and other attributes.
Guidelines: Naming for Replicated Subshares	This operation replicates subshares between filers as needed. The volume replicates every subshare name, directory path (relative to the import-share root) and ACL. Replicated 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 target 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 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. To prevent any such generated names on a volumes filers, you can use the native-names-only option in the filer-subshares command.
Sample	newptA# sync subshares from-service provmed.MEDARCH.ORG to-namespace provMed volume /mds tentative   % INFO: Sync subshares operation completed. See report 'syncSshrServToVolume_201110030248.rpt' for more detail.   tentatively syncs the subshares in the provmed.MEDARCH.ORG service. This produces a report that lists the subshares that require synchronization: see the sample in Figure 37.18 on page 37-57. The sample report shows missing subshares.
Related Commands	filer-subshares show cifs-service sync subshares from-namespace export (gbl-cifs) ... filer-subshare show namespace show reports

Purpose	Use the wait-for nsck command to wait for an nsck operation to complete.
Mode	(any)
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	wait-for nsck namespace [vol-path] [timeout timeout]   namespace (1-30 characters) is the name of a namespace. vol-path (optional, 1-4096 characters) identifies a particular managed volume in the namespace. timeout (optional, 1-2096) is the timeout value, specified in seconds. If this timer expires before the nsck operation completes, the command exits with a warning.
Default(s)	timeout - 0 (zero, meaning wait indefinitely)
Guidelines	The wait-for nsck command waits for an nsck operation on a specified namespace or volume to complete. To interrupt the wait-for nsck command before the nsck operation completes, press <Ctrl-C>. If the command is waiting for nsck ... rebuild, it exits after the volume(s) are destaged and have started importing files and directories from back-end shares. This command only waits until clients have full access to their files, not until import is complete.
Sample	bstnA(gbl-ns[medarcv])# wait-for nsck medarcv timeout 60 waits for a nsck operation to complete in the medarcv namespace. If 60 seconds elapse before the nsck operation is finished, the command exits.
Related Commands	clear nsck nsck ... report dir-structure nsck ... report inconsistencies nsck ... report metadata-only nsck ... rebuild show nsck show reports terminal beta

Purpose	Use the wait-for sync command to block the CLI until one or more sync operations completes.
Mode	(any)
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	wait-for sync {files | directories} [timeout timeout] wait-for sync {files | directories} namespace [timeout timeout] wait-for sync {files | directories} namespace volume vol-path [timeout timeout] wait-for sync {files | directories} namespace volume vol-path path path [timeout timeout]   files | directories is a required choice. This selects the type of sync operation to await. The namespace, vol-path, and path arguments mimic the ones used in the sync files or sync directories command. These identify one or more sync operations; if you omit all of them, the command waits for all sync-files or sync-directories operations on the switch. namespace (1-30 characters) specifies a namespace where one or more sync operations are occurring. vol-path (optional, 1-1024 characters) specifies a volume. Use forward slashes (/) for all volumes, including CIFS. path (optional, 1-1024 characters) identifies a particular path that is being synchronized. As with volumes, use forward slashes in all paths. timeout (optional, 1-2096) is the timeout value, specified in seconds. If this timer expires before the sync operation completes, the command exits with a warning.
Default(s)	timeout - 0 (zero, meaning wait indefinitely)
Guidelines	The wait-for sync command waits for a specified sync operation to complete. To interrupt the wait-for sync command, press <Ctrl-C>. Use cancel sync to cancel the sync operation altogether. The show sync command shows all sync-files or sync-directories operations.
Samples	bstnA# wait-for sync files timeout 60 waits for all sync-files operations on the switch to complete. If they do not complete in 60 seconds, the command returns with a warning.   bstnA(gbl-ns[medarcv])# wait-for sync directories medarcv timeout 300 waits for all sync-directories operations in the medarcv namespace to complete. If they do not complete in 300 seconds, the command returns with a warning.   bstnA> wait-for sync files wwmed timeout 120 waits for all sync-files operations in the wwmed namespace to complete. If they do not complete in 120 seconds, the command returns with a warning.
Related Commands	sync files sync directories show sync cancel sync