Manual Chapter :
Front-End Services
Applies To:
Show Versions
ARX
- 6.3.0
| An MMC user can share out storage from a remote CIFS filer, and MMC offers an opportunity to browse the filers volumes so that the user can choose one of them for sharing. The CIFS service does not support this browsing feature by default. Use the browsing command to enable this type of MMC browsing for one namespace behind the current CIFS service. Use no browsing to disallow this MMC browsing for one namespace (or all namespaces) behind the CIFS service. | |
| browsing namespace no browsing [namespace] namespace (1-30 characters) chooses a namespace behind this CIFS service. This makes the namespaces volumes visible to MMC clients who browse the namespaces volumes before choosing one for sharing. (In a multi-protocol namespace, the backing namespace might be established by an NFS export for the same global server.) | |
| You authorize a client by adding it to a Windows-management-authorization (WMA) group; use the windows-mgmt-auth command to create one such group. The show windows-mgmt-auth command shows all members and permissions for a group. Use the windows-mgmt-auth (gbl-ns) command to assign a WMA group to the backing namespace(s); you can use the command more than once to associate multiple groups with the namespace. All namespaces behind this CIFS service must have a matching set of WMA groups. Authorized WMA users can share the services backing volumes with MMC instead of the export (gbl-cifs) command. With browsing enabled, MMC clients have an added convenience: they can browse all of the namespaces volumes and share the one(s) they want. | |
| bstnA(gbl-cifs[ac1.medarch.org])# browsing medarcv bstnA(gbl-cifs[testSrvr])# no browsing demo2 | |
| Use the cifs command to instantiate a CIFS service for a global server. Use the no form of the command to delete a CIFS-service instance. | |
| cifs fqdn no cifs fqdn fqdn (1-128 characters) is the fully-qualified domain name (for example, myserver.organization.org) for an existing global server. Use show global server to see a list of global servers. | |
| This command prompts for confirmation before creating the CIFS service; enter yes to continue. (To prevent confirmations for creating these sorts of configuration objects, use the terminal expert command.) After you confirm, the CLI places you in gbl-cifs mode. From gbl-cifs mode, you must use the export (gbl-cifs) command to share at least one managed volume through CIFS. Use domain-join to register as a valid CIFS service with a Windows Domain Controller (DC). This creates a machine account in the Active Directory for the fqdn service, or uses an existing machine account if one already exists for fqdn. At a DC, an authorized administrator must raise the Trusted for Delegation flag for this service, and should also list the filers to which it can delegate; from priv-exec mode, you can use probe delegate-to to find all filers behind the CIFS service. You then use the enable (gbl-cifs, gbl-nfs) command to start the CIFS service. Finally, map the services fqdn to its VIP with the dynamic-dns command. Windows clients can then map their network drives to the volumes exported by the CIFS service. Each exported volume appears on the Windows network as one share on the CIFS services fqdn. To add additional service-principal names for this CIFS service, to which clients could also connect, use the active-directory alias command from gbl-gs-vs mode. Dynamic DNS names for a CIFS service are registered at external DCs, and all must be removed (with no dynamic-dns) before you can remove the CIFS service (with no cifs). | |
| The NetBIOS name for the CIFS service is tied to the virtual server. Each virtual server registers a NetBIOS name with its local WINS server. From gbl-gs-vs mode, use the wins command to identify the WINS server for a virtual server. From the same mode, you can optionally use wins-name to set the NetBIOS name for the virtual server and wins-alias to set additional aliases; by default, the NetBIOS name is the first part of the global servers FQDN (for example, \\ATHOS for the global server at athos.myco.com). | |
| There are several CLI commands for monitoring and managing client access to CIFS shares. The show cifs-service exports command shows the connection statistics for each CIFS share/export. Use show cifs-service user-sessions to find clients with open CIFS 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 (and locked against reads). The policy engine cannot migrate or copy a file in this state; use close cifs file to close one from the CLI. | |
| bstnA(gbl)# cifs www.mycompany.com bstnA(gbl)# no cifs www.defunctcompany.com | |
| Some Kerberos DCs have an option to assign a maximum age for their machine-account passwords. Each machine uses its secret password to authenticate with the AD domain. (An ARX-CIFS service is treated as a machine in this context.) If the secret password expires, the CIFS service cannot use Kerberos for client authentication. You can use the cifs rekey all command to refresh the secret password (or key) for every CIFS service on the ARX. | |
| all is required. If you rekey any CIFS service on the ARX, you rekey all of them at once. | |
| A CLI prompt warns you of the service outage; enter yes to continue with the rekey operation. If you proceed, the CLI lists all of the affected CIFS services. | |
| bstnA# cifs rekey all Proceed [yes/no] yes | |
| A CIFS service can use dynamic DNS to register its host name and/or aliases in DNS. When you remove a host name or change the VIP, the CIFS service attempts to remove the DNS entry. If the remove fails after several retries, the show dynamic-dns output keeps a record of the failed removal indefinitely, to remind you to remove the A record from the DNS server itself. Use the clear dynamic-dns command to clear all failed DNS removals from the system. | |
| The CLI prompts for confirmation before clearing all failed DNS-remove records from the ARX. Enter yes to proceed. The dynamic-dns command causes a CIFS service to add or remove DNS-host names from a local DNS server. The CIFS service retries every minute on failure; it retries add operations indefinitely, but eventually stops retrying for remove operations. These remove operations show up with Failed status in the show dynamic-dns output. Failed removals persist in the show output until someone clears them. Use the clear dynamic-dns command to clear all failed DNS removals from the system. | |
| bstnA# clear dynamic-dns | |
| The NFS Lock Manager (NLM) manages file locks for NFS clients. Use the clear nlm locks command to clear all locks for all clients, or for a given client machine. | |
| clear nlm locks {all | host-name} all | hostname is a required choice: all clears all locks for all NFS clients, system-wide. hostname (1-192 characters) clears all locks held by one clients host machine (for example, myhost). | |
| To see all the client machines that hold locks for a given file, use the show nlm file command. For a list locks held by a given client machine (or a list of all the client machines that have locks), use the show nlm client command. Use show nlm statistics to see statistics for all NLM activity. | |
| bstnA# clear nlm locks client18 | |
| Use the optional description command to set a descriptive string that appears as a comment in the Windows Network Neighborhood. Use the no form of the command to delete the description. | |
| description text text (1-48 characters) is your description. Surround the text with quotation marks () if it contains any spaces. | |
| bstnA(gbl-cifs[www.medarcv.com])# description archives for Longwood Ave | |
| Use the optional description command to set a descriptive string for the NFS service. This appears in the show command. Use the no form of the command to delete the description. | |
| description text text (1-255 characters) is your description. Surround the text with quotation marks () if it contains any spaces. | |
| bstnA(gbl-nfs[www.wwmed.com])# description mount point for wwmed storage | |
| Use the domain join command to register a CIFS front-end service with its Active-Directory (AD) domain. This is similar to adding client computers to the Active Directory domain, and it requires a sufficiently-privileged username and password. An administrator with stronger credentials can pre-create an account at the DC before you run this command, or the command can automatically enable delegation privileges at the DC. | |
| domain-join domain-name [ou organizational-unit] [delegation {constrained | unconstrained | none}] [timeout seconds] domain-name (1-256 characters) is the Windows domain to join. This domain must be the global servers domain, and it must be part of the Active-Directory forest configuration (see active-directory update seed-domain or active-directory-forest). The CIFS service registers with one of the DCs that manage this domain. organizational-unit (optional, 1-512 characters) is the Organizational Unit (OU) to which this service should be added. A Windows domain is divided into OUs for administrative convenience: each OU is a group of machines or accounts that are managed by a single administrator. Surround the OU name with quotation marks (); OU names often contain spaces. Use a slash (/) to separate each layer in a nested OU: for example, ou Virtual Services/pharmaceuticals is a valid nested OU. This is the reverse of the LDAP path shown on the Windows server, which would be .../cn=ac1,ou=pharmaceuticals,ou=Virtual Services,dc=medarch,dc=org. delegation {constrained | unconstrained | none} (optional) is unnecessary if the CIFS-service account already exists in the local AD. Omit this option if an AD administrator pre-created the machine account for this service. Otherwise, the ARX automatically generates the account on a DC that manages this domain. This option determines which Trust for delegation flag (if any) to be used for the CIFS service. The command enables this delegation at the DC if (and only if) you have sufficient privileges to do so: constrained is recommended, though it is only possible if the AD forest has a Domain Functional Level of Windows 2003 or later. This sets the Trust ... for delegation for specified services flag for the CIFS service. You (or an authorized administrator) can then access the DC and specify all of the back-end filers to whom this service can delegate. Once all the services filers are on its delegate-to list at the DC, clients can authenticate once and then access CIFS storage on all those filers. (You can use the probe delegate-to command to confirm that all of the filers behind the CIFS service are properly configured at the DC.) The DCs allow clients to use NTLM, NTLMv2, or Kerberos to authenticate; at the namespace(s) behind the CIFS service, you can use cifs authentication to support any or all of these authentication types. | |
| unconstrained only works for Kerberos authentication (by default). This sets the Trust ... for delegation to any service flag for this CIFS service. Clients cannot connect to any back-end storage with NTLM or NTLMv2 if this flag is raised at the DCs. To support NTLM authentication together with this option, you must install a Secure Agent at one of your DCs; see ntlm-auth-server. none does not trust this CIFS service for any delegation. This makes it impossible for Kerberos clients to authenticate to this service. (NTLM/NTLMv2 clients cannot authenticate either, unless you install a Secure Agent on your DCs and use the ntlm-auth-server command.) Use this when you do not have sufficiently strong Windows credentials to raise any Trust for delegation flag. This presumes that an authorized administrator will raise the appropriate Trust for delegation flag at a later time, thereby opening access to CIFS clients. seconds (optional, 1-300) sets a time limit for the domain-join operation. Use this in case the DC is too slow to respond before the command times out. | |
| organizational-unit, if omitted, defaults to Computers at the domains root. delegation, if omitted, is unconstrained. timeout seconds is 90 seconds | |
| To support CIFS-client authentication, the namespace(s) behind this CIFS service must have the desired authentication types enabled. Use the gbl-ns cifs authentication command to enable Kerberos, NTLM, and/or NTLMv2 for a namespace. Additionally, the Active-Directory forest must be accurately reflected in the switch configuration (see active-directory update seed-domain or active-directory-forest), and the global servers FQDN must be in one of the forests domains (the forest-root, a tree-domain, or a child-domain). You can use show active-directory to see all of the domains discovered in the AD forest. | |
| After you issue this command, the CLI prompts for a username and password. These are the credentials to be presented to the DC, called the domain-joiner credentials. In some sites, the domain-joiner credentials are sufficiently privileged to create a machine account on the DC and raise all of the proper flags. In other sites, a more-privileged user creates the machine account before the domain-joiner runs this command. These next subsections describe the minimal access privileges required to join the domain with either a new machine account or a pre-created account. | |
| If the domain-joiner has the following privileges, the domain-join operation can create a new machine account for the CIFS service. A pre-created machine account is unnecessary. | |
| We recommend Trust this computer for delegation to specified services only together with Use any authentication protocol. This is what the domain-join operation sets when it creates the account with the delegation constrained options. Do not use any delegation options with a pre-created machine account. The delegation is already set at the DC, as described above. | |
| If the CIFS service is already joined to the domain and you want to upgrade to constrained delegation, you can upgrade at the DC. From the DC, use the Active Directory Users and Computers interface to access the machine account for fqdn. (The machine account name is the first part of the fqdn: for example, the machine account name for ac1.medarch.org is ac1.) In the machine accounts properties, access the machine accounts Delegation tab and enter The CIFS service probes the DCs every few minutes to find these settings, so it may not be up-to-date right after you change them. You can use the sync cifs delegation command to update the CIFS service immediately. To verify success, wait for the DCs to synchronize with one another and then use the show cifs-service fqdn command to confirm the change. You can also use the probe delegate-to fqdn command to probe the DC and confirm that all the necessary filers are on the delegate to list. If any of these filers show up as failed on that list, enter those filers at the DC. | |
| Note: When you enter your filers at a Windows 2003 or 2008 DC, the following error may appear in a pop-up: The following Active Directory error occurred: The specified directory service attribute or value already exists. This indicates a software issue at the DC. Click OK to return to the Delegation tab, then check the Expanded box at the bottom. Look for duplicate SPNs in this expanded view; each filer should have only 2 SPNs, one with its FQDN and another with only its hostname. Remove all duplicate SPNs and then click Apply. | |
| Once this is done for all of your cifs services, you can remove all ARX Secure Agent applications from your DCs. When constrained delegation is active in all CIFS services, the Secure Agent applications are ignored. For more information about Secure Agent, see the ARX® Secure Agent Installation Guide. | |
| You can use the show cifs-service fqdn command to verify the success of the domain-join operation. This also shows the delegation type (constrained, unconstrained, or none) configured at the DC. If the service uses constrained delegation, this also lists the filers to which the service can delegate. The CIFS service probes the DCs every few minutes to update this information, so it may not be up-to-date right after you run the domain-join command. The probe delegate-to fqdn command verifies that all of the filers behind the fqdn service are properly listed at the DC. This verifies that the delegate to list is correct and complete on the DC. If not, copy all failed filers from the ARXs probe delegate-to output to the DCs delegate to list. | |
| Note: As described in the note above, an error may appear in a pop-up when you enter your filers at a Windows 2003 or 2008 DC. If the error appears, remove any duplicate filer SPNs (visible in the Expanded view) as described in the above note. | |
| If you use the delegate constrained option and properly configured the CIFS service at the DC, the service can support NTLM and Kerberos simultaneously. Each client negotiates the authentication protocol at the start of the CIFS session. The CIFS service uses Kerberos to authenticate with its back-end filers. If you use the delegate unconstrained option, NTLM and NTLMv2 authentication is not supported by default. In this case, you can install a Secure Agent on some of your DCs to allow NTLM and/or NTLMv2 authentication. Then use ntlm-auth-server to identify each of these DCs, and ntlm-auth-server (gbl-ns) to use them in the namespace(s) behind this CIFS service. (The show cifs-service fqdn command shows the namespace(s) behind the fqdn service.) In this case, if a client connects with NTLM or NTLMv2, the CIFS service uses one of the NTLM protocols (preferably NTLMv2) to connect to the back-end filers. All policy-initiated transactions with CIFS filers (such as file migrations) attempt to use Kerberos. The backing namespace negotiates the authentication method (Kerberos, NTLMv2, or NTLM) with each back-end filer. Kerberos requires that the backing namespace uses a proxy user configured with a full FQDN for its windows-domain (gbl-proxy-user). Kerberos also requires that it can discover the service-principal name (SPN) of each filer; you can use the show exports command to find if the filer allows for SPN discovery, or use spn to set the SPN manually. | |
| The domain-join operation involves the exchange of a shared password (or key). It is possible to set a maximum age for this type of machine-account key at the DC. If a maximum age is set at your site, you can later use the cifs rekey command to reset the CIFS services key before it expires. This makes the CIFS service automatically restart, so it causes a brief service outage. You can also use the at command to reset the machine-account key on a regular schedule. | |
| bstnA(gbl-cifs[ac1.medarch.org])# domain-join MEDARCH.ORG Username: jsmith Password: jspasswd stkbrgA(gbl-cifs[bgh.medarch.org])# domain-join MEDARCH.ORG Username: Administrator Password: adminpasswd | |
| cifs authentication kerberos | |
| Kerberos authentication requires up-to-date DNS records for every front-end CIFS service. Use the dynamic-dns command to register a host name or DNS alias for the current CIFS service. Use the no form of the command to withdraw an alias from the local DNS database. | |||||
| dynamic-dns alias no dynamic-dns alias alias (1-255 characters) is an alias for this CIFS service. This can be a simple host name (for example, myserver) or an FQDN (for example, myserver.mycompany.com). If it is a simple host name, the CIFS service appends the services Windows domain (set with windows-domain (gbl-gs)) before registering the name. If it is an FQDN, it must match that Windows domain or the CLI rejects it. Use show global server to see the Windows domain for the CIFS service (the Windows domain is set at the global server for the service). | |||||
| Before you use this command, you must configure at least one DNS server for this services Windows domain. You can do this as part of setting up the Active-Directory (AD) forest; use the gbl-forest name-server command to identify the name server for the services domain. The Windows domain for this CIFS service is set in the services global server. Use show global server to see the Windows domain. You must also join an Active-Directory domain with domain-join. Finally, the CIFS service must be enabled (with enable (gbl-cifs, gbl-nfs)) before you issue this command. This command immediately registers an address (A) record with one of the configured name servers. The A record maps the services virtual-IP (VIP) address to the alias you set in this command. (Use the virtual server command to set the VIP.) You can repeat this command to map multiple aliases to the VIP, so that clients can connect through multiple service names. All clients that connect through these names can use Kerberos authentication. The CIFS service renews the A record registration at 1:00 AM (local time) each morning. It adds and or withdraws A records whenever the global servers VIP changes (with [no] virtual server) or the CIFS service is removed (with no cifs). Use the priv-exec dynamic-dns update command to update all A records immediately. The no dynamic-dns command causes the CIFS service to remove the A record from DNS. As with the affirmative syntax, you must issue the command while the CIFS service is enabled. The show dynamic-dns command shows the dynamic-DNS configuration as well as the current status of all host-name registrations. | |||||
| If the CIFS service has more valid hostnames than its FQDN, each additional hostname is a DNS alias. Each DNS alias must be established externally, in the Active Directory. The domain-join command registers its CIFS-service FQDN at the Active-Directory (AD) domain; if a client connects to the service using a DNS alias, the local Domain Controller (DC) must be able to translate the alias into the registered FQDN. Otherwise, Kerberos authentication fails. From gbl-gs-vs (virtual server) mode, you can use the active-directory alias command to set a DNS alias for the CIFS services global server. This registers the alias in the external Active Directory. Follow these instructions to reach gbl-gs-vs mode for the correct virtual server:
| |||||
| bstnA(gbl-cifs[sales.myco.com])# dynamic-dns sales bstnA(gbl-cifs[sales.myco.com])# dynamic-dns fs5.myco.com bstnA(gbl-cifs[fs.myorg.org])# no dynamic-dns betafs | |||||
| Kerberos authentication requires up-to-date DNS records for every front-end CIFS service. If you use dynamic-dns for the current CIFS service, the CIFS service automatically updates its DNS server daily, or whenever a configuration change necessitates a change in DNS configuration. If you require an immediate update to your DNS server(s), use the dynamic-dns update command. | |
| dynamic-dns update [fqdn] fqdn (optional, 1-128 characters) identifies a single CIFS service for the update. If you omit this, all CIFS services send DNS updates to their local name servers. | |
| You can register a new host name or DNS alias with the dynamic-dns command. This command sends an immediate update for all such host names. Under most circumstances, the update is redundant; the CIFS service sends updates daily, and sends changes whenever a VIP changes, a host name is removed, or some other IP/name change occurs. You can use this command to force an update if, for example, your external DNS servers have returned from an extended outage. The show dynamic-dns command shows the dynamic-DNS configuration as well as the current status of all host-name registrations. | |
| bstnA# dynamic-dns update as1.medarch.org bstnA# dynamic-dns update bstnA# ... | |
| Use the enable command to activate the current CIFS or NFS service. Use the no form of the command to stop the current CIFS or NFS service. | |
| The enable command makes all declared CIFS shares or NFS exports available to clients. Clients can access the share through the virtual-IP (VIP) address of the global servers virtual server. The CIFS service does not send any dynamic-dns updates unless it is enabled. | |
| bstnA(gbl-nfs[www.wwmed.com])# no enable | |
| Use the export command to share a namespaces managed volume through CIFS. Use the no form of the command to stop sharing a managed volume. | |||||||||
| no export namespace vol-path no export as share-name namespace (1-30 characters) can be any namespace that supports CIFS. If the same CIFS service exports more than one namespace, all of the namespaces behind the service must have matching CIFS settings; see Guidelines: Exporting from Multiple Namespaces, below. vol-path (1-1024 characters) is the path to one of the namespaces managed volumes (for example, /multimedia) or inside the volume (/multimedia/data/apps). as share-name (optional; 1-1024 characters) sets an advertised path to the volume. If entered, CIFS clients see this path as an available export instead of the volume path. You can re-enter the command to share the volume under more than one share name. description description (optional; 1-64 characters) sets a description for this share. This appears as a comment in Windows network browsers such as Network Neighborhood and the net view command. Surround the text with quotation marks () if it contains any spaces. | |||||||||
| no export namespace vol-path no export as subshare-name is the syntax for exporting a filer subshare. A filer subshare is a CIFS share inside the volumes directory tree, below the root. At the back-end filer(s), a subshare often has a different share-level ACL than the root share. namespace and vol-path are described above. The vol-path must be a valid path in a managed volume with filer-subshares enabled. as subshare-name (optional; 1-1024 characters) is required for filer subshares. This is the name of the subshare for vol-path (for example, MYSHARE). If the CIFS service is enabled, this subshare is replicated on all back-end shares behind vol-path. This replicates the subshares directory path, ACL, and attributes from the master directory to all other back-end shares. You can use the find command to find a directorys master directory. This replication operation is equivalent to running sync subshares from-service. filer-subshare is also required for filer subshares. | |||||||||
| hidden (optional) tells the CIFS service to find a hidden version of the subshare-name behind the volume, and expose it to front-end clients. The hidden subshare has a dollar-sign at the end of its name (such as hidden_share$). With this option, the CIFS service exposes the subshare by exporting it without the $ suffix. description description (optional; 1-64 characters) sets a description for this subshare, as explained above. | |||||||||
| share-name defaults to the volume path without the leading slash (/), all in uppercase. For example, the /var volume would default to the share name, VAR. subshare-name has no default. description defaults to an empty string. | |||||||||
| You must enable the CIFS service for any shares to be visible to clients. Use the enable (gbl-cifs, gbl-nfs) command in gbl-cifs mode to enable CIFS service. | |||||||||
| A new CIFS front-end share often requires some configuration at a local Domain Controller (DC). Best practices dictate that a CIFS service is trusted to delegate CIFS connections to all of the filers behind it, and it is not trusted to delegate CIFS to any other filer. This is called constrained delegation. The DCs manage the CIFS services ability to delegate, as well as the back-end filers to whom it can delegate. An authorized Windows administrator must therefore go to a DC and add this new volumes filers to its CIFS services delegate to list. After you export the volume, you can use probe delegate-to fqdn to check the DC(s) and determine whether or not delegation is properly configured for the new filers. If not, a properly authorized administrator must access the DC and add the new filer(s) to the CIFS services delegate to list. Every new filer must be joined to the same Windows Domain as the CIFS service, and it must support Kerberos authentication. The show cifs-service fqdn command shows the domain to which the fqdn service is joined. | |||||||||
| Filer subshares are defined at back-end filers, along with all of their share-level ACLs. If you support subshares in the CIFS service, a client that connects to the subshare on the front end passes through to the corresponding subshare at the back-end; the share-level ACL is enforced there. Before using the filer-subshares syntax, you must prepare the volume with the filer-subshares command. Without the subshare preparation at both the CIFS service and the volume, a client always connects to the root of the back-end share, even after connecting to a lower-level share at the front-end. You can use the show cifs-service subshares command to view all filer subshares corresponding to each front-end subshare. As an alternative to export ... filer-subshares, you can use sync subshares from-namespace to export all back-end subshares at once. | |||||||||
When you use the export command to share a volume from a new namespace, the ARX software confirms that the new namespace is consistent with all currently-exported namespaces. If any of the above options do not match, the CLI offers the opportunity to synchronize the namespace settings. Enter yes to proceed. This provides all backing namespaces with the same superset of options; for example, if one namespace supported Kerberos and the other supported Kerberos and NTLM, the synchronization process would configure all namespaces to have both Kerberos and NTLM. | |||||||||
| bstnA(gbl-cifs[www.medarcv.com])# export medarcv /rcrds description clerical records bstnA(gbl-cifs[www.myco.com])# export homes /lhome as HOMEDIRS bstnA(gbl-cifs[www.myco.com])# export homes /lhome as ALLSHARES bstnA(gbl-cifs[www.myco.com])# no export as ALLSHARES bstnA(gbl-cifs[www.medarcv.com])# no export medarcv /schedules bstnA(gbl-cifs[www.medarcv.com])# export medarcv /rcrds/2004 as Y2004 filer-subshare bstnA(gbl-cifs[www.medarcv.com])# export medarcv /rcrds/VIP_wing as CELEBS filer-subshare hidden | |||||||||
| Use the export command to export a namespace volume through NFS. Use the no form of the command to stop exporting a volume. | |
| no export namespace vol-path namespace (1-30 characters) can be any namespace that supports NFS. If the same NFS service exports more than one namespace, all of the namespaces behind the service must have the same character-encoding nfs settings. vol-path (1-1024 characters) is the path to one of the namespaces managed volumes (for example, /var) or inside the volume (/var/log/archive). as export-path (optional, 1-1024 characters) sets an advertised path to the NFS-share mount point. If entered, NFS clients see this path as an available export or share instead of the volume path. You cannot export the same vol-path under more than one name; you can only use this option to change the export path that is visible to clients. access-list name (optional, 1-64 characters) is the access list to associate with this share.Use the show nfs-access-list command to view the configured access lists. | |
| access-list name, if omitted, defaults to allowing all clients access to the volume/share with read/write permission, root-squash enabled, and root squashed to UID 65534 and GID 65534. | |
| This command exports a volume from any namespace. Clients can mount this volume through NFS by accessing the virtual-IP (VIP) address of the global servers virtual server. You must enable the NFS service for any shares to be visible to clients. Use the enable (gbl-cifs, gbl-nfs) command in gbl-nfs mode to enable NFS service. If you export volumes from more than one namespace, the character-encoding nfs settings must match in all namespaces: Before you remove a volume with no export, you must first disable it using the no enable command in gbl-nfs mode (see enable (gbl-cifs, gbl-nfs)). | |
| If any filer goes offline behind this export, a client cannot access its files or directories. The NFS service could return an access error to the client (typically preferred by human users), or the service could let the client retry until the filer answers (often preferred by scripted clients). You can use the offline-behavior command to choose the behavior of this export when a back-end filer goes offline. You can define a default behavior for the entire NFS service, and you can redefine the behavior for each export. | |
| bstnA(gbl-nfs[ac1.medarch.org])# export wwmed /acct | |
| When a Windows client uses offline access for a file on a remote CIFS share, Windows creates a local copy of the file for the client. The client can use that local copy whenever the client machine is disconnected from the CIFS share, and can later sync the local copy with the original whenever the CIFS-share connection is up. By default, clients can manually select directories and files for offline access. You can use the export offline-access command to also automatically enable offline access for any file the client opens (with or without network optimization), or to disable all offline access. Use the no form of the command to revert to the default setting. | |
| export offline-access share-name {manual|auto|auto-local|none} no export offline-access share-name share-name (1-1024 characters) is the name of a share or subshare from this CIFS service, established with the export (gbl-cifs) command. You can use show cifs-service fqdn for a list of all shares and subshares in the fqdn service. manual | auto | auto-local | none is a required choice. This maps to the offline settings in the MMC interface for managing CIFS shares. Use this command in place of those options: manual means that clients must set the option for offline files and directories themselves. This maps to the MMC option (in Windows 7), Only the files and programs that users specify are offline. auto indicates that client software is allowed to automatically enable offline access for every file the client opens. Client software is also allowed to automatically sync its local files with the files on the CIFS share whenever the connection is up. This can produce a great deal of network traffic between clients, the ARX, and the back-end filers behind this CIFS share. It maps to the Windows 7 MMC option, All files and programs that users open from the shared folder are automatically available offline. auto-local extends the auto feature. This maps to the same MMC option above together with an additional Optimized for performance option. This permits the client software to reduce its network usage by downloading all executable files immediately after connecting. For newer Windows clients, this is equivalent to the auto feature. none means that the client software is not permitted to offer any offline-access options to the client. This maps to the MMC option, No files or programs from the shared folder are available offline. | |
| Both of the auto options have the potential for creating high network traffic, since they ensure that every opened file is locally cached, and they sync local files whenever possible. The CLI prints an informational message about this if you choose either of those options. Use these options only on the advice of F5 Support. | |
| stkbrgA(gbl-cifs[bgh.medarch.org])# export offline-access naumkeag auto-local bstnA(gbl-cifs[ac1.medarcv.com])# export offline-access ARCHIVES none | |
| Use the nfs command to instantiate an NFS service for a global server. Use the no form of the command to delete an instance of NFS service. | |
| nfs fqdn no nfs fqdn fqdn (1-128 characters) is the fully-qualified domain name (for example, www.organization.org) for an existing global server. Use show global server to see a list of global servers. | |
| This command prompts for confirmation before creating the NFS service; enter yes to continue. (To prevent confirmations for creating these sorts of configuration objects, use the terminal expert command.) This places you in gbl-nfs mode. You must use the export (gbl-nfs) command to export at least one ARX volume through NFS. Optionally (while the service is disabled), you can use no nlm enable to disable the NFS Lock Manager (NLM) service. Once you have at least one export, you must use the enable (gbl-cifs, gbl-nfs) command to start the NFS service. Clients can then mount the export(s) through the global servers virtual-IP (VIP) address (created with the virtual server command). If any filer goes offline behind this service, a client cannot access its files or directories. The service could return an access error to the client (typically preferred by human users), or the service could let the client retry until the filer answers (often preferred by scripted clients). You can use the offline-behavior command to choose the behavior of this service when a back-end filer goes offline. You can also use the command to customize the behavior for various NFS exports. The ARX-500 supports a maximum of 16 front-end services, and the other platforms support up to 64. This limit applies to the sum of all NFS services (created by this command) and CIFS services (created with the cifs command). You can use show nfs-service to show the configuration of an NFS service. The show nfs-service mounts command shows all clients who are mounted to an NFS service. | |
| bstnA(gbl)# nfs www.mycompany.com bstnA(gbl)# no nfs www.defunctcompany.com | |
| Use the no form of this command to go back to the default timeout and behavior. | |
| nfs tcp timeout seconds seconds (5-104) is the new timeout period. | |
| This command sets the timeout and behavior for all NFS services and filers. Use the show nfs tcp command to show the current timeout period and behavior. | |
| bstnA(gbl)# nfs tcp timeout 90 bstnA(gbl)# no nfs tcp timeout | |
| The NFS Lock Manager (NLM) manages file locks for NFS clients. While the NFS service is disabled, you can use the no nlm enable command to disable NLM. Use the affirmative command, nlm enable, to enable NLM for this NFS service. | |
| The current NFS service must be disabled (through no enable (gbl-cifs, gbl-nfs)) for this command to function. The CLI prompts for confirmation before stopping NLM; enter yes to proceed. It is often appropriate to disable NLM for a direct volume, where clients are allowed to access back-end files without going through the ARX. Each volume manages its own set of NLM locks, unknown to any of the filers behind the volume. If any client accesses a file by going directly to the filer, the filer is unaware of any NLM locks that the volume may have granted. This is also true if a client accesses the same file through another direct volume. In either case, the volume behind this NFS service is incapable of enforcing its NLM locks. | |
| To see all the client machines that hold locks for a given file, use the show nlm file command. For a list of locks held by a given client machine (or a list of all the client machines that have locks), use the show nlm client command. If a client machine is down, you can clear all of its locks with clear nlm locks. Use show nlm statistics to see statistics for all NLM activity. | |
| bstnA(gbl-nfs[acopiaFiler])# no nlm enable bstnA(gbl-nfs[myserver.com])# nlm enable | |
| When an NFS client attempts to access a file on an offline filer, the ARX-NFS service ignores the request and lets the client retry; this can block the NFS client for a long time. Use the offline-behavior ... deny-access command to immediately return an access error (typically NFSERR_ACCES or NFS3ERR_ACCES) instead. This provides a definitive answer to NFS-client software, so that it can return an error for an offline file and immediately move on to other file requests. To silently wait for a client retry instead of returning an access error, use the offline-behavior ... retry command. This setting prevents sparse returns (a mixture of available files and access errors) for multi-file requests. Use the no offline-behavior command to revert to the inherited offline behavior for the entire NFS service, one namespace behind the service, one volume behind it, or one particular export from one of its volumes. | |
| ns (optional, 1-30 characters) narrows the scope of this command to a particular namespace behind this NFS service. /vol (optional if you choose namespace, 1-1024 characters) narrows the scope further, to a particular volume in the above namespace. expt-path (optional, if you choose a volume, 1-64 characters) narrows the scope to one explicitly-exported path in the volume. You must choose an export path that is explicitly exported with the export (gbl-nfs) command. The command is accepted, but the NFS service does not honor the offline behavior until someone exports this exact path. retry | deny-access is a required choice: retry causes the service to accept requests to offline filers without sending an error back to the NFS client. The client must therefore retry until the filer comes back online, or until the client software times out. This causes NFS requests to hang if they involve a mix of online and offline filers. deny-access causes the service to return an error (typically NFSERR_ACCES or NFS3ERR_ACCES) for any client request that requires an offline filer. An NFS request succeeds (with some access errors) if it accesses both online and offline filers. no offline-behavior reverts to the behavior inherited from the parent path, volume, namespace, or NFS service. Inheritance is explained below. | |
| At the NFS-service level, this is equivalent to offline-behavior retry. | |
| For example, suppose an NFS client mounts an ARX export with one offline filer and runs the Unix ls -l command. If the export is configured to deny-access for offline files, the user would see access errors in place of the offline files (two of them, in this case), along with full information for all of the accessible files: juser@client2:/mnt/arx$ ls -l For an ARX export that waits for the client to retry, the above command would hang until the back-end filer came back online or the ls command timed out. | |
| For volumes where an NFS client desires access to some filers whether or not other filers are available, we recommend the deny-access behavior. This behavior always allows NFS access to filers that are online, even for directories that are partially hosted by an offline filer. This can be useful in tiered volumes where files on the lower-tier filers are rarely accessed. | |
| The offline behavior setting is only useful if there is an export (gbl-nfs) for the exact path named in the offline-behavior command. The above examples would be ineffective until someone also issued both of the following export commands: If /usr/local/bin was exported but not /usr/local/bin/auto-drop/, an NFS client that mounts /usr/local/bin/auto-drop would get the offline behavior for /usr/local/bin, deny access. You can use the show nfs-service ... detailed command to confirm that all of your offline behavior settings are assigned to at least one NFS export. | |
| bstnA(gbl-nfs[ac1.medarch.org])# offline-behavior deny-access bstnA(gbl-nfs[ac1.medarch.org])# offline-behavior namespace wwmed volume /acct path /wksheets retry overrides this default behavior for clients that connect to the /acct/wksheets export. The warning indicates that the export does not yet exist, so NFS clients that mount /acct/wksheets still get the access errors for offline filers. You can use the export (gbl-nfs) command to create the /acct/wksheets export later, and that export would then get the retry behavior. bstnA(gbl-nfs[ac1.medarch.org])# offline-behavior namespace insur retry | |
| A front-end CIFS service can delegate CIFS to the filers behind it. A CIFS client can then authenticate once and access any of the services back-end filers without re-authenticating. This single-authentication mechanism, facilitated by constrained delegation, requires some configuration at the local DC. After the CIFS service joins its domain using constrained delegation (with domain-join), you must go to the DC and inform it of the filers to which the CIFS service can delegate. This command lists all of the filers behind a given CIFS service, along with their current delegation status. You can use this list to confirm that all filers are correctly set at the DC. | |
| fqdn (1-128 characters) is the fully-qualified domain name for a CIFS service (for example, www.organization.org). user user-name domain domain-name (optional) is a Windows-user identity for the probe operation. The CLI uses this Windows identity to test whether or not the CIFS service can delegate to each back-end filer. If you omit this, the CLI uses the proxy-user (gbl-ns) from one of the namespaces behind the CIFS service. user-name and domain-name each take1-128 characters. | |
| This command is only relevant for a CIFS service with constrained delegation. You set up constrained delegation at a DC or with the domain-join command. A background query runs every 10 minutes to confirm that the service has constrained delegation; this command does not function until that query runs successfully at least once. You can use this command to find all of the filers behind a given CIFS service. At the DC, you can apply each of these filers in the Delegation list for the CIFS service: select the Trust ... for delegation for specified services and the Use any authentication protocol flags, then add the filers to the list of services. The CIFS service must be allowed to delegate to all of these filers so that its clients can authenticate to them. The client-authentication mechanism can then be any combination of NTLM, NTLMv2, and Kerberos. | |
| External-Filer is the name of the back-end filer. You can use the show external-filer command to list all external filers on the ARX. Filer SPN is the service-principal name (SPN) of the back-end filer. This is the SPN that the ARX discovered, or the one that was set with the spn command. The next two SPNs are both expected to be on the CIFS services Delegation list, at the DC. Probe SPN-1 is another service-principal name (SPN) for the back-end filer. This is the exact text of a SPN that someone must enter at the DC. After the SPN is the status of that SPN on the DC: OK means that the DC allows the front-end CIFS service to delegate to this SPN. If Probe SPN-1 and Probe SPN-2 both have this status, the filer is properly entered in the CIFS services Delegation (or delegate-to) list. Failed (Not in delegate-to list) means that the front-end CIFS service cannot delegate to this filer. Go to one of the DCs for the services domain and add this filer to the Delegate list for the CIFS service. Use the full filer name from this Probe SPN field. Configure the CIFS service to delegate cifs to the filer. Failed (Filer spn is not configured nor discovered) indicates that the filers service principal name (SPN) is unknown. You can use show exports to automatically discover a filers SPN, or spn to manually set it. Failed (Filer not in the same domain) means that the back-end filer is not joined to the same domain as the CIFS service. The CIFS service belongs to the Windows domain of its backing namespace(s): use show cifs-service cifs-service to find this Windows domain for a given cifs-service. The filer must be joined to the same Windows Domain for constrained delegation to function. Probe SPN-2 is the exact text of a second SPN that should be on the CIFS services Delegation (or delegate-to) list. As above, the SPNs status appears after the SPN. If either SPN fails, address the issue as described above. | |
| bstnA# probe delegate-to ac1.medarch.org user juser domain MEDARCH.ORG uses an identity of juser@MEDARCH.ORG to test the CIFS delegation for the insur.medarch.org service. See Figure 24.1 on page 24-41 for sample output. In this case, neither of the services back-end filers are on its Delegation list, so the administrator must go to a local DC to add them. stoweA# probe delegate-to patrol.MEDARCH.ORG tests the delegation status for the patrol.MEDARCH.ORG service. This uses the credentials defined for the proxy-user in one of the services backing namespaces; those credentials appear at the top of the output. For sample output, see Figure 24.2 on page 24-41. This service is properly configured at the DCs. | |
bstnA# probe delegate-to ac1.MEDARCH.ORG user juser domain MEDARCH.ORG
stoweA# probe delegate-to patrol.MEDARCH.ORG
| Use the remove namespace ... volume ... exports-only command to remove all of a volumes front-end exports. | |
| name (1-30 characters) identifies the namespace. volume (optional, 1-1024 characters) focuses on a single volume. exports-only removes all front-end exports (created with export (gbl-nfs) and/or export (gbl-cifs)) for the specified volume. The volume and namespace configurations remain. seconds (optional, 300-10,000) sets a time limit for each component operation in the removal process. sync (optional) shows its progress at the command line. With this option, the CLI prompt does not return until all components have been removed. | |
| By default, this command generates a report to show all of the actions it takes to remove the volume(s), in order. The CLI shows the report name after you issue the command, and then returns. You can enter CLI commands as the namespace software removes the exports in the background. 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. Use the sync option to send the status to the command line instead; the command does not generate a report if you use the sync option. Use remove namespace to remove an entire namespace or volume, or remove service to remove an entire namespace and all configuration objects that are dedicated to the namespace (including the front-end exports). To remove a share from a volume, use remove-share migrate or remove-share nomigrate. | |
| prtlndA# remove namespace insur_bkup volume /insurShdw exports-only | |
| Use the show cifs-service command to display configuration information about front-end CIFS service(s). | |||||||||||||||
| show cifs-service [{ fqdn | all } [detailed]] fqdn (optional; 1-128 characters) is the fully-qualified domain name for one CIFS service (for example, www.organization.org). all (optional) shows summaries of all CIFS-service offerings. detailed (optional) adds CIFS-share details to the output. | |||||||||||||||
| The default output is a table of all CIFS services, one service per row, with the following columns: Service Name is the FQDN that identifies the CIFS service. The cifs command, which instantiates the CIFS service, establishes this FQDN. It is the same as the FQDN for the global server where this service runs. Description is set by the description (gbl-cifs) command. | |||||||||||||||
| If you focus on a single CIFS service, more details appear. Several of these fields are updated by a background query to the DCs. This background query runs every 10 minutes, so you cannot immediately see the results of a domain-join operation: Service Name is described above. Domain Join shows whether or not the CIFS service has performed a successful domain-join operation.
This field is updated by the DC query mentioned above. It can take up to 10 minutes after a domain-join for this output to show the results of the operation. Account Name the name that was used for the machine account at the local DCs. This is typically the hostname part of the CIFS-service FQDN followed by a $ symbol; for example, insur$ could be the account name for the insur.medarch.com service. If that hostname exceeds 15 bytes, this is the first 15 bytes of the hostname followed by a $ (for example, the account name for reallylonghostname.myorg.org would be reallylonghostn$). As above, this field is updated by a DC query that runs every 10 minutes. Delegation is the machine accounts setting for the Trust for delegation flag at the DCs. This determines whether or not the DCs trust the CIFS service to delegate CIFS access to its filers.
Delegate To shows a list of filers to whom the CIFS service is allowed to delegate. This is Not Applicable until someone performs a successful domain-join for the CIFS service. This list is only relevant if the Delegation type (above) is Constrained. Each filer appears on a separate line, in the format cifs/filer-name. The cifs/ string indicates that the service can delegate CIFS to the filer; if another service type appears here, the line is irrelevant. If no filers appear here and the Delegation is Constrained, an administrator with sufficient credentials must access the services computer account at a local DC and add them. The DCs must trust the CIFS service to delegate CIFS to all the filers behind it. You can use probe delegate-to to get a complete list of the CIFS filers behind the CIFS service. As above, this field is updated by a DC query that runs every 10 minutes. | |||||||||||||||
| Description, is described for the summary output, above. State is Enabled or Disabled, as set by the enable (gbl-cifs, gbl-nfs) command. Signatures describes this services setting for SMB signing, a CIFS security feature. This is Enabled (use SMB signing if and only if the client requires it), Required (only allow connections from clients that agree to use SMB signing), or Not Enabled (only allow connections from clients that do not require SMB signing). You can change this with the signatures command. WINS Name Encoding is the character-encoding method used for the services WINS-name registration. If the service uses WINS for name resolution, this is the character encoding used to send the CIFS services name to the WINS server. You can use the wins-name-encoding command to change this. Exports for Namespace: ns-name identifies one namespace behind this CIFS service. The export (gbl-cifs) command establishes a namespace for the service. Share Name is the name that is advertised to clients. S appears for subshares of an imported share. To configure a subshare for this service, use the filer-subshare argument in the export (gbl-cifs) command, or use sync subshares from-namespace. Volume Path is the directory path that is being shared, set by the export (gbl-cifs) command. State describes the state of the volume behind this share:
Degraded (at the end of the row) only appears for a CIFS subshare. This indicates that the filer subshares behind this client-visible subshare are not replicated properly. All of the filer subshares must have the same name (or a special name generated by the ARX), the same directory path (relative to the root of each filer share), and the same ACL. If this flag appears for any subshare, the CLI provides a prompt at the bottom suggesting that you use sync subshares from-service ... tentative to get details about the problem. | |||||||||||||||
| Namespace is the ARX namespace that holds the shares storage. Volume Path is the ARX volume in the above namespace. Description is set by an option in the export (gbl-cifs) command. Export state describes the state of the client-side export. This often depends on the results of the subshare-replication process that occurs during managed-volume import. If the backing volume contains any CIFS subshares, the volume must replicate all subshare definitions on all of its filers:
Path State is the same as the State field in the summary output, described above. Filer-subshare is Yes or No, depending on whether or not the share is implemented as a subshare. To create a subshare, use the filer-subshare argument in the export (gbl-cifs) command, or use sync subshares from-namespace to export all subshares from a particular backing volume. Offline-access shows the type of offline access allowed to the shares clients. Clients can use this feature to make a local copy of a file on this share, edit the copy while disconnected from the share, then sync the copy with the original on the share once the connection is re-established. This shows the value set by the export offline-access command on the current share. | |||||||||||||||
| bstnA> show cifs-service lists all global servers (by their FQDNs) configured with a CIFS front-end service. See Figure 24.3 on page 24-48 for sample output. bstnA> show cifs-service ac1.medarch.org shows a summary for the CIFS service running at ac1.medarch.org. For sample output, see Figure 24.4 on page 24-48. bstnA> show cifs-service all shows summaries for all the front-end CIFS services on the bstnA chassis. See Figure 24.5 on page 24-49 for sample output. stoweA> show cifs-service patrol.MEDARCH.ORG detailed | |||||||||||||||
Figure 24.3 Sample Output: show cifs-service
bstnA> show cifs-service
Figure 24.4 Sample Output: show cifs-service ac1.medarch.org
bstnA> show cifs-service ac1.medarch.org
Figure 24.5 Sample Output: show cifs-service all
bstnA> show cifs-service all
Figure 24.6 Sample Output: show cifs-service ... detailed
stoweA> show cifs-service patrol.MEDARCH.ORG detailed
| A subshare is a CIFS share of another CIFS shares subdirectory. You can configure a volume to pass CIFS clients from a front-end subshare directly to the corresponding subshare on the back-end, therefore applying the correct share-level ACL for the clients access. Use the show cifs-service subshare command to show the mapping of front-end subshares to their corresponding back-end subshares. | |||||||||||||
| show cifs-service subshares {fqdn|all} [detailed] [state {ready | degraded | idle | pending | nsmwait}] fqdn|all chooses one (or all) CIFS services: fqdn (1-128 characters) is the fully-qualified domain name for one CIFS service (for example, www.mycharity.org). all shows the subshares in all CIFS services. detailed (optional) expands the output to show details for each subshare. state {ready | degraded | idle | pending | nsmwait} (optional) filters the output so that it shows only the subshares in the specified state. The Guidelines below explain each of these states in detail. | |||||||||||||
| Service is the FQDN that identifies the CIFS service. The cifs command, which instantiates the CIFS service, establishes this FQDN. It is the same as the FQDN for the global server where this service runs. Export is the name of the front-end subshare, seen by clients of the CIFS service. The export (gbl-cifs) ... filer-subshare command establishes this name. Filer is the name of an external filer that hosts a back-end subshare. This is the external-filer name defined in the ARX configuration; use show external-filer to see a full list of external filers. Share is the name of the parent share at the back-end filer. Subshare is the name of the subshare at the back-end filer. Some subshares that are automatically generated by the ARX (with filer-subshares, sync subshares from-namespace, or sync subshares from-service) may have names with the following format: _acopia_subshare_id$, where subshare is the name of the original subshare and id is a unique integer to identify the replica. If the subshare synchronization is underway and the back-end subshare is temporarily inaccessible to clients, the term [Fenced] appears in place of the subshare name. | |||||||||||||
| State describes the results of the subshare-replication process that occurs during managed-volume import. If the backing volume contains any CIFS subshares, the volume must replicate all subshare definitions on all of its filers:
| |||||||||||||
| Export is the name of the CIFS services subshare, as seen by CIFS clients. Filer is the name of the back-end filer, as configured on the ARX. For details on this filer (such as its IP address), use the show external-filer filer-name command. Share is the name of the imported share on the filer. The subshare resides in this share. Subshare is the name of the subshare on the filer. This is described above. State is also described above. | |||||||||||||
| bstnA> show cifs-service subshares ac1.medarch.org shows all of the front-end subshares in the ac1.medarch.org service, and all of the back-end subshares that correspond with them. The sample in Figure 24.7 shows several front-end subshares, where each is connected to three back-end subshares. bstnA> show cifs-service subshares ac1.medarch.org detailed shows details for the above subshares. Figure 24.7 shows sample output. canbyA> show cifs-service subshares all state degraded | |||||||||||||
Figure 24.7 Sample Output: show cifs-service subshares
bstnA> show cifs-service subshares ac1.MEDARCH.ORG
bstnA> show cifs-service subshares ac1.MEDARCH.ORG detailed
| show dynamic-dns [fqdn] fqdn (optional; 1-128 characters) is the fully-qualified domain name for one CIFS service (for example, www.organization.org). If you omit the FQDN, this command shows DNS summaries for all CIFS services. | |||||||
| Svc is the type of front-end service. This is always CIFS in the current implementation. Global Server identifies the global server for the CIFS service. The cifs service uses the same name. Domain Name is the windows-domain (gbl-gs) for the Global Server. This is also the Windows domain for the CIFS service. | |||||||
| Status is one of the following values:
Host Name is a host name that was configured for this CIFS service, set by the dynamic-dns command. VIP is the virtual-IP address for this CIFS service, set by the gbl-gs-vs virtual server command. The CIFS service registers the Host Name with the VIP in a single A record. | |||||||
| Operation is add or remove. The dynamic-dns command triggers an add operation. A remove is triggered by commands that delete a DNS host name (no dynamic-dns) or change the VIP (virtual server). This field is empty if the CIFS service is disabled. Retries is the number of failed attempts to register the host name. This should be 0 (zero); if it is greater than 0, you should check the DNS server(s) that are configured for the domain. (The name-server command configures one DNS server for an Active-Directory domain.) The syslog catalogs all registration failures; use show logs syslog to view the syslog. As above, this field is empty if the CIFS service is disabled. Last Update is the time and date of the last attempt to register this host name. DNS Server is the IP address of the name-server where the Last Update was sent. If the Status is FAIL, this server may be down. If the Status is OK but the Retries are 1 or more, the registration failed at some other DNS server(s) before it succeeded at this one. | |||||||
| bstnA> show dynamic-dns ac1.medarch.org | |||||||
Figure 24.9 Sample Output: show dynamic-dns ac1.medarch.org
bstnA> show dynamic-dns ac1.medarch.org
| Use the show global service command to cross-reference the front-end services with their global servers. | |
| fqdn (optional; up to 128 characters) is the fully-qualified domain name (for example, www.organization.org) for one global server. | |
| Domain Name is the FQDN that identifies the global server. Service is the type of front-end service: State is enabled or disabled. Use enable (gbl-cifs, gbl-nfs) to enable a front-end service. | |
| bstnA> show global service bstnA> show global service ac1.MEDARCH.ORG | |
| Use the show nfs-service command to display configuration information about one or more front-end NFS services. | |||||
| show nfs-service [fqdn | all] [detailed] fqdn (1-128 characters) is the fully-qualified domain name (for example, www.organization.org) for one NFS service. If no FQDN is specified, this command shows summaries for all NFS-service offerings. all (optional) shows full configurations for all NFS-service offerings. detailed (optional) shows full configurations for the selected NFS service(s), along with an additional table to show the behavior of each NFS export when one of its back-end shares is offline. When a client attempts to access a file that resides on an offline share, the NFS export can either send an access error to the client or silently wait for the client to retry. You can configure this behavior with the offline-behavior command. export namespace export-path focuses on a single service export. This shows the full configuration and the offline-behavior details for the selected export. namespace (1-30 characters) is the namespace that hosts the export, and export-path (1-1024 characters) is the full path of the NFS export, starting with the volume name. | |||||
| Domain Name is the FQDN that identifies the NFS service. The nfs command, which instantiates the NFS service, establishes this FQDN. It is the same as the FQDN for the global server where this service runs. Description is a string to describe this service. You can change it with the description (gbl-nfs) command. | |||||
| Virtual Server is the same as the Domain Name in the summary output; it is the FQDN that identifies the NFS service. Description also matches the summary output. NFS State is Enabled or Disabled. This is the administrative state, set with the enable (gbl-cifs, gbl-nfs) command. NLM State is also Enabled or Disabled. This shows whether or not the NFS Lock Manager (NLM) protocol is running for this NFS service. You can set this with the nlm enable command. | |||||
| Exports for Namespace name is the heading for each export table. This is the namespace that holds the back-end storage for the exports below. Export As is the NFS-export name that is advertised to clients. You can enter this with the export (gbl-nfs) command. Volume Path is the managed-volume path that is being shared. You also enter this as part of the export (gbl-nfs) command. An asterisk (*) appears after this if the export returns an access error for back-end shares that are offline; you can use the offline-behavior command to change this behavior. State is the volumes state:
Access shows the permissions that clients have for accessing this service. If an NFS access list is assigned to this service (with the nfs-access-list command), the name of the access list appears here. An (rw) appears if no access list is configured; this indicates that all clients have read and write access to the service. (NIS ip-address) appears if the access list refers to at least one NIS netgroup. This is the address of the NIS server used for the most-recent NIS update. The word ERROR appears instead of the IP address if the netgroup is not completely resolved. The error indicates that either a netgroup has caused the access list to grow too large, or one of the hosts in one of the netgroups cannot be resolved through a DNS lookup. Use show nis domain to find more details about the NIS configuration and its current status. | |||||
| The Offline-behavior table appears if you enter the detailed option in the command. This table shows the export behavior when clients access a back-end filer that is offline: the export either returns an access error to the client or silently allows the client to retry. The top row shows the default offline-behavior for the whole service, and the following rows (if any) each show the offline behavior for an individual namespace, volume, or export in the service. Each row contains the following columns: Namespace is one of the namespaces behind the current NFS service. This contains All in the top row and a specific namespace name in all subsequent rows. Volume is one volume in the namespace, or All if the behavior applies to all of the namespaces volumes. Path is a volume path that is exported to NFS clients, or All to indicate that the behavior applies to all of this volumes exported paths. Behavior is deny-access or retry. This shows the export behavior when a client accesses a file or directory on a back-end share that is currently offline. Either the client receives an access error or the NFS service silently waits for the client to retry the request. Count shows the number of NFS exports that use this behavior. If the count is 0 (zero) for a given behavior row, there is no export with the exact Path in this row. You can use the command with the exact path in this row for the offline behavior to take effect. The NFS client chooses one of these behaviors when mounting the NFS service. If the clients mount command exactly matches a Path in any row, the client gets the Behavior in that row. Otherwise, the client gets the behavior in the row that matches the closest, with an ancestor Path, the same Volume, or the same Namespace. | |||||
| bstnA> show nfs-service bstnA> show nfs-service ac1.MEDARCH.ORG shows the NFS service running at ac1.MEDARCH.ORG. See Figure 24.11 for sample output. bstnA> show nfs-service ac1.MEDARCH.ORG detailed shows the NFS service running at ac1.MEDARCH.ORG, along with details about the offline-filer behavior. See Figure 24.12 for sample output. bstnA> show nfs-service acopiaFiler | |||||
Figure 24.10 Sample Output: show nfs-service
bstnA> show nfs-service
Figure 24.11 Sample Output: show nfs-service ac1.medarch.org
bstnA> show nfs-service ac1.MEDARCH.ORG
bstnA> show nfs-service ac1.MEDARCH.ORG detailed
Figure 24.13 Sample Output: show nfs-service acopiaFiler
bstnA> show nfs-service acopiaFiler
| Use the show nfs-service mounts command to show all NFS mounts to one or more NFS services. | |
| show nfs-service mounts {fqdn | all} fqdn (1-128 characters) specifies a particular NFS service (for example, www.company.com). all shows all client connections to all NFS services. | |
| Global Server identifies the global server that the client mounted. The global servers name appears here as configured; depending on your external DNS configuration, it may not be an FQDN that is visible to clients. Use the show global server command for a full list of global servers, along with configuration details. Mount Point is where the client connected. This is the volume path established in the export (gbl-nfs) command, possibly with an additional sub path. Client IP Address identifies the client host. [VIP] is the Virtual-IP address to which the client connected. This also appears in the output for show global server. Note: After a client un mounts, there may be a short time where the clients mount persists in the output. Use the show nfs-service command to see NFS-service configuration and state. | |
| bstnA> show nfs-service mounts all bstnA> show nfs-service mounts acopiaFiler lists all mounts to a particular NFS service. See Figure 24.15 for sample output. | |
Figure 24.14 Sample Output: show nfs-service mounts all
bstnA> show nfs-service mounts all
Figure 24.15 Sample Output: show nfs-service mounts acopiaFiler
bstnA> show nfs-service mounts acopiaFiler
| Use the show nfs tcp command to display the current timeout period for NFS/TCP connections to back-end shares, and the current client-side behavior in the event of this server-side timeout (disconnect or send an I/O error). | |
| Consider an NFS client that makes a request, where the ARX forwards the request to a back-end NFS server. If the server times out after 105 seconds, the switch disconnects the client by default. You can use nfs tcp timeout to change this reaction: instead of closing the client connection, NFS services can send an NFSERR_IO (NFSv2) or NFS3ERR_IO (NFSv3) back to the client application. Behavior is either Close Connection or Return I/O Error. Inactivity is the timeout period. | |
| bstnA> show nfs tcp | |
| The NFS Lock Manager (NLM) manages file locks for NFS clients. Use the show nlm client command to display currently-held locks by one or all NFS-client machines. | |
| show nlm client {all | hostname} all | hostname is a required choice: all shows all NFS clients that hold any locks. hostname (1-192 characters) identifies one clients host machine (for example, myhost). This shows all files locked by the given host. | |
| The show nlm client all command presents a list of client hosts that currently hold locks, or held them over the last five minutes. The show nlm client hostname command shows the SVID (the process ID of the lock holder), namespace, and file path for all files locked by one client. To see all clients that hold locks for one of these files, you can copy the namespace and file path from this output and paste it into the show nlm file command. Use show nlm statistics to see statistics for all NLM activity. If a client machine is down, you can clear all of its locks with clear nlm locks. | |
| bstnA# show nlm client all | |
| bstnA# show nlm client rh1 | |
| The NFS Lock Manager (NLM) manages file locks for NFS clients. Use the show nlm file command to show which clients have locks on a given file. | |
| show nlm file namespace file-path namespace (1-30 characters) is the files namespace. file-path (1-4096 characters) identifies the file to check. | |
| This command shows all locks for the file at file-path. These are locks that are currently held or have been held in the last five minutes. The following information is shown for each lock: Client is the host name of a lock-holding client. SVID (System V Interface Definition) is process ID of the program that holds the lock. Locked Region shows which bytes are locked in the file. Type is either Exclusive or Shared. An exclusive lock is held by a single client, blocking access from all others. A shared lock can be shared by multiple clients, allowing them all to read the region but not change it. | |
| To see all the locks held by a given client machine (or a list of all the client machines that have locks), use the show nlm client command. If a client is down, you can clear all of its locks with clear nlm locks. Use show nlm statistics to see statistics for all NLM activity. | |
| bstnA# show nlm file wwmed /acct/rvcIndex.html | |
| bstnA# show nlm file EMC-NFS /NFS-EMC/lockfile | |
| The NFS Lock Manager (NLM) manages file locks for NFS front-end service clients. Use the show nlm statistics command to display NFS-lock statistics. | |
| Lock Requests is the total number of locks requested. Locks Granted is the number of locks that the NLM server granted to clients. Locks Denied counts the number of client requests that were rejected. Locks Blocked is the number of client requests where the lock is unavailable but client is willing to block until the lock is free. Unlock Requests is the number of requests to unlock a file region (NLM_UNLOCK requests). Test Requests is the number of NLM_TEST requests, which a client sends to check for the availability of a lock. Cancel Requests is the number of NLM_CANCEL requests, which a client sends cancel a blocked request. | |
| Current Locks Held is the total locks that clients hold now, system-wide. Cached Clients is the number of client machines with processes that hold (or recently held) locks. Lock-holding clients are cached for five minutes; this counts all the clients in that cache. Cached Processes is the number of processes that have held locks over the past five minutes. Cached File Handles is the number of NFS file handles that have been cached over the past five minutes. These identify files that have one or more locks on them. Unsupported Lock Calls is the total number of DOS-file-sharing calls. The ARX does not support those NLM calls. Unimplemented Lock Calls should always be zero; this indicates a malfunctioning client. If a client application is encountering NFS-locking errors (notably timeouts or hangs) then check this counter and look for NLM_UNIMPLEMENTED messages in the syslog. Those syslog messages specify the unsupported NLM function that was called. To see all the client machines that hold locks for a given file, use the show nlm file command. For a list locks held by a given client machine (or a list of all the client machines that have locks), use the show nlm client command. If a client is down, you can clear all of its locks with clear nlm locks. | |
| See Figure 24.16 for sample output. | |
Figure 24.16 Sample Output: show nlm statistics
bstnA# show nlm statistics
| Use the show virtual service command to display the front-end services running on each virtual server. | |||||||||||
| show virtual service [hostname] hostname (optional; up to 128 characters) is the hostname for one ARX in the current redundant pair. | |||||||||||
| Switch is the current ARX (or its redundant peer) where the virtual servers are running. Global Server is the global server for which this virtual server is a host. Virtual IP Address is the IP address where the front-end service is listening. Service is the name of the front-end service: State is the result of a health-check for the front-end service: Disabled indicates that an administrator has disabled the front-end service, or that is was just enabled and is about to go into the Starting state. Use the enable (gbl-cifs, gbl-nfs) command to enable a disabled service. Starting indicates that the NFS or CIFS service software is initializing or waiting for the exported volume(s) to become available. If (No Running Volumes) appears, too, the Starting state is frozen because of the services namespace(s); you can use show cifs-service or show nfs-service to find the namespace name(s), then use show namespace to examine each namespace and its volumes. Ready indicates that the NFS or CIFS service is ready to serve file data to external clients. Stopping indicates a transition from Ready to Disabled. The service stops because someone has disabled it (no enable (gbl-cifs, gbl-nfs)), or because someone has removed it (no nfs or no cifs). Failed indicates that the service has failed its health check. Call F5 Support if this state appears. Suspended means that an nsck ... rebuild is re-creating one of the services namespaces. When the rebuild finishes (or on reboot), the service goes back to the Starting state. Use show nsck to show the progress of all nsck jobs. Unreachable indicates that the remote switch is unreachable over the RON, so the service state is unknown. Use show ron to examine the status of the RON. | |||||||||||
| |||||||||||
| prtlndA> show virtual service shows all virtual services on the prtlndA switch and its redundant peer. See Figure 24.17 for sample output. prtlndA> show virtual service prtlndB | |||||||||||
Figure 24.17 Sample Output: show virtual service
prtlndA> show virtual service
| Use the signatures command to enable (or perhaps require) SMB signing between this CIFS front-end service and its clients. SMB signing is the process of placing a digital signature into each Server Message Block (SMB) exchanged between a CIFS server (this service) and any CIFS client. SMB signing prevents man-in-the-middle attacks at the cost of slower performance. Use no signatures to refuse SMB signing from any CIFS clients. This prevents any new connections from clients that require SMB signing. | |
| required (optional) obligates all CIFS clients to use SMB signing in their communication with this service. If any of the clients refuse to support SMB signing, they cannot connect to the service. | |
| If you use this command to declare SMB signatures required, the service only accepts connections from clients that support SMB signing. The least-restrictive setting is to enable SMB signing without requiring it (using the simple signatures syntax). The CIFS service can then accept any client connection, whether it requires or refuses SMB signing. If a client requests or requires SMB signatures, the CIFS service complies. To control the SMB-signing policy between one of the services backing namespaces and its back-end filers, you can use the cifs filer-signatures command in gbl-ns mode. To find the backing namespace(s) for this CIFS service, use show cifs-service fqdn, where fqdn is the name of the CIFS service. To see the number of filers and/or clients who have used SMB signing, along with some success and failure statistics, use the show fastpath cifs-signatures command. | |
| bstnA(gbl-cifs[ac1.medarch.org])# signatures | |
| You can use the sync cifs delegation command to immediately synchronize an ARX cifs service with its delegation settings in the Active Directory (AD). With the proper delegation settings, a CIFS client can authenticate at the ARX once and then access any of the back-end servers without re-authenticating. This delegation feature is set in the AD, outside the ARX. When someone changes the delegation settings at a domain controller (DC), the ARX software can take up to 10 minutes to synchronize with the changes. Use this command to make the synchronization immediate. | |
| sync cifs delegation {fqdn | all} all synchronizes the delegation settings for all CIFS services on the ARX. | |
| Delegation enables multiple CIFS servers to delegate client authentications to a front-end CIFS service, so that clients can authenticate with the front-end service once and remain authenticated for connections with the back-end servers. We recommend trusting your ARX CIFS service for delegation, to enable this single-sign-on feature. It is generally recommended that you also constrain this delegation to the particular CIFS servers behind this service. You set this trust (at a DC) in the CIFS services machine account, or you can set it with the domain-join command if you have sufficient privileges. If the service uses constrained delegation, you can use the probe delegate-to command to confirm that all the servers behind a particular CIFS service are properly assigned to its delegate list. Clients can only access the storage on a back-end server that is on that list. | |
| stkbrgA# sync cifs delegation bgh.MEDARCH.ORG | |
| Character encoding is the mapping between binary numbers and written characters. Some character-encoding schemes use only a single byte for each character; these typically support alphabets without any Asian characters. Multi-byte encoding schemes encompass Asian character sets. Unicode (such as UTF-8) can also use more than one byte per character, and encompasses most character sets and languages. Use the wins-name-encoding command to set the CIFS services character encoding for its NetBIOS names. Use no wins-name-encoding to reset NetBIOS names back to the single-byte default. | |
| utf-8 specifies UTF-8 (Unicode) character encoding. shift-jis specifies Shift_JIS (Japanese) character encoding. cp932 is Code Page 932, or Windows-31J (Japanese) character encoding. This is the Microsoft version of Shift_JIS. euc-jp specifies EUC-JP (Extended Unix Code - Japanese) character encoding. ksc5601 is KSC5601 (Korean) character encoding. iso-8859-1 is ISO 8859-1 (Latin1, single-byte) character encoding. | |
| This command determines the character encoding used to register the virtual servers NetBIOS computer name (called the wins-name) with its wins server. This should be the encoding supported by the networks WINS server. This also determines the encoding for all of the virtual servers wins-alias names, as well as the servers group (or domain) name. | |
| bstnA(gbl-cifs[ac1.medarch.org])# wins-name-encoding shift-jis sets the character encoding to Shift_JIS for the ac1.medarch.org service. Whenever the virtual server registers its NetBIOS names with its wins server, it translates to Shift_JIS for the registration. bstnA(gbl-cifs[ac1.medarch.org])# no wins-name-encoding | |
