Purpose	A managed volume duplicates all CIFS subshares between its back-end filers. That is, if a CIFS share exists below one of its back-end shares, that lower share (called a subshare) and its ACL is duplicated to all of its peer subshares in the managed volume. In former software releases, the managed volume used a special name for the replicated subshares, with the format _acopia_subshare-name_id$ (for example, acopia_CELEBS_3$). You can use this command to promote all such subshare names to a native name, such as CELEBS. You can invoke this command on one share at a time.
Mode	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	cifs promote-subshares namespace ns volume vol share shr [tentative]   ns (1-30 characters) identifies the shares namespace. Use the show namespace command for a list of all namespaces. vol (optional, 1-1024 characters) identifies the managed volume with CIFS subshares. The show global-config namespace ns-name command lists all volumes (and other parameters) in a particular namespace. shr (optional, 1-64 characters) is the share with ARX-generated subshares. tentative (optional) creates a report showing all of the ARX-generated subshares at the back-end share, and showing the native share names that the managed volume would give to each subshare. You can use this option to confirm that the volume would rename the subshares as needed, then you can re-run the command without the option to actually perform the renames.
Default(s)	None
Guidelines	When you use the command without the tentative option, the CLI prompts for confirmation before it performs any subshare renames. Enter yes to proceed with the rename operations. This command generates a report to show the results (or tentative results) of the operation. The report name has a prefix of cifsPromoteSubshares and a time stamp; the exact name of the report appears after you enter the command. You can use the tentative option to generate the report, which reveals any subshares with names that were generated unnecessarily. (Some subshare names are generated to avoid a collision with another share name on the same back-end filer; you cannot use native names for those shares.) If you find any such subshare names, you can re-run the command without the tentative option to change them to their native names. If the volume has no modify set, preventing it from changing any configuration on its back-end filers, this operation always runs as though the tentative flag is raised. The command generates a report but does not change any subshare names. Use the filer-subshares command to enable subshare support in the managed volume.
Samples	bstnA# cifs promote-subshares namespace medarcv volume /rcrds share bulk tentative   % INFO: Promote subshares operation completed. See report 'cifsPromoteSubshares_201009020052.rpt' for more detail.   runs a tentative command to promote all subshares in the bulk share. The report shown in the prompt lists all of that shares subshares (if there are any) and the new names that the command would give them. A sample report, showing no subshares that require promotion, is in Figure 41.1 on page 41-4. Had the report shown any subshares that required promotion, you could promote them to native names by re-running the command without the tentative argument.   bstnA# cifs promote-subshares namespace ns4 volume /vol share shr3   This operation renames subshares on filer fs14[172.16.195.44] corresponding to ARX-generated subshares under share bulk in use by front-end passthrough exports for volume /vol. Continue? [yes/no] yes   % INFO: Promote subshares operation completed. See report 'cifsPromoteSubshares_201003161659.rpt' for more detail.   promotes all subshares in the shr3 share. The report lists all of that shares subshares and their new names.
Related Commands	filer-subshares

Purpose	Use this command to clear the authentication statistics for a front-end CIFS service.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	clear statistics cifs authentication {fqdn | all}   fqdn (1-128 characters) is the fully-qualified domain name (for example, myserver.organization.org) for a CIFS service. Use show cifs-service to see a list of CIFS services. all clears statistics for all CIFS services. The CLI requires confirmation before doing this.
Default(s)	None
Guidelines	The show statistics cifs authentication command shows counters and statistics for all CIFS authentications. Use this command to clear the traffic counters for one (or all) CIFS services. If you clear all statistics with this command, the CLI prompts for confirmation; enter yes to proceed.
Sample	bstnA# clear statistics cifs authentication all   Confirmation of this command causes CIFS authentication statistics to be cleared for all CIFS services.   Proceed [yes/no] yes clears all CIFS-authentication statistics from the system.
Related Commands	show statistics cifs authentication show cifs-service

Purpose	Each NSM processor keeps a cache of file and directory paths for CIFS managed volumes. The NSM processors learn these paths from the managed-volume software, then store them in their path cache. The system keeps running statistics on the usage of the path cache. This command clears the path-cache statistics for a CIFS-supporting namespace or volume.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	clear statistics cifs path-cache namespace [volume [slot.processor]]   namespace (1-30 characters) is the name of a namespace. Use the show namespace command for a list of all namespaces. volume (optional, 1-1024 characters) focuses on the path cache for a single volume. The show global-config namespace ns-name command lists all volumes (and other parameters) in a particular namespace. If you omit this, the statistics are cleared for all volumes in the namespace. slot.processor (optional: for example, 1.4) focuses on a single NSM processors cache. Each processor keeps an individual cache for each volume.
Default(s)	None
Guidelines	Use the cifs path-cache command to enable the CIFS path-cache for a volume. This command clears statistics only. It does not clear any path-cache entries. The show statistics cifs path-cache command shows counters and statistics for the path cache. Use this command to clear the counters for CIFS-supporting volumes. The CLI prompts for confirmation before clearing the statistics; enter yes to proceed.
Samples	bstnA# clear statistics cifs path-cache insur /rcrds 3.3   Clear path-cache statistics? [yes/no] yes clears the path-cache statistics that processor 3.3 kept for the insur~/rcrds volume.   bstnA# clear statistics cifs path-cache medarcv   Clear path-cache statistics? [yes/no] yes clears all path-cache statistics on all volumes in the medarcv namespace. This clears the statistics at all NSM processors.
Related Commands	cifs path-cache show statistics cifs path-cache show cifs-service path-cache

Purpose	CIFS clients can de reference NFS symbolic links (or symlinks) in a multi-protocol volume. Use this command to clear the statistics for these de referencing operations.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	clear statistics cifs symlinks [volume-group id]   volume-group id (optional) narrows the scope to a single volume group. A volume group is a failure domain for a group of volumes in the same namespace. If you omit this option, the command clears statistics from all volumes on the system.
Default(s)	None
Guidelines	The show statistics cifs symlinks command shows counters and statistics for all symlink de referencing operations. The statistics only include symlink operations on behalf of CIFS clients; NFS clients perform symlink de referencing at the client machine. Use this command to clear the symlink counters for one (or all) volume groups. The CLI prompts for confirmation before clearing any statistics; enter yes to proceed.
Sample	bstnA# clear statistics cifs symlinks   Clear statistics for CIFS symlink resolution for all Volume Groups?   Are you sure? [yes/no] yes clears all CIFS-symlink statistics from the system.
Related Commands	show statistics cifs symlinks

Purpose	CIFS volumes use internal work queues to process CIFS commands, CIFS authentication requests, and all the component tasks required to accomplish them. The volume software keeps statistics for the amount of processing time used by each work item in these queues. Use this command to clear those work-queue statistics.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	clear statistics cifs work-queues volume-group vg-id clear statistics cifs work-queues instance instance-id   volume-group vg-id (optional, 1-255) chooses a volume group. A volume group is a failure domain for a group of volumes in the same namespace. You can use show volume-group for a list of all volume groups on the system, and to see which volumes are assigned to each volume group. instance instance-id (optional) chooses a volume group by its namespace-instance ID. Instance IDs often appear in syslog messages, which you can view with show logs syslog. You can can also see instance IDs with show namespace all, which shows full details on all namespaces in the system.
Default(s)	None
Guidelines	The show statistics cifs work-queues command shows counters and statistics for all CIFS work queues. These statistics include time required to process each work item, number of work items completed and discarded from each queue, average processing time for each CIFS operation, and average round-trip times between the volume(s) and their back-end CIFS servers. The back-end-server statistics can only be cleared by the clear statistics filer command; this command clears all the remaining statistics. The CLI prompts for confirmation before clearing any statistics; enter yes to proceed.
Sample	bstnA# clear statistics cifs work-queues volume-group 2 Statistics for filer shares are not cleared by this command. It may take up to 30 seconds after the command for other statistics to be cleared.   Clear CIFS work-queue statistics? [yes/no] yes clears all CIFS-work-queue statistics for volume group 2.
Related Commands	show statistics cifs work-queues clear statistics filer

Purpose	The ARX keeps statistics for its NTLM/NTLMv2 authentications against each of its domain controllers (DCs). Use this command to clear the statistics for a particular DC, or for all DCs at once.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	clear statistics domain-controller {ip-address | all}   ip-address (for example, 1.2.3.4) identifies the DC for which you want to clear statistics. The show active-directory command shows all DCs that are known to the ARX. all clears NTLM statistics for all DCs.
Default(s)	None
Guidelines	The show statistics domain-controller command shows counters and statistics for NTLM and NTLMv2 authentications from all CIFS front-end services with constrained delegation. Use this command to clear the NTLM counters against a particular DC. The CLI prompts for confirmation before clearing any statistics; enter yes to proceed.
Sample	bstnA# clear statistics domain-controller 192.168.25.102 Clear domain-controller statistics? [yes/no] yes   clears all NTLM/NTLMv2 statistics for the DC at 192.168.25.102.
Related Commands	show statistics domain-controller show active-directory

Purpose	The ARX balances its Kerberos requests between multiple domain controllers (DCs) in the same Windows Domain, and keeps count of the number of requests to each DC. The ARX keeps these counters until the next reboot. Use this command to clear the counters immediately.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	clear statistics domain-controller load-balancing
Default(s)	None
Guidelines	The show statistics domain-controller load-balancing command shows counters for all Kerberos requests to all DCs. Use this command to clear those counters. The CLI prompts for confirmation before clearing any statistics; enter yes to proceed.
Sample	bstnA# clear statistics domain-controller load-balancing Clear load-balancing statistics? [yes/no] yes   clears all Kerberos-request counters for all DCs.
Related Commands	show statistics domain-controller load-balancing show active-directory

Purpose	A managed volume that supports filer-subshares keeps all of its subshare information in cache memory. This decreases the number of RPC calls between the ARX and its back-end filers during sync subshare operations. On the advice of F5 personnel, you can use this command to clear this cache.
Mode	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	clear subshare-cache [ext-filer-name]   ext-filer-name (optional, 1-64 characters) identifies an external filer with outdated subshare information. This is the name of the filer in the ARX configuration. For a list of configured external filers, use show external-filer.
Default(s)	None
Guidelines	Use the filer-subshares command to enable filer subshares for a volume. Then use export (gbl-cifs) ... filer-subshare to export a single subshare, or sync subshares from-namespace to export all of the subshares from the back-end filers. A filer subshare is any CIFS share that is inside an imported CIFS share. A client who connects to a front-end subshare, if the subshares are configured as described above, is passed through the managed volume directly to a corresponding subshare on a back-end filer. The filer can then enforce its subshare ACL, as opposed to the top-level ACL of the imported share. Each front-end subshare (visible to your CIFS clients) maps to one or more back-end subshares. The state of each filer share and share ACL resides in a memory cache; you can use show subshare-cache to see the contents o f the cache. The sync subshares from-namespace and sync subshares from-service commands clear this cache automatically before they begin, but only for the filers affected by the command. You can use this command to clear the entire cache, or the cache for one filer where you are sure that subshare information has changed. This slows the performance of future sync subshare commands, but ensures that the cache is updated with the latest subshare information on the back-end filer(s).
Sample	bstnA# clear subshare-cache fs2 clears the subshare-cache for the external filer named fs2.
Related Commands	filer-subshares sync subshares from-namespace sync subshares from-service show subshare-cache

Purpose	You can use the close cifs file command to close a file that is being held open by a CIFS client.
Modes	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	close cifs file fqdn slot.processor fid file-id   fqdn (1-128 characters) is the fully-qualified domain name for one CIFS service (for example, www.organization.org). This identifies the host for the open file. slot.processor (for example, 2.4) is the NSM slot and processor that is hosting the CIFS session, from the output of show cifs-service open-files. file-id (0-65535) identifies the file to close. You can also find this in the output of show cifs-service open-files.
Default(s)	None
Guidelines	Some Windows applications open a file, read it, immediately close it, and then present its contents to the user as though the file was still open. Notepad and WordPad are two commonly-used applications that use this practice. These applications do not actually hold the files open, so other clients can still access the file for writing. Other applications, such as Microsoft Word, hold the file open until the user closes it through the application interface. This prevents access from any competing applications or clients. This command closes any such file from the CLI. Use show cifs-service open-files to see all files that are currently held open by CIFS clients. This is the same open files listing seen through MMC. Use show cifs-service user-sessions to find clients with open CIFS sessions. You can also use drop cifs-service user-session to disconnect a client session. An authorized Windows client can perform this operation from an MMC interface (or a similar Windows-management client), assuming the CIFS service has browsing enabled and the client belongs to a properly-enabled windows-mgmt-auth group.
Sample	bstnA# close cifs file ac1.medarch.org 2.6 fid 1241 slot:2.6 CIFS open file with FID:1241 closed. closes an open CIFS file that is hosted by processor 2.6, through a CIFS service at ac1.medarch.org.
Related Commands	cifs show cifs-service open-files show cifs-service user-sessions browsing windows-mgmt-auth

Purpose	Use the drop cifs-service user-session command to drop a client connection to a CIFS service.
Modes	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	drop cifs-service user-session fqdn slot.processor ipaddress client-ip   fqdn (1-128 characters) is the fully-qualified domain name for one CIFS service (for example, www.organization.org). This identifies the host for the session. slot.processor (for example, 1.4) is the NSM slot and processor that is hosting the session, from the output of show cifs-service user-sessions. client-ip (an IP address in a.b.c.d format) identifies the client to drop.
Default(s)	None
Guidelines	This is useful for malfunctioning CIFS clients that fail to tear down their connections, or for testing. Use show cifs-service user-sessions to find clients with open CIFS sessions. You can also use show cifs-service open-files to see all files that are currently open through CIFS (and holding an exclusive-write lock). An authorized Windows client can perform this operation from an MMC (or similar) interface, assuming the CIFS service has browsing enabled and the client belongs to a properly-enabled windows-mgmt-auth group.
Sample	bstnA# drop cifs-service user-session ac1.medarch.org 2.5 ipaddress 172.16.100.214 disconnects a CIFS client at 172.16.100.214.
Related Commands	cifs show cifs-service user-sessions show cifs-service open-files browsing windows-mgmt-auth

Purpose	Use the show cifs-service client-activity command to show details about one clients connection to a CIFS service.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show cifs-service client-activity fqdn ip-address [connection-id [open-files | pending-transactions]]   fqdn (1-128 characters) is the fully-qualified domain name for one CIFS service (for example, www.organization.org). ip-address is the IP address of a single client. connection-id (optional) identifies a single client connection. You can get this ID from the summary output, then rerun the command with the ID to show details about the client connection. open-files (optional, if you chose a connection-id) shows only the Open Files table for the given client connection. pending-transactions (optional, if you chose a connection-id) shows only the pending transactions for the given client connection, if any.
Guidelines: Summary Output	The simplest syntax outputs the following fields, table, and summary: Client IP Address is the IP address of the client, specified on the command line. SlotProc is the NSM processor that is hosting the CIFS session, in slot.processor format. Then a table shows all of the connections from the above filer. Each connection appears on two rows. These rows contain the following fields: Conn is an integer ID to identify the front-end CIFS connection. You can rerun this command with this specific ID to see details about the connection, such as the specific files that the client is holding open. Port is the port on the NSM to which the client is connected. Age is the number of seconds that the client connection has been up. Sessions is the number of sessions from the client to the CIFS service (at the specified NSM processor). Tree Cons is the number of different front-end shares to which client is connected. These may be different volumes in the same namespace and/or different share names for the same front-end share (see export (gbl-cifs)). Open Files is the number of files open in this client session. Details on the open files appear in a table below. Username appears on its own line. This is the name provided by the CIFS client. Total number of connections is the sum of the above client connections.
Guidelines: Detailed Output for One Client Connection	If you specify a connection-id in the command, the output also includes two tables. You can use the open-files or pending-transactions keyword to include only one of these two tables.
Guidelines: Open Files Table	The Open Files table contains three rows per open file. The top row shows various IDs used for the clients front-end and back-end connections: FE Conn identifies the front-end connection to the client. This is the connection-id entered in the command. BE Conn identifies the back-end connection to a file server. FE UID is the clients User ID. The CIFS service provides the UID to the client after a successful authentication. This is only valid for the duration of the CIFS-client session. BE UID is the User ID used for the back-end connection. The CIFS service provides the UID to the client after a successful authentication to the back-end server. This is only valid for the duration of the CIFS session. FE TID is the clients Tree-connection ID. This identifies the clients CIFS connection to a particular resource, such as a directory tree offered by the front-end service. The TID changes for each CIFS session (whenever the connection is broken and re-established). BE TID is the Tree-connection ID for the back-end connection. FE FID is the front-end File ID for this file. This changes with each CIFS-client session. BE FID is the back-end File ID for this file. In cases where the back-end connection is to an internal process instead of a filer, the BE IDs are 0 (zero). The second row is the FE Path to the open file. This is the virtual path, as seen by the front-end client. The final row is the BE Path to the open file. This is the physical path on the back-end server.
Guidelines: Pending Transactions Table	Some CIFS transactions may wait in a queue before they get a response, such as messages from the NSM processes to back-end filers or to ACM processes. These are called pending transactions. This table lists all pending transactions, two rows per transaction. The top row shows CIFS IDs from the front-end (FE) perspective, along with the state of the associated back-end transaction: FE Conn is the client ID from the front-end CIFS service. The service assigns this to the client when it establishes a TCP connection. The CIFS service uses this internally to identify the client session. FE UID is the clients User ID. The CIFS service provides the UID to the client after a successful authentication. As above, this only valid for the duration of the CIFS session. FE MID is the Multiplex ID. The client software sets this. Whenever the client has its own pending transaction (waiting for response from the ARXs CIFS service), it can send a packet with a new MID to differentiate the new transaction. FE PID is the process ID, provided by the client. FE TID is the clients Tree-connection ID. This identifies the clients CIFS connection to a particular resource, such as a directory tree offered by the front-end service. The TID changes for each CIFS session (whenever the connection is broken and re-established). FE FID is the File ID for this file. This also changes with each CIFS session. State explains the current state of the transaction. This is the state of the CIFS connection between the NSM process and the remote process; unlike the preceding fields on the top row, this concerns the back-end (BE) CIFS session. The remote process is either a filer (referenced as the backend or the filer in the state text) or a namespace process (called dnas in the state text). The bottom row shows the same IDs for the back-end (BE) CIFS session with either a back-end filer or a namespace process on the ACM. If the latter, there is no authentication, tree connection, or file involved, so the UID, TID, and FID are all 0 (zero). The final field, Command, is the CIFS command that is pending.
Guidelines: Table Summaries	Total Open Files and Total Pending Transactions appear beneath the above tables.
Guidelines: Manipulating the Client Session	Use the show cifs-service user-sessions command for a list of all client connections to a CIFS service. You can use drop cifs-service user-session to disconnect a client session. An authorized Windows client can show and drop CIFS sessions from a Windows-management interface like MMC, assuming the CIFS service has browsing enabled and the client belongs to a properly-enabled windows-mgmt-auth group. For statistics on CIFS authentication, use show statistics cifs authentication.
Samples	bstnA> show cifs-service client-activity ac1.medarch.org 172.16.100.20 lists all client sessions with the ac1.medarch.org CIFS service. See Figure 41.2 for sample output.   bstnA> show cifs-service client-activity ac1.medarch.org 172.16.100.20 24 lists one client session with the ac1.medarch.org CIFS service. This uses the client-connection ID from the previous output, 24. See Figure 41.3 on page 41-18 for sample output.
Related Commands	cifs show cifs-service user-sessions drop cifs-service user-session show cifs-service open-files browsing windows-mgmt-auth show statistics cifs authentication

Purpose	Use the show cifs-service exports command to list CIFS exports and their client-connection statistics.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show cifs-service exports {fqdn [slot.processor] | all}   fqdn (1-128 characters) specifies a particular CIFS service (for example, www.company.com). slot.processor (optional: for example, 2.3) focuses on the connections to a particular NSM processor. all shows the connections statistics for all CIFS services.
Guidelines	The output is a table of CIFS shares that are exported by each NSM processor. Each row in the table describes a single export: Proc is the NSM that is exporting the share. Use show processors for a full list of all processors on the ARX. Export is the name of the CIFS share as seen by clients. This is created as part of the export (gbl-cifs) command. Namespace identifies the namespace behind this CIFS share. This is also chosen with the export (gbl-cifs) command. Virtual Path is the path to the CIFS share from the root of the volume. Again, this is from the perspective of the front-end client, and it is established by the export (gbl-cifs) command. Tree Connects is the heading for a series of connection statistics: Curr is the number of CIFS clients currently connected to the share and processor. Peak is the highest number of simultaneous connections. Total is the sum of all CIFS connections to the share. To see the client sessions that are connected to the CIFS service, use show cifs-service user-sessions. To disconnect a client session, use drop cifs-service user-session. The show cifs-service open-files command shows all files that are currently open through CIFS (with an exclusive-write lock). A share farm cannot auto-migrate a file in this state; use close cifs file to close one from the CLI.
Samples	bstnA> show cifs-service exports all lists all exports from all CIFS services. See Figure 41.4 on page 41-21 for sample output.   bstnA> show cifs-service exports ac1.medarch.org 2.8 lists all exports from a particular CIFS service and NSM processor. See Figure 41.5 on page 41-22 for sample output.
Related Commands	cifs show cifs-service show cifs-service user-sessions show cifs-service open-files

Purpose	If a CIFS service authenticates its clients with Kerberos, it caches all of the tickets granted to its clients. The tickets have expiration times, and are cached by the CIFS service until they expire. Use the show cifs-service kerberos-tickets command to list the Kerberos tickets in the cache.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show cifs-service kerberos-tickets {fqdn | all} [user username]   fqdn | all is a required choice: fqdn (1-128 characters) is the fully-qualified domain name for one CIFS service (for example, www.organization.org). all shows the tickets granted by all CIFS-services. username (optional: 1-128 characters) is used in a case-blind search: this shows all principals whose names start with this string. For example, myuser matches myuser, MYUSER@myco.com, and myusername@myorg.org.
Guidelines	This command shows the Kerberos tickets granted by CIFS services. Kerberos authentication must be enabled for the service to grant any such tickets: use cifs authentication kerberos (in gbl-ns mode) to enable Kerberos for a namespace, and domain-join to join the CIFS service to a Windows domain so that Kerberos works. The output has a separate table of principals (clients) and their tickets for each CIFS service. It contains the following fields: Service identifies the CIFS service by name. This is the FQDN of the CIFS services global server, used in the cifs command. Principal is name of the client who requested the ticket(s). Start Time(UTC) is the date and time when the CIFS service granted the ticket. As noted, this is not in local time. Expiry Time(UTC) is the date and time when the ticket is due to expire next. As above, this is not in local time. Service Principal is name of the server or Ticket-Granting Ticket that granted this ticket to the principal. Renew Till only appears for renewable Ticket-Granting Tickets. Total number of principals displayed, Total number of ticket-granting-tickets ..., and Total number of service tickets ... appear at the end of each CIFS-service section. An SNMP trap appears if the ticket cache begins to fill up. Use snmp-server traps and snmp-server trusthost to set up SNMP traps, and/or use email-event to deliver the traps via E-mail. The show health output also shows this condition if it arises. To see the client sessions that are connected to the CIFS service, use show cifs-service user-sessions. Use the show statistics cifs authentication command for statistics on all CIFS-service authentications: Kerberos, NTLMv2, and NTLM.
Sample	bstnA> show cifs-service kerberos-tickets all lists all Kerberos tickets granted by all CIFS services. See Figure 41.6 on page 41-24 for sample output.
Related Commands	cifs cifs authentication kerberos domain-join show cifs-service user-sessions show statistics cifs authentication

Purpose	Use the show cifs-service open-files command to list the files that CIFS clients are holding open.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show cifs-service open-files {fqdn [slot.processor] | all}   fqdn (1-128 characters) is the fully-qualified domain name for one global server (for example, www.organization.org). slot.processor (optional: for example, 1.3) focuses on the open files served by one NSM slot and processor. all shows the open files for all CIFS-service offerings.
Guidelines	This command shows all of the open files in a CIFS front-end service. Each open file is described with three rows of information. The first row shows the file view that the clients see: Proc is the NSM processor that is serving the file, in slot.processor format. User IP is the IP address of the client that has the file open. Mode shows the read/write mode used to open the file. This is either Read+Write or Read. FID is the CIFS file ID for the file, as seen by the client application. Each NSM processor assigns its own set of file IDs, so the same file ID may be reused by multiple processors. Virtual IP is the IP address that the client is using to access the file. This is established by the virtual server command. Virtual Share is the name of the CIFS share from the client perspective. This is established by the export (gbl-cifs) command, or by a Windows-management application like MMC (if browsing is enabled for the CIFS service). The second row contains more information, including the number of locks on the file and the back-end filer view: User Name identifies the client with a username and domain name. Locks is the number of range locks held by the client, if any. These are locks for ranges of bytes in the file. Filer IP is the IP address of the back-end filer that hosts the open file. Filer Share is the share name at the back-end filer.
Guidelines (Cont.)	The Namespace row indicates the ARX namespace where the file resides. The final two rows identify the open file: Virtual Path is the pathname of the open file from the root of the ARX volume. Path on Filer is the pathname of the open file from the root of the Filer Share shown above. To close an open CIFS file, use close cifs file. To see the client sessions that are connected to the CIFS service, use show cifs-service user-sessions. An authorized Windows client can perform all of these operations from an MMC (or similar) interface, assuming the CIFS service has browsing enabled and the client belongs to a properly-enabled windows-mgmt-auth group.
Samples	bstnA> show cifs-service open-files ac1.medarch.org lists all open files in the ac1.medarch.org service. See Figure 41.7.   bstnA> show cifs-service open-files ac1.medarch.org 2.9 focuses on files served by a particular processor, 2.9. See Figure 41.8 on page 41-29.
Related Commands	cifs close cifs file show cifs-service user-sessions browsing windows-mgmt-auth

Purpose	Each NSM processor can keep a cache of file paths in memory. Whenever a CIFS client requests a file or directory path, the NSM processor queries namespace software (on the ACM) for the virtual path and records the answer in its cache. The next request for the same path goes to the cache instead of the namespace software. This decreases the number of repetitive path queries to namespace software, thereby increasing performance. Use the show cifs-service path-cache command to show all file/directory paths currently in the path cache.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show cifs-service path-cache namespace [volume [slot.processor]] [detailed]   namespace (1-30 characters) is the name of a namespace. Use the show namespace command for a list of all namespaces. volume (optional, 1-1024 characters) focuses on the path cache for a single volume. The show global-config namespace ns-name command lists all volumes (and other parameters) in a particular namespace. slot.processor (optional: for example, 2.2) focuses on a single NSM processors cache. detailed (optional) shows the additional front-end export, /acopia#, if it is exported by this CIFS service. This export is automatically generated by a CIFS service with browsing enabled.
Guidelines	Use the cifs path-cache command to enable the CIFS path cache for a volume. At the top of the output is one line per selected volume, indicating whether or not the volume has CIFS path caching enabled. Below these lines is a table with all of the currently-cached file paths. Each file (or directory) path is described with three rows of information. The first row shows the volume and share (and, possibly subshare) with the virtual path, and the NSM processor that has the path in its cache: Volume is the name of the volume with this file path. ShareName is the name of the share as it appears in the volume configuration. (The name of the filer share appears in the next row.) SubShareName, if applicable, is the name of the subshare where this path resides. A subshare is any share under the imported share; see the documentation for the filer-subshares command. slot.proc is the NSM processor that is serving the file, in slot.processor format.
Guidelines (Cont.)	The second row contains more information: \\Filer\ShareName identifies the back-end share for the cached path. The external-filer name is the one configured on the ARX; use show external-filer for a full list of all configured filers. The share name is the one configured on the filer itself. Age is the age of the cache entry in seconds. After 120 seconds of non-use, the entry is invalidated; the next search for the path causes a new namespace query. This aging process keeps the cache from occupying excessive memory. State is the current state of this cache entry. This can be up (the path is valid), init, pending (the NSM processor is waiting for a response from the namespace software), down (the path information is known to be stale), none, or unknown. The final row identifies the virtual path: Path shows the path from the client perspective. This always starts from the root of the volume. Use the show statistics cifs path-cache command to show the total path-cache usage since the last ARX reboot.
Samples	bstnA> show cifs-service path-cache medarcv lists all cached paths for the medarcv namespace. See Figure 41.9 on page 41-32.   bstnA> show cifs-service path-cache insur /claims shows the path cache for a specific volume, insur~/claims. See Figure 41.10 on page 41-33.
Related Commands	cifs path-cache show statistics cifs path-cache

Purpose	Use the show cifs-service transactions command to list the active CIFS transactions from a particular client-IP address.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show cifs-service transactions ip-addr   ip-addr (optional) is the source-IP address of a client machine.
Guidelines	This command shows the current CIFS transactions between a client station and the ARX. CIFS Transactions for the client: is the IP address of the client, entered in the command. via Processor shows the NSM processor that is hosting the CIFS session, in slot.processor format. Src Port is the transport protocol (TCP or UDP) and port of the client, in transport/port format. RPC is the name of the Remote Procedure Call invoked by the client transaction. Status describes the current state of the transaction: Fwd Filer means that the NSM is forwarding the client connection to a back-end filer. Fwd Volume Group Proc indicates that the NSM is forwarding the client connection to managed-volume software on the control plane. Fwd Fastpath Proc means that the namespace software is forwarding the client application back to an NSM processor (the fastpath). To see the client sessions that are connected to a particular CIFS service, use show cifs-service user-sessions. Use show cifs-service open-files to see all files that are currently open through CIFS.
Sample	bstnA> show cifs-service transactions 172.16.100.20 shows all currently-active transactions between the PC at 172.16.100.20 and any CIFS services on the switch. See Figure 41.11 for sample output.
Related Commands	cifs show cifs-service user-sessions show cifs-service open-files

Purpose	Use the show cifs-service user-sessions command to list the client connections to a CIFS service.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show cifs-service user-sessions all [summary] show cifs-service user-sessions all [namespace ns [volume vol]] show cifs-service user-sessions fqdn [slot.processor] show cifs-service user-sessions fqdn [namespace ns [volume vol]]   all shows all client sessions with all CIFS services. summary (optional) shows client-authentication counters for all CIFS services. namespace (1-30 characters) focuses on client sessions with one of the services namespaces. Use the show namespace command for a list of all namespaces. volume (optional, 1-1024 characters) focuses on the client sessions with a single volume. The show global-config namespace ns-name command lists all volumes (and other parameters) in a particular namespace. fqdn (1-128 characters) is the fully-qualified domain name for one CIFS service (for example, www.organization.org). This option focuses on the client connections to a single CIFS service. slot.processor (optional: 2.1-12 on ARX-4000; 1.2-5 on ARX-2000; 1.2 on ARX-500 or ARX-VE) focuses on the sessions with one NSM slot and processor.
Guidelines	For each selected cifs service, this command shows a table of current client sessions. The table contains one client session per row. Proc is the NSM processor that is hosting the CIFS session, in slot.processor format. IP Address is the source IP of the client. Username shows the Windows credentials used by the client. Auth is the authentication protocol used for the client connection. This is Kerberos, NTLMv2, NTLM, or Anon. The Anon means anonymous access; clients can log into the CIFS service (below) anonymously, but then have extremely limited access to the services storage and other resources. Anonymous access to the IPC$ share is only supported if the CIFS service is backed by a namespace with cifs anonymous-access. Sign shows whether or not the client connection is using SMB signing, a CIFS security feature. You can use the signatures command to determine (or change) SMB-signing support at the CIFS service. Age is the time that the client connection has been up.
Guidelines (Cont.)	Total number of users displayed appears at the bottom of the output. To disconnect a CIFS client, use the drop cifs-service user-session command. Use show cifs-service open-files to see the open files in the service, or close cifs file to close one from the command line.
Guidelines: Summary Output	The all summary options show counters for each type of client authentication. Each CIFS service appears in a row with the following counters: Kerberos shows the number of Kerberos authentications to the service. NTLMv2 and NTLM are the number of clients that authentication with NTLMv2 or NTLM. Anon shows the number anonymous accesses to this service. Clients can log into the CIFS service anonymously, but then have extremely limited access to the services storage and other resources. Anonymous access to the IPC$ share is only supported if the CIFS service is backed by a namespace with cifs anonymous-access.
Samples	bstnA> show cifs-service user-sessions all lists all client sessions with all CIFS services on the switch. See Figure 41.12 for sample output.   bstnA> show cifs-service user-sessions all summary shows authentication counters for all CIFS services. See Figure 41.13 on page 41-37 for sample output.   bstnA> show cifs-service user-sessions ac1.medarch.org lists all client sessions with the CIFS service at ac1.medarch.org. See Figure 41.14 on page 41-37 for sample output.   bstnA> show cifs-service user-sessions ac1.medarch.org namespace medarcv volume /rcrds lists all client sessions with a particular volume behind the CIFS service at ac1.medarch.org. See Figure 41.15 on page 41-38 for sample output.   bstnA> show cifs-service user-sessions ac1.medarch.org 2.7 narrows the list of client sessions to those that are hosted by a single processor, 2.7. For sample output, see Figure 41.16 on page 41-38.
Related Commands	cifs show cifs-service open-files browsing windows-mgmt-auth signatures show statistics cifs authentication

Purpose	Use the show fastpath cifs-signatures command to show counters and statistics for SMB signing. SMB signing is a CIFS security feature for client/server communication, where all packets contain a digital signature that the sender creates and the receiver verifies. This command shows counters for various SMB-signing activities, both on the client side and the filer side.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show fastpath cifs-signatures [slot.processor]   slot.processor (optional: for example, 1.3) focuses on the signing statistics for one NSM slot and processor. If you omit this, the output contains statistics from all network processors.
Guidelines	The default output shows the SMB-signing counters for all network processors. Each processors counters appear in a separate table, with one row per counter. Each row shows the counter for the client side of the ARX and the filer side. Outbound Unsigned SMBs is the number of unsigned CIFS packets sent from the ARX. The first number is the number of unsigned packets sent to clients, and the second is the number of unsigned packets sent to back-end filers. Outbound Signed SMBs is the number of signed CIFS packets sent from the ARX to its clients, followed by the number of signed packets sent to back-end filers. Inbound Unsigned SMBs counts the unsigned CIFS packets received by the ARX from clients and filers, respectively. Inbound Verified SMBs is the number of signed CIFS packets received and verified by the ARX. Inbound SMB Verify Errors counts all inbound CIFS packets that were rejected because their SMB signatures failed verification. You can use the cifs filer-signatures command to enable, require, or disable SMB signing between a namespace and its back-end filers. The signatures command enables, requires, or disables SMB signing between a CIFS service and its clients.
Samples	bstnA(cfg)# show fastpath cifs-signatures shows the SMB-signing counters for all network processors. See Figure 41.17 on page 41-40 for sample output.   bstnA(cfg)# show fastpath cifs-signatures 2.8 focuses on the SMB-signing counters for a particular network processor. See Figure 41.18 on page 41-42 for sample output.
Related Commands	cifs filer-signatures signatures

Purpose	Use the show statistics cifs authentication command to show counters and statistics for CIFS-authentication.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show statistics cifs authentication {fqdn | all} [verbose]   fqdn | all is a required choice: fqdn (1-128 characters) is the fully-qualified domain name for one CIFS service (for example, www.mystate.gov). all shows all authentication statistics from all CIFS-services. verbose (optional) adds an additional table to the output. The table shows details for all CIFS-authentication failures.
Guidelines	The default output shows the CIFS-service FQDN, its Windows Domain, and two tables.
Guidelines: Client Authentication Table	Client Authentication, the first table, shows Kerberos, NTLMv2, and NTLM counters for front-end CIFS clients. These count the authentications between clients and the CIFS service. The NTLM and NTLMv2 counts include Netlogon authentications and authentications through a separately-installed Secure Agent. A CIFS service that uses constrained delegation uses Netlogon, but a CIFS service that use unconstrained delegation uses the Secure Agent. You choose between constrained and unconstrained delegation when you run domain-join for the service. Client authentication success and Client authentication failure count the number of successful and failed authentication attempts for NTLM, NTLMv2, and Kerberos. Principals in same realm is a Kerberos-only counter. This is the number of principals (users and hosts) who were in the same Kerberos realm (Windows domain) as the CIFS service. The CIFS-service realm/domain is established in the global-server configuration: use show global server fqdn to see it and windows-domain (gbl-gs) change it. Principals in trusted realm is another Kerberos-only counter. These are the number of principals in a trusted realm. Trust relationships in realms are established by the local Active-Directory forest, which you configure on the ARX with active-directory-forest and its sub commands. Use show active-directory to show the Active-Directory forest on this ARX. Principals in realm unknown counts the Kerberos-using principals who were outside any realm (domain) in the Active-Directory forest. This may indicate one or more realms/domains are missing from the ARXs Active-Directory-forest configuration.
Guidelines (Cont.)	Errors contacting Secure Agent are NTLM and/or NTLMv2 errors for a CIFS service that uses unconstrained delegation or is not joined to its domain (see the domain-join command). These may indicate a connection problem with the Secure Agents DC host. Use show ntlm-auth-server to show the host(s) for the Secure Agent, and use show exports host dc-ip-address connectivity to check connectivity to the DC. SMB signing incompatibility counts the number of times that a client and the CIFS service could not successfully negotiate SMB signing. In this case, one end of the connection requires SMB signing and the other end of the connection refuses it. You can use the signatures command to set the SMB signing policy for the CIFS service.
Guidelines: Filer Authentication Table	Filer Authentication shows statistics for back-end Windows authentication. These count the authentications between the CIFS service and the back-end CIFS servers. Some of these statistics have different meanings depending on the delegation setting for the CIFS service; when the service joins its Windows domain (see domain-join), it is set for either constrained delegation or unconstrained delegation. Constrained delegation is more secure, and therefore recommended. Control plane authentication success and Control plane authentication failure count all authentication attempts that originate from the control plane. The control plane is where volumes, global-servers, and the policy engine run. These count the client requests that require processing at the control plane. Fast path authentication success and Fast path authentication failure are the authentications that do not require processing at the control plane; they are processed at the NSM only. Cross-Realm TGTs granted applies only to Kerberos. For a CIFS service that uses constrained delegation, the CIFS service follows the Kerberos S4U protocol and obtains service tickets on behalf of its clients. This counts the number of cross-realm service tickets that the service obtained. For unconstrained delegation, the CIFS client presents a Ticket-Granting Ticket (TGT) to the CIFS service, which then uses that TGT to get a Service Ticket for a back-end filer. This counts the number of cross-realm TGTs that the DCs granted. Cross-Realm TGTs denied are also Kerberos-only statistics, with different meanings for CIFS services with constrained or unconstrained delegation: For constrained delegation, this is the number of S4U service tickets that have been denied, where the client was in a different realm (or domain) from the CIFS service. A constrained CIFS service uses the Kerberos Service-for-User (S4U) protocol extension, where the CIFS service gets service tickets to its back-end filers on behalf of each of its Kerberos clients. If these tickets are denied, verify that the CIFS service still has an account configuration at a local DC, and that the accounts password key has not expired. If the password key has expired, you must use domain-join to rejoin the CIFS service to its domain. For unconstrained delegation, the CIFS client presents a TGT to the CIFS service, which then uses that TGT to get a Service Ticket for a back-end filer. This counts the number of cross-realm TGTs that the DCs denied.
Guidelines: Filer Authentication Table (Cont.)	Cross-Forest TGTs granted, and Cross-Forest TGTs denied are also Kerberos-only statistics. These only apply to a service with unconstrained delegation. The CIFS client presents a Ticket-Granting Ticket (TGT) to the unconstrained CIFS service, which then uses that TGT to get a Service Ticket for a back-end filer. These fields count the number of cross-forest TGTs that the ARX requested. A cross-forest TGT grants access from one forest to another. Use show active-directory to view all realms (or Windows domains), all forests, their connections to one another, and the Domain Controller(s) for each. Service tickets granted, and Service tickets denied are Kerberos-only statistics that apply to both constrained and unconstrained delegation. These are the results from attempting to attain Service Tickets on behalf of clients. Control plane expired TGTs count the problems that the control plane has encountered with TGTs. Fast path expired TGTs are TGT errors for NSM-only transactions. Errors contacting Secure Agent may indicate a connection problem with the Secure Agents DC host. These counters only apply to a CIFS service that uses unconstrained delegation (or is not joined to its domain). This is an NTLM/NTLMv2 counter. Use show ntlm-auth-server to show the host(s) for the Secure Agent, and use show exports host dc-ip-address connectivity to check connectivity to the DC. SMB signing incompatibility counts the number of times that a filer and the namespace behind the CIFS service could not successfully negotiate SMB signing. In this case, one end of the connection requires SMB signing and the other end of the connection refuses it. You can use the cifs filer-signatures command to set the SMB signing policy for a namespace. S4U-to-self tickets granted and S4U-to-self tickets denied count the successful and failed attempts for the CIFS service to get a service ticket for itself. These only apply to a CIFS service configured for constrained delegation. Such a CIFS service needs a service ticket to itself for each of its Kerberos clients. A constrained CIFS service uses the Kerberos Service-for-User (S4U) protocol extension, which necessitates this ticket. This is the total number of such tickets that have been denied, including the cross-realm tickets shown in the Cross-Realm TGTs denied field above. If these S4U tickets are denied, verify that the CIFS service still has an account configuration at a local DC, and that the accounts password key has not expired. If the password key has expired, you must use domain-join to rejoin the CIFS service to its domain.
Guidelines: Verbose Output	If you use the verbose keyword, additional tables appear to display CIFS-authentication failures. The tables display detailed reasons for the last 20 failures. The Client Authentication section has a table entitled Authentication Failure Reason Table. Each failure appears on two lines with the following fields: Error Code is an internal code name for the error (for example, KRB5KRB_AP_ERR_MODIFIED). Error Description is the text for the error (for example, Message stream modified). Count is the number of times the error has occurred. Only unique errors appear in this table; this counter increments each time the CIFS service gets each error. Last Time is the date and time the error was last received. Last Client IP is the IP address of the client to get the error. The Filer Authentication section has a similar table. Instead of showing a filer IP in all cases, this attempts to show the Principal involved with each back-end authentication error. These tables contain up to 20 unique authentication errors. After a service reaches 20 errors, any new errors are dropped until you clear the statistics. The clear statistics cifs authentication command clears all CIFS-authentication statistics, including these tables.
Sample	bstnA(cfg)# show statistics cifs authentication ac1.medarch.org shows CIFS-authentication statistics for the CIFS service at ac1.medarch.org. See Figure 41.19 on page 41-46 for sample output.
Related Commands	clear statistics cifs authentication show cifs-service kerberos-tickets show statistics domain-controller show statistics cifs work-queues

Purpose	Use the show statistics cifs fastpath command to show counters and statistics for CIFS servers. The NSM processors keep these statistics.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show statistics cifs fastpath [all | slot.processor]   all (optional) shows statistics from all NSM processors. slot.processor (optional: 2.1-12 on ARX-4000; 1.2-5 on ARX-2000; 1.2 on ARX-500 or ARX-VE) focuses on the statistics for one NSM slot and processor. If you omit this, the output contains statistics from all NSM processors; the effect is the same as using the all keyword.
Guidelines	The output is a table with one row per NSM processor. Each row contains the following fields: Proc identifies the NSM processor. This is in slot.processor format. Transactions Handled is the sum of front-end and back-end CIFS transactions handled by the processor since the last reboot. FrontEnd Connections shows the current number of connections from clients. BackEnd Connections is the current number of connections made to filers on behalf of CIFS clients. File Info shows the current number of files, pipes, and directories held open on this processor. File Handles is the total file handles associated with the above files, directories, and/or pipes. This number may be lower than the above number because multiple clients may be accessing the same files.
Samples	bstnA(cfg)# show statistics cifs fastpath shows CIFS statistics for all CIFS services. See Figure 41.20 for sample output.   bstnA(cfg)# show statistics cifs fastpath 2.4 focuses on a single NSM processor. See Figure 41.21 for sample output.
Related Commands

Purpose	Each NSM processor can keep a cache of file/directory paths to improve CIFS performance. Use the show statistics cifs path-cache command to show counters and statistics for this cache.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show statistics cifs path-cache namespace [volume [slot.processor]]   namespace (1-30 characters) is the name of a namespace. Use the show namespace command for a list of all namespaces. volume (optional, 1-1024 characters) focuses on the path cache for a single volume. The show global-config namespace ns-name command lists all volumes (and other parameters) in a particular namespace. slot.processor (optional: for example, 2.4) focuses on a single NSM processors cache.
Guidelines	Use the cifs path-cache command to enable the CIFS path-cache for a volume. The output is one or more tables, where each table contains statistics for each volume on each NSM processor. Each NSM processor keeps a separate cache for every managed volume it serves. The header for each table identifies its managed volume and its NSM processor (in slot.processor format). The table body contains the following counters: Total Hits is the number of path queries from CIFS clients where the path was found in the cache. Total Misses counts the path queries where the answer was not in the cache. These result in a lookup query to the namespace software; the path goes into the cache (for future requests) after a successful lookup. DNAS Lookup Fails shows the number of path lookups that failed. (The namespace software is called DNAS.) A lookup can fail when a file or directorys path is in flux due to migrations, filer error, or some other issue. Many of these issues are counted in the fields below. The next block of fields show the number of path-cache entries that have been declared invalid, and removed from the cache. DNAS Invalidates shows the number of paths that were removed from the cache due to an invalidate message from the namespace software. The namespace software sends an invalidate message when a file or directorys path is changing: during a migration (caused by rules like place-rule, and auto-migrate), during a directory rename, while a managed-volume share is being removed (caused by, for example, remove-share migrate), while the volume is being disabled (no enable (gbl-ns, gbl-ns-vol)), or during a share import (enable (gbl-ns-vol-shr)). Client Invalidates is the number of paths that have been invalidated (removed from the cache) due to some client action, such as a rename or delete.
Guidelines (Cont.)	Filer Reply Invalidates is the number of paths that have been invalidated by a filers unexpected not found response. This is typically a case where a filer application, such as anti-virus software, has moved a file. If the volume has auto sync files enabled, it responds to this by probing the filer and updating its metadata with the correct path. Age Invalidates counts the number of paths that were removed from the cache due to a 120-second timeout. Each path stays in the cache for at least 120 seconds before being removed, to avoid wasting valuable memory. The clock restarts every time a client requests the path. Insert Invalidates shows the number of paths that were removed from the cache to make room for a new path. This only occurs when the path cache exceeds its maximum size; the NSM processor removes the oldest entries first. Mgmt Invalidates counts the paths that were invalidated due to a CLI or GUI command that destages a volume (nsck ... destage) or rebuilds it (nsck ... rebuild). This invalidates all paths in the volume.
	Coll Invalidates is the number of paths that were declared invalid when a case collision was discovered. A case collision is a path on another share that is exactly the same except in letter case (for example, /myDir/yourDir/yourFile.doc has a case collision with /myDir/yourDir/YOURFILE.DOC). The final block of fields summarizes the path-cache statistics: Current Entries shows the number of paths in the cache now. Max Entries shows the maximum size of the cache since the last reboot. Total Entries is the sum of all path-cache entries since the last reboot. Use the clear statistics cifs path-cache command to clear the above statistics. To see the current contents of the path cache, use the show cifs-service path-cache command.
Samples	bstnA(cfg)# show statistics cifs path-cache insur shows path-cache statistics for the insur namespace. See Figure 41.22 for sample output.   bstnA(cfg)# show statistics cifs path-cache medarcv /rcrds focuses on a single volume. See Figure 41.23 on page 41-52 for sample output.   bstnA(cfg)# show statistics cifs path-cache medarcv /rcrds 2.6 focuses on a single volume and processor. See Figure 41.24 on page 41-53 for sample output.
Related Commands	cifs path-cache show cifs-service path-cache clear statistics cifs path-cache

Purpose	In a multi-protocol (CIFS and NFS) volume, CIFS clients can follow the symbolic links (or symlinks) created by NFS clients. Use the show statistics cifs symlinks command to show counters and statistics for symlink usage by CIFS clients.
Mode	(any)
Security Role(s)	network-technician, network-engineer, storage-engineer, backup-operator or crypto-officer
Syntax	show statistics cifs symlinks [volume-group id]   volume-group id (optional) narrows the scope to a single volume group. A volume group is a failure domain for a group of volumes in the same namespace. If you omit this option, the output shows statistics for all of the volumes on the system.
Guidelines	Multi-protocol volumes keep these statistics for de referencing symlinks for its CIFS clients. To disable all CIFS access to symlinks in a given volume, you can use the cifs deny-symlinks command. You can use the clear statistics cifs symlinks command to clear these statistics. The statistics also clear after every chassis reboot.
Guidelines: Output	The output is a group of tables, one per volume group. Each table contains the following statistics: Symlink requests dereferenced from backend is the number of symlink reads that required a query to the back-end filer. These are symlinks requested by CIFS clients. The volume software queries the back-end filer once and then caches the symlink target for future CIFS-client access. Symlink requests dereferenced from cache counts the symlinks that were accessed from the internal cache, without requiring any back-end access. Total symlink requests dereferenced is the sum of the above two counters. This is the total number of times that CIFS clients accessed symlinks in the given volume group. Entries in symlink cache shows the current number of symlinks stored in the internal cache. These are symlinks accessed by one or more CIFS clients in the past 2 minutes. Symlink cache size indicates the amount of memory currently used by the internal symlink cache. This is rounded to the nearest Kilobyte. Cache hit rate is the percentage of symlinks resolved by accessing the internal cache. The remaining symlinks were resolved by querying a back-end filer.
Guidelines: Output (Cont.)	The remaining statistics count all failed attempts to de reference symlinks for CIFS clients: Failed symlink requests dereferenced to a dangling path counts all attempts to access a dangling symlink. A dangling symlink is one that points to a non-existent file or directory. Failed symlink requests dereferenced to an absolute path is the number of attempts to access an absolute symlink. An absolute symlink is one starts with a slash (/) or back slash (\); for example, /vol/vol3/flightRecords/2009. A CIFS-client machine invariably has a different root path than the one in the symlink (such as e:\flightRecords\2009), so it cannot possibly interpret an absolute symlink. Failed symlink requests due to filer timeout is the number of back-end queries that failed due to a back-end-filer timeout. Failed symlink requests due to other filer error counts the back-end queries that failed due to any non-timeout error by the filer.
Samples	bstnA(cfg)# show statistics cifs symlinks shows CIFS symlink statistics for all volume groups on the ARX. See Figure 41.25 for sample output.   bstnA(cfg)# show statistics cifs symlinks volume-group 4 focuses on a single volume group. See Figure 41.26 on page 41-56 for sample output.
Related Commands	clear statistics cifs symlinks cifs deny-symlinks

Purpose	A CIFS volume uses internal work queues to manage its CIFS-related tasks. There is a main work queue for the bulk of client requests, an authentication queue for client-authentication tasks, two queues for communication with the data plane (networking software), and so on. The show statistics cifs work-queues command shows the time that CIFS work items have spent waiting in these work queues, as well as the time used to perform the actual work. You can use this information for troubleshooting CIFS performance issues.
Mode	(any)
Security Role(s)	network-technician, network-engineer, storage-engineer, crypto-officer, or operator
Syntax	show statistics cifs work-queues volume-group vg-id show statistics cifs work-queues instance instance-id   volume-group vg-id (optional, 1-255) chooses a volume group. A volume group is a failure domain for a group of volumes in the same namespace. You can use show volume-group for a list of all volume groups on the system, and to see which volumes are assigned to each volume group. instance instance-id (optional) chooses a namespace by its instance ID. Instance IDs often appear in syslog messages, which you can view with show logs syslog. You can can also see instance IDs with show namespace all, which shows full details on all namespaces in the system.
Guidelines	The clear statistics cifs work-queues command clears most of these statistics, and clear statistics filer clears the rest of them. A chassis reboot clears all of them at once. There are some related CLI commands that can aid in troubleshooting CIFS connections. Use show cifs-service user-sessions to see the which CIFS clients are currently connected to the ARX. Use show cifs-service client-activity to see how many back-end session, tree connections, and files they currently have open. The show cifs-service open-files command shows details about currently-open files. For details about currently-held Kerberos tickets, use the show cifs-service kerberos-tickets command. The show statistics domain-controller command examines the NTLM-related communication with domain controllers in the network.
Guidelines: Output	The output is a series of tables. The work queues only function in managed volumes that support CIFS. The tables are empty for a volume group or namespace that only supports NFS-only volumes and/or direct volumes.
Guidelines: CIFS Work Queue Histograms	CIFS work queue pool statistics shows the usage statistics for each CIFS work queue in the chosen volume group or namespace instance. Reset... shows the last time these statistics were cleared. The software resets these statistics whenever someone issues the clear statistics cifs work-queues command or reboots the chassis. Under the Reset line, a separate sub table appears for each work queue: Work list... shows the name and purpose of the current work queue. n items active or waiting... displays the number of work items currently in the queue, along with the highest number ever in the queue at one time. The time stamp is for the most-recent time when the queue had its highest number of work items. x items completed, y discarded is the number of completed and discarded items processed in this work queue. A completed item may have succeeded or failed. Items are discarded from the queue only when system resources are low and traffic is high, and the system only discards items that have waited a long time. A discard occurs before any thread begins executing the work item. Average... shows the average time that completed items spent waiting in the queue, and the average time that the volume software spent processing the work items after they were taken off of the queue. The times are measured in microseconds; there are 1,000,000 microseconds in 1 second. Time waiting in queue is a histogram showing various time amounts (0.001 second, 0.01 second, 0.1 second, and so on) and the number of work queue items that waited in the queue for that amount of time. The smallest time period is 0.001 seconds, which is 1 millisecond or 1,000 microseconds. This histogram only appears if at least one work item was in the queue since the last Reset time. Time processing on thread is a similar histogram, showing the time that threads spent processing the work-queue items after having taken them off the queue. Work-queue status messages, if any, appear after all of the work-queue tables. Each of these is a declaration that a work item was excessively slow, was slow long enough to be declared stuck, or eventually got done after being slow or stuck. Each event appears in its own row with the event type (SLOW, STUCK, or DONE), a time stamp for when the work item reached this state, the name of the work queue, the time spent working on the item, the name of the CIFS command sent to the data plane, and any other relevant information about the work item.
Guidelines: Processing-Time Table	Average processing time per operation type is a table of Server Message Blocks (SMBs, also known as CIFS Commands) processed through the above queues. These are commands that originate from ARX clients. You can use this table to determine if some client requests take longer than others. Reset... shows the last time these statistics were cleared. The software resets these statistics whenever someone issues the clear statistics cifs work-queues command or reboots the chassis. Under the Reset line, a table of SMBs appears. These are all the SMBs processed by the work queues since the Reset time. Each SMB appears in its own row with the following columns: CIFS SMB is the name of the SMB, Count is the number of these SMBs received from clients, Avg time (uSec) is the average number of microseconds (millionths of a second) required to fully process the request. This is the time in the work queue plus the time for the thread to process the work item. All SMBs shows the total count for all of the above SMBs, and the average time to process them.
Guidelines: Filer-RTT Table	Average file server round-trip time per operation type is another table of SMBs forwarded to back-end filers and servers. This table helps to determine if a filer or server is slow. Reset... shows the last time these statistics were cleared. The software resets these statistics whenever someone issues the clear statistics filer command or reboots the chassis. This is a different clear command than the one used for the other statistics. Under the Reset line, a table of SMBs appears. These are all the SMBs sent to the filers since the Reset time. Each SMB appears in its own row with the following columns: CIFS SMB is the name of the SMB, Count is the number of these SMBs sent to filers, RTT (uSec) is the average round-trip time (RTT) to and from the filer. All SMBs shows the total count for all of the above SMBs, and the overall average RTT for them. The next two rows show the total Response Timeouts and Network Errors, if any.
Guidelines: Authentication Table	Time spent in authentication shows the time spent with CIFS-client authentication. (For counters of various authentication tasks, you can use the show statistics cifs authentication command.) Reset... shows the last time these statistics were cleared. The software resets these statistics whenever someone issues the clear statistics cifs work-queues command or reboots the chassis. Under the Reset line, a separate sub table appears for each authentication type: Kerberos, Netlogon (NTLM/NTLMv2 for CIFS services that use constrained delegation (see domain-join)), or ARX Secure Agent (NTLM/NTLMv2 for CIFS services that use unconstrained delegation or no delegation). Kerberos service ticket requests focuses on Kerberos authentications. Total calls is the number of Kerberos tickets requested from the ARX-CIFS service. Elapsed time in call is a histogram showing various time amounts (0.001 second, 0.01 second, 0.1 second, and so on) and the number of service-ticket requests that took that amount of time. The smallest time period is 0.001 seconds, which is 1 millisecond or 1,000 microseconds. This histogram does not appear unless at least one client authenticated with Kerberos. Average time is the average time for all service-ticket requests. Netlogon requests shows the time taken for NTLM and NTLMv2 requests through Netlogon. These occur for a front-end CIFS service that uses constrained delegation. You choose the delegation type when you run domain-join for the CIFS service. Total calls is the number of Netlogon requests received by the ARX-CIFS service. Elapsed time in call is a histogram showing various time amounts (0.001 second, 0.01 second, 0.1 second, and so on) and the number of Netlogon requests that took that amount of time. The smallest time period is 0.001 seconds, which is 1 millisecond or 1,000 microseconds. This histogram does not appear unless at least one client authenticated with NTLM or NTLMv2 through a CIFS service with constrained delegation. Average time is the average time for all Netlogon requests. ARX Secure Agent requests shows the time taken for NTLM and NTLMv2 requests through the ARX Secure Agent (see ntlm-auth-server (gbl-ns)). These occur for a front-end CIFS service that uses unconstrained delegation or no delegation. You choose a delegation type when you run domain-join for the CIFS service. Total calls is the number of NTLM and NTLMv2 requests received by the unconstrained ARX-CIFS service. Elapsed time in call is a histogram showing various time amounts (0.001 second, 0.01 second, 0.1 second, and so on) and the number of NTLM + NTLMv2 requests that took that amount of time. The smallest time period is 0.001 seconds, which is 1 millisecond or 1,000 microseconds. This histogram does not appear unless at least one client authenticated with NTLM or NTLMv2 through a CIFS service with unconstrained delegation. Average time is the average time for all NTLM and NTLMv2 requests.
Guidelines: Authentication Table (Cont.)	Table of longest recorded round-trip times shows up to 20 clients who took the longest time for authentication. Each authentication session appears in one row of the table, with the following fields: Timestamp is the time that the client started the authentication process. Type is NL (Netlogon request), KRB (Kerberos ticket request), or ASA (ARX Secure Agent request). Time (uSec) is the time consumed by the authentication request, in microseconds. Principal Name identifies the CIFS client that invoked the authentication request. You can use show cifs-service user-sessions to see the clients that are currently connected to the ARX.
Sample	bstnA(cfg)# show statistics cifs work-queues volume-group 2 shows the work-queue statistics for volume group 2. See Figure 41.27 on page 41-62 for sample output.
Related Commands	clear statistics cifs work-queues clear statistics filer domain-join show cifs-service user-sessions show cifs-service client-activity show cifs-service open-files show cifs-service kerberos-tickets show statistics domain-controller show statistics cifs authentication show active-directory status

Purpose	Use the show statistics domain-controller command to view NTLM-usage statistics for a particular domain controller (DC).
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show statistics domain-controller ip-address   ip-address identifies a DC .
Guidelines	This command shows the statistics for communication with a particular DC. The statistics are divided into two categories: statistics for NTLM Netlogon authentications and statistics for LDAP pings. The NETLOGON statistics only apply to CIFS services that use constrained delegation, which is chosen when domain-join is performed for the service. If you use unconstrained delegation for your service, but still support NTLM or NTLMv2 for the services clients, use the show ntlm-auth-server command to find NTLM-authentication statistics. The LDAP-ping statistics in this command apply to any CIFS service, whether or not it uses constrained delegation. This command shows all the counters for this NTLM-related communication with a particular DC. You can use the clear statistics domain-controller command to clear these statistics. The statistics also clear after every chassis reboot.
Guidelines: Output	The output is divided into two tables: NTLM NETLOGON Authentication Statistics and LDAP Ping Statistics.
Guidelines: Netlogon Authentication Statistics	The NTLM NETLOGON Authentication Statistics table only applies to CIFS services that use constrained delegation, as explained above. The CIFS services that can use this DC are any that are in its Windows domain. An ARX CIFS service uses Netlogon service for NTLM and NTLMv2 authentication. Through the Netlogon protocol, each CIFS service sets up a secure channel with the DC. For each client that authenticates to the CIFS service with NTLM or NTLMv2, the service sends a clients username and password through that encrypted channel. If the password is correct, the DC returns the domain security identifiers (SIDs) and access rights for the user back through the secure channel. Domain Controller IP is the IP address you entered in the command. Last Reset time shows the last time these counters were cleared, either with a chassis reboot or with the clear statistics domain-controller command. All of the counters below started at this time. Successful NTLM and Successful NTLMv2 count the number of successful NTLM authentications at the selected DC.
Guidelines: Netlogon Authentication Statistics (Cont.)	Failed NTLM is a total number of NTLM failures at the DC. The counters below show the specific failures. No Such User counts the clients who used an unidentified username for the Windows domain. Bad Password is the number of failures due to an incorrect password for a valid username. Account Disabled shows the number of failures due to an administratively-disabled user account. No logon server counts the number of failures due to a service interruption. Each time, the ARX service was unable to reach the DCs Netlogon server. You can use show active-directory status to check the status of the DC connection, and you can set a preference for another DC in the same Windows Domain with forest-root ... preferred, child-domain ... preferred, or tree-domain ... preferred. Ntlm Blocked is the number of times the DC blocked NTLM access. This can be controlled at the DC with Local Security Policy; the specific Local Policy settings are Network Security:Restrict NTLM:policy-name. Other shows the number of failed authentications outside any of the above categories. Failed NTLMv2 is a total number of NTLMv2 failures at the DC. The counters below this summary field break down the specific failures, as described above. Schannel Inits are the number of times that the Secure Channel between the CIFS service an the DC has been re-initialized. Avg Request SRT (mSec), Min Request SRT (mSec), and Max Request SRT (mSec) show the average, minimum, and maximum round-trip times for NTLM authentications. This measures the elapsed time the Netlogon agent uses to process an authentication request. This is the processing time within the agent itself plus the communication time between the agent and the DC. The times are measured in milliseconds (there are 1,000 milliseconds in one second). Avg DC SRT (mSec), Min DC SRT (mSec), and Max DC SRT (mSec) show the average, minimum, and maximum round-trip times for NTLM authentications to this DC. This measures the round trips between the internal Netlogon Agent and the DC. These times are also measured in milliseconds.
Guidelines: LDAP Ping Statistics	The LDAP Ping Statistics table shows the results of periodic pings to the DC. The pings measure the ability to reach the DC as well as the latency of the DC connection: Each ping-statistics table contains the following information: Last Reset (Local Time) time shows the last time these counters were cleared with clear statistics domain-controller or a chassis reboot. All of the counters below started at this time. Total Count is the number of LDAP pings to the DC. Success Count and Error Count show the numbers of successful and failed pings. Average RTT (uSec) is the average round-trip time for LDAP pings. This is measured in microseconds. There are 1,000,000 microseconds in one second. RTT Histogram is a sub-table to display the numbers of pings in certain time ranges. Each row defines a time range in microseconds: 0 to 1000 microseconds, 1000 to 2000 microseconds, and so on. At the end of each row is the number of LDAP pings whose round-trip times where in this range.
Sample	bstnA(cfg)# show statistics domain-controller 192.168.25.102 shows NTLM statistics for the DC at 192.168.25.102. See Figure 41.28 for sample output.
Related Commands	clear statistics domain-controller show ntlm-auth-server

Purpose	Whenever a Windows domain is served by multiple domain controllers (DCs), the ARX rotates its queries between the active DCs in that group. Use the show statistics domain-controller load-balancing command to view the statistics for using these DCs. You can use this output to assess the usage of one DC over another.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show statistics domain-controller load-balancing
Guidelines	This command shows the statistics for communication with your DCs. You can use this output to compare the number of Kerberos requests to each DC. The output contains one table for every Windows Domain in the Active Directory. (You can use the active-directory update seed-domain command to discover all of the domains and DCs in the current Active Directory.) Each table contains one row per DC in that domain, with the following columns: DC IP Address identifies the DC. Kerberos Requests is the number of Kerberos requests sent to the DC since the last reboot, or since someone cleared the statistics with clear statistics domain-controller load-balancing. Preferred is either Yes or No. The ARX always directs its Kerberos requests to a preferred DC if any are reachable. DCs at the same AD site as the ARX are preferred by default. You can also use the child-domain, forest-root, or tree-domain command to manually set a DC preference. These statistics all restart at 0 (zero) after the ARX reboots. You can manually reset these statistics with the clear statistics domain-controller load-balancing command.
Sample	bstnA(cfg)# show statistics domain-controller load-balancing shows Kerberos-usage statistics for all DCs behind the bstnA ARX. See Figure 41.29 for sample output.
Related Commands	clear statistics domain-controller load-balancing

Purpose	A managed volume that supports filer-subshares keeps all of its subshare information in cache memory. This decreases the number of RPC calls between the ARX and its back-end filers during sync subshare operations. You can use this command to show the current contents of this cache.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer or crypto-officer
Syntax	show subshare-cache [filer ext-filer-name] [report prefix]   filer ext-filer-name (optional, 1-64 characters) focuses on a particular external filer. This is the name of the filer in the ARX configuration. For a list of configured external filers, use show external-filer. report prefix (optional, 1-64 characters) sends the subshare-cache output to a report instead of the screen. The CLI displays the full report name after you enter the command. The report is named as follows: prefix_yyyymmddHHMM.rpt, where prefix is chosen here and the rest of the filename is the current date and time.
Default(s)	None
Guidelines	A filer subshare is any CIFS share that is inside an imported CIFS share. A client who connects to a front-end subshare, if the subshares are configured as described in the filer-subshares documentation, is passed through the managed volume directly to a corresponding subshare on a back-end filer. The filer can then enforce its subshare ACL, as opposed to the top-level ACL of the imported share. Each front-end subshare (visible to your CIFS clients) maps to one or more back-end subshares. The state of every filer share (and share ACL) resides in a memory cache. You can use this command to show the cache, or the cache for one filer. You have the option to clear this cache for a filer where the ACLs and/or shares have changed since import. Use the clear subshare-cache command to clear the subshare cache.
Guidelines: Output	The output is a series of nested tables, one per back-end filer. Each filer has a table with the following heading: Subshare cache for filer ip-address Each filer table contains a separate table for each of its imported shares: Subshares nested below import share bulkstorage on filer ip-address is the heading for the first table. Each share contains its own sub table, with several fields to describe the share: Share is the name of the share in \\ip-address\share-name format. CIFS clients can use this path to access the storage. Path is the file-system path on the filer itself, including the drive letter. If you log into the filer, you can use this path to directly access the storage. Import is the name of the import share, the one that was imported into a managed volume. This is typically the container share for the current subshare. This says [This is the imported share.] for each top-level share. RelPath only appears for a subshare. This is the relative path to the subshare, starting from the root of the imported share. ACL is the Access Control List (ACL) for this share or subshare. This must match the ACL on all matching subshares. (A matching subshare is a subshare at the same relative path of another import share.) After all imported shares and subshares, each filer is re-iterated to show all of its un imported shares (called orphan shares): Orphan (unnested) share caches for filer ip-address is the heading for the second filer table. These are shares outside the imported share(s). Each of these shares contains a similar sub table with these fields: Share and. Path are described above. Remark only appears for special default shares. This is a note about a share, such as Default share for the root share on a disk drive or Remote Admin for the special ADMIN$ share. ACL is also described above.
Sample	bstnA# show subshare-cache shows the full subshare-cache. See Figure 41.30 on page 41-75 for sample output.   bstnA# show subshare-cache filer fs2 report fs2_sbshrs   Creating subshare-cache report: fs2_sbshrs_201004290537.rpt   shows the subshare-cache for the external filer named fs2, and sends it to a report.
Related Commands	filer-subshares sync subshares from-namespace sync subshares from-service clear subshare-cache