Applies To:

Show Versions Show Versions

Manual Chapter: Troubleshooting Managed Volumes
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

10 
The ARX records read/write statistics, including latency measures, for each of its filer shares. It keeps these statistics from the moment each share is enabled as part of an ARX volume. (For instructions on configuring and enabling a volume share, refer to the ARX® CLI Storage-Management Guide: Adding a Share, on page 8-8 for direct volumes, or Adding a Share, on page 9-33 for managed volumes.) The statistics are kept at the NSM, which runs the ARXs fastpath processes. Use the show statistics namespace fastpath command to see these statistics:
bstnA> show statistics namespace fastpath
To focus on the share statistics from one namespace, use the namespace argument in the show statistics namespace command, followed by the fastpath keyword:
name (1-30 characters) identifies the desired namespace, and
fastpath is a required keyword.
bstnA> show statistics namespace wwmed fastpath
show statistics namespace name volume fastpath
name (1-30 characters) identifies the desired namespace,
volume (1-1024 characters) identifies the volume, and
fastpath is a required keyword.
bstnA> show statistics namespace wwmed /acct fastpath
show statistics namespace name volume share-name fastpath
name (1-30 characters) identifies the desired namespace,
volume (1-1024 characters) identifies the volume,
share-name (1-64 characters) identifies the specific share, and
fastpath is a required keyword.
bstnA> show statistics namespace wwmed /acct budget fastpath
show statistics metadata [namespace name [volume volumepath]]
where name specifies a namespace for which to display metadata statistics, and volumepath species a volume for which to display metadata statistics.
bstnA# show statistics metadata
Execute the command clear statistics metadata to clear and reset metadata counters for the entire system, or for a specified namespace or volume.
You can move all files from one share (or share farm) to one or more other shares in the same volume, thereby draining the source share(s). A placement rule accomplishes this, and prevents any new files from being created on the source share(s). A placement rule is typically used for moving files to their storage tiers, as described in Placing Files on Particular Shares, on page 14-4 of the ARX® CLI Storage-Management Guide. This is a special use case for a placement rule.
Use place-rule to create a new placement rule, as described in the storage manual. This puts you into gbl-ns-vol-plc mode, where you must choose a source share or share farm, set the storage target for the files, and enable the rule. There are also some optional commands you can invoke from this mode. This section explains the options that are relevant to draining a share.
bstnA(gbl)# namespace wwmed volume /acct
From gbl-ns-vol-plc mode, use one of two source commands to specify the source share(s):
source share share-name
where share share-name (1-64 characters) identifies a single source share, or
source share-farm share-farm-name
where share-farm-name (1-64 characters) is a group of shares in a share farm.
Use the show global-config namespace command to see the shares or share farms in each volume: see Showing Namespace Configuration, on page 7-24 of the ARX® CLI Storage-Management Guide.
bstnA(gbl)# namespace wwmed volume /acct
bstnA(gbl)# namespace wwmed volume /acct
bstnA(gbl)# namespace archives volume /etc
To migrate files off of any share that is running low on free space, you can configure auto migration for the share farm. Refer to Auto Migrating Existing Files, on page 15-15 of the ARX® CLI Storage-Management Guide.
to close any files held open by CIFS clients, thereby making it possible to migrate them. For details, refer to Automatically Closing All Open Files (CIFS), on page 14-14 of the ARX® CLI Storage-Management Guide.
to control the bandwidth used for migrations. For details, refer to Limiting Each Migration (optional), on page 14-17 of the same storage guide.
to create a progress report for the drain operation. This is recommended. For details, refer to Configuring Progress Reports, on page 14-21 of the storage guide.
bstnA(gbl)# namespace wwmed volume /acct
bstnA(gbl)# namespace wwmed volume /acct share it5
bstnA(gbl)# namespace wwmed volume /acct share it5
A tentative rule is configured to appear in the system logs (syslog) as tentative, showing the potential effects of the rule if it was enabled. (The log component, POLICY_ACTION, creates the syslog messages; syslog access and log components are described in Accessing the Syslog.) If you configured reporting for the rule (as shown above), the report shows which files would be migrated if the rule was fully enabled. Tentative rules do not change policy enforcement, but they do consume processing time in the policy software. From gbl-ns-vol-plc mode, use the tentative command to put the placement rule in a tentative state:
To see the simulated rule run, you must enable the rule (as described below). Then use show logs syslog or grep pattern logs syslog to view the syslog.
bstnA(gbl)# namespace wwmed volume /acct
Use the no tentative command to fully activate the drain rule. You can then disable and re-enable the rule (as described below) to start the draining process. For example, the following command sequence activates the emptyRH rule. When the rule is enabled, it performs actual migrations:
bstnA(gbl)# namespace wwmed volume /acct
The final step in draining a share is to enable its placement rule. By default, the rule is disabled and ignored by policy software. Use the enable command to enable the rule. For example, the following command sequence enables the emptyRH rule:
bstnA(gbl)# namespace wwmed volume /acct
Disabling the rule removes it from consideration. Use no enable from gbl-ns-vol-plc mode to disable a placement rule. For example, the following command sequence disables the emptyRH rule:
bstnA(gbl)# namespace wwmed volume /acct
You can use a metadata-only report to verify that the share is empty. Use the nsck ... metadata-only command to generate a report about the share (as described in Focusing on One Share), and then use show reports to view the report. For example, the following command sequence generates a report on the it5 share, proving that it has no files:
bstnA(gbl)# nsck wwmed report metadata-only share it5
bstnA(gbl)# show reports metadata_only.10.rpt
You can remove a rule to both disable it and delete its configuration. From gbl-ns-vol mode, use the no form of the place-rule command to remove a placement/drain rule. For example, the following command sequence removes the drain rule, drainSrvW08, from the medarcv~/rcrds volume:
bstnA(gbl)# namespace medarcv volume /rcrds
bstnA(gbl-ns-vol[medarcv~/rcrds])# no place-rule drainSrvW08
You can remove a share from its managed volume without affecting service to the volumes clients. The remove-share migrate command migrates all of the shares files and master directories to another share or share farm in the same volume. (A master directory is the first-imported (or only) instance of a directory in the managed volume.)
Before you remove the share, you must first verify that it is not referenced by any policies or rules; look for the share name in the volumes rules (use the show policy namespace ... volume command, as shown in Focusing on One Volume, on page 14-40 of the ARX® CLI Storage-Management Guide). Also, the share must be online in the namespace: use show namespace status to confirm this (see Monitoring the Import, on page 9-56 of the same manual).
From priv-exec mode, use remove-share migrate to remove the share:
remove-share migrate namespace volume share destination [close-file [exclude fileset]] [async]
namespace (1-30 characters),
volume (1-1024 characters), and
share (1-64 characters) all identify the share to remove, and
destination (1-64 characters) is the destination share or share farm. This command migrates all of the shares files and master directories to the destination. This must be a share or share farm in the same volume.
close-file (optional) causes the operation to close all files open by CIFS clients in order to migrate them. If you omit this option, files opened by CIFS clients cannot migrate off of the selected share. This would leave files stranded on the share and cause the share removal to fail.
exclude fileset (optional if you choose close-file, 1-64 characters) is a fileset to exclude from automatic closure. If a file in this fileset is open through CIFS, the rule places it on a retry queue instead of automatically closing it. If such a file remains open for the duration of the share removal, it never migrates off of the share and the share-removal fails.
async (optional if you specify a destination) makes this command return immediately, rather than waiting for the share removal to finish.
The CLI prompts you with a warning before removing the share; enter yes to proceed. The CLI blocks as the volume migrates the files and directories off of the share, then prints a message indicating the success of the share removal.
bstnA# remove-share migrate wwmed /acct it5 fm1
If the share is in a multi-protocol (NFS and CIFS) volume, the volume may require additional processing for the migration. The extra processing guards against a file or directory on the source share colliding with a filer-generated name (FGN) at the destination. The volume does not record filer-side FGNs in its metadata; it deduces when collisions are possible and then uses probes to check for them.
Any file or directory with a back-end FGN is labeled NFS-only; CIFS clients cannot access it through the volume, and the ARX software cannot reliably find its CIFS-side FGN. The CIFS attributes for NFS-only files and directories are therefore inaccessible to the ARX. This is especially important for directories. If the volume cannot find a directorys CIFS attributes, it cannot make a precise duplicate of the directory. The migrations for NFS-only directories therefore fail.
bstnA(gbl)# namespace insur
bstnA(gbl)# namespace insur
drain_share_rule_for_share_share-name_time.rpt, and
remove.job-id.share-name.share-id.rpt
Use show reports type Plc to list all file-placement (and drain-share) reports. To list all of the remove-share reports, use show reports type Rm. For example, this shows the two reports (highlighted in bold text) from removing the it5 share:
bstnA# show reports type Plc
drain_share_rule_for_share_it5_201002240213.rpt Feb 24 02:21 2.3 kB Plc DONE: 44 in 00:07:34
bstnA# show reports type Rm
remove.23.it5.8.rpt Feb 24 02:21 1.3 kB Rm DONE: 942 in 00:00:01
The drain-share report shows the number of files migrated off of the share. Use the show reports command to show it. For example, this shows the numbers of files migrated from the it5 share:
bstnA# show reports drain_share_rule_for_share_it5_201002240213.rpt
bstnA# show reports remove.23.it5.8.rpt
By default, the CLI waits for the share removal to finish before allowing you to enter any more commands. Add the async flag at the end of the command to return to the CLI immediately after confirming the removal:
remove-share migrate namespace volume share destination async
bstnA# remove-share migrate wwmed /acct it5 fm1 async
From priv-exec mode, use the remove-share nomigrate command to remove a share from a namespace without migrating any of its files:
remove-share nomigrate namespace volume share destination [async]
where all of the options are described above. The destination is required for the shares master directories, which must migrate before the share is removed. In multi-protocol volumes, master directories with NFS-only names cannot migrate to the destination share; resolve this as discussed above, in Migrating NFS-Only Directories.
The CLI prompts for confirmation; enter yes to continue. The back-end share does not lose any of its files or directories when you use this command. You can access the share directly when the share-removal completes.
bstnA# remove-share nomigrate medarcv /rcrds oldrx rx async
remove-share nomigrate namespace volume share destination [async]
The CLI prompts you with a warning before removing the share; enter yes to proceed. The CLI blocks as the volume removes the share, then prints a message indicating the success of the share removal.
bstnA# remove-share nomigrate ns / defunctShr rx async
cancel remove namespace ns volume vol-path share share-name
ns (1-30 characters) identifies the namespace.
vol-path (1-1024 characters) is the shares volume.
share-name (1-64 characters) is the share.
bstnA# cancel remove namespace wwmed volume /acct share expir
You can remove an offline, unreachable, or otherwise defunct back-end share from a namespace by using the remove-share offline CLI command in privileged-exec mode. Use this command only for a back-end share that is unreachable on a metadata-based managed volume, not on a direct volume. If the share is still reachable, use remove-share migrate or remove-share nomigrate instead.
When executed, the command creates a report, remove.job-id.share-name.share-id.rpt. Use show reports to view its contents.
The remove-share offline command deletes all of the shares files from the volumes metadata; from the clients perspective, these files disappear. Given that the back-end filer was unreachable to begin with, those files were inaccessible to clients already. Before removing the share, resolve all dependencies on the share. Use the show policy command to verify that no policy rules reference the share.
remove-share offline namespace volume share dest [async]
namespace (1 - 30 characters) is the name of the namespace.
volume (1 - 1024 characters) is the name of the volume.
share (1 - 64 characters) is the name of the share.
dest (1 - 64 characters) is the new destination share or share farm where the original shares master directories (if any) are to be migrated. A master directory is the first-imported instance of a directory in the managed volume. Use show global-config namespace for a list of shares and share farms in the namespace.
async (optional) makes this command return immediately, rather than waiting for the share removal to finish.
After you enable a namespace volume, the volume reads all of its back-end shares and imports all of their files and directories. If anything goes wrong in any share, the failed share shows a Status of Error in the show namespace status output, and one of the errors in Table 10.1 appears in the more-verbose show namespace output. Use show namespace (not show namespace status) to see the full error message.
After you correct the problem, use nsck ... rebuild volume to reimport all shares in the volume.
One of the shares directories has a name with Unicode characters that are unsupported by the character-encoding nfs setting. CIFS file names are Unicode and can contain any character, but NFS servers and clients must each configure their character encoding for file names. The volume cannot import a directory with any un-mappable characters in its name.
You can use the import rename-directories unmapped-unicode command to allow the volume to rename such directories during import, or you can rename them manually at the filer. Then restart the share import: enter gbl-ns-vol-shr mode and re use the enable (gbl-ns-vol-shr) command.
A share with a higher import priority has failed its import, so this share cannot import. If any share import fails, the managed volume cannot import any shares with lower import priorities. Find the import error for the failed share(s), look for the error in this table, and take action as directed. This error is resolved as soon as all higher-priority shares successfully import.
For NFS exports, check your back-end filer configuration: the back-end share should allow root access to all of the ARXs proxy IP addresses. Use the show exports command examine all permission settings at the filer. Use the show ip proxy-addresses command to list all configured proxy IP addresses.
For CIFS shares, the switch uses the namespaces proxy user (username and password). The proxy-user credentials must belong to the Administrators group at every filer behind the namespace. Use the probe exports command to check this. The proxy-user (gbl-ns) command sets the proxy user credentials for a namespace.
After you correct the problem, use nsck ... rebuild volume to reimport all shares in the volume.
For NFS exports, check your back-end filer configuration: the back-end share should allow root access to all of the ARXs proxy IP addresses. Use the show exports command examine all permission settings at the filer. Use the show ip proxy-addresses command to list all configured proxy IP addresses.
For CIFS shares, the switch uses the namespaces proxy user (username and password). The proxy-user credentials must belong to the Administrators group at every filer behind the namespace. The proxy-user (gbl-ns) command sets the proxy user credentials for a namespace.
The share cannot be found on the external filer. Use the filer command to change the path or share name for this share, then re-enable the share (enable (gbl-ns-vol-shr)) to retry the import.
(CIFS) The volume supports cifs access-based-enum (ABE), and attempted to replicate ABE settings between its back-end shares. This replication process failed. The same process also checks for CIFS subshares (filer-subshares), so you can use sync subshares from-namespace ... tentative to get a full report on this issue.
This often occurs because the ARX does not have proper permissions to check for ABE support on this back-end share. The ARX uses the namespaces proxy user (username and password) as its identity when it checks for ABE support. The proxy-user credentials must belong to the Administrators group at this back-end filer. You can use the proxy-user (gbl-ns) command to choose new proxy user credentials for the namespace.
After you find and fix this issue, use nsck ... rebuild volume to reimport all shares in the volume.
(CIFS) This is a CIFS error that is not an access or network error, but prevented the import. The syslog shows the specific error. Use show logs syslog to read the syslog, or grep string logs syslog to search for a specific string in the syslog.
After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import.
(multi-protocol) The volume software encountered an NFS symbolic link on this back-end share, and the volume has cifs deny-symlinks enabled. You can resolve this issue by using the no cifs deny-symlinks command to allow the volume software to follow these links. Alternatively, you can remove all NFS symbolic links from the back-end share.
After you fix this issue, use nsck ... rebuild volume to reimport all shares in the volume.
(CIFS) The back-end filer returned an unexpected CIFS error during import. The syslog shows the specific error. Use show logs syslog to read the syslog, or grep string logs syslog to search for a specific string in the syslog. You may need to escalate to F5 Support.
After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import.
(CIFS) The filer returned an unexpected error during the import, and the error indicates a problem at the filer itself. The syslog shows the specific error. (Use show logs syslog to read the syslog, or grep string logs syslog to search for a specific string in the syslog.) Check the filer itself and correct the problem there.
After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import.
(CIFS) The back-end share returned an error indicating that it does not support a CIFS option that the ARX requires. Consult the F5 Data Solutions Compatibility Matrix (included in this doc set) to confirm that the filer has been qualified for use behind the ARX. If the share cannot possibly support CIFS behind an ARX, you can use no share to remove the share from the volume.
After you fix this issue, use nsck ... rebuild volume to reimport all shares in the volume.
(CIFS) The namespace software attempted to write a test file to the share and failed. Go to the filer and check permissions for the namespaces proxy-user (gbl-ns); the proxy user must be part of the Backup Operators and/or Administrators group on the filer.
After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import.
(CIFS) The volume supports filer-subshares and/or cifs access-based-enum (ABE), and attempted to replicate subshares, subshare ACLs, and/or ABE settings between its back-end shares. This replication process, also known as subshare synchronization, failed. As a result, any front-end export of the failed subshare will be degraded. The output of show cifs-service fqdn shows all of the degraded subshares in a given fqdn service.
Use sync subshares from-namespace ... tentative to get a full report on this issue. To repair it, use the sync subshares from-namespace or sync subshares from-service command without the tentative option.
Use the proxy-user command to add or edit these credentials, and use the proxy-user (gbl-ns) command to apply them to a namespace.
After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import.
You can use show cifs-service open-files to find the open file, close cifs file to close it, and then retry the share import (with enable (gbl-ns-vol-shr)).
Failure to update file attributes can be caused by loss of connectivity during the import. Use the show exports command and/or ping to check the connection to the filer.
After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import.
Two or more of the volumes shares had common file names that either collided or had NFS/CIFS naming inconsistencies, and this volume disallows import if it encounters either of these problems. As an example of a collision, suppose share A and share B had the same file in the same path, \docs\index.htm: these files would collide. A naming inconsistency can only occur for a directory in a multi-protocol (NFS and CIFS) namespace; the CIFS-side directory name has unicode characters that are inexpressible on the NFS-side (see the documentation for the character-encoding nfs command). The volume must be allowed to modify the directory (or one of the colliding files) for the import to succeed: the directory or file must be renamed.
All duplicate files and naming inconsistencies are recorded in the import reports for each share. These reports are named import.job-id.share-name.share-id.rpt. Use show reports to list all import reports and read their contents.
Using the import report for each share, resolve all file collisions and naming inconsistencies before re-importing. Go to the filers and rename the files, move them, and/or resolve that certain file renames are acceptable. Once the issues are cleared, use the gbl-ns-vol reimport-modify and modify commands to allow modification (renames) on import. (If any other shares are still importing, you must wait for their imports to finish before you can use the modify command.) To rename inconsistent NFS/CIFS directories, use the import rename-directories unmapped-unicode command, too.
After you correct the problem, use nsck ... rebuild volume to reimport all shares in the volume.
To retry the import, you can use the enable (gbl-ns-vol-shr) command on this share.
Remove all DFS links from the back-end share. Then use the enable (gbl-ns-vol-shr) command to retry the import.
To allow the volume to modify directory attributes on import, you can use modify on the volume and import sync-attributes on the share. (If any other shares are still importing, you must wait for their imports to finish before you can use the modify command.) Then use the enable (gbl-ns-vol-shr) command to retry the import.
This can only occur for NFS-only directories, with names that are illegal in CIFS. If possible, change the directory name(s) so that they are accessible from CIFS. As an alternative, you can use no strict-attribute-consistency to remove the requirement for strict-attribute consistency; this reduces all undiscovered CIFS attributes to zero. Once the volume has stopped importing any shares, you can do this for all shares in the volume. Then restart this share import with the enable (gbl-ns-vol-shr) command.
To allow the volume to correct this by changing the directory name on import, you can use modify on the volume and import rename-directories on the share. Alternatively, you can directly access the filer(s) and correct the problem there. Retry this share import (with enable (gbl-ns-vol-shr)) after you address the issue.
Two or more of the volumes shares had common file/directory names that somehow collided, causing one of the shares to fail its import. The following collisions can cause this failure:
A file or directory in share A has a CIFS case collision with a file or directory on share B, and the volume is set for no cifs case-sensitive. For example, myDir/MYFILE.doc on share A could collide with myDir/myFile.doc on share B.
All duplicate files and naming inconsistencies are recorded in the import reports for the share. These reports are named import.job-id.share-name.share-id.rpt. Use show reports type Imp to list all import reports, and use show reports report-name to read a report.
Then re-import the share with the enable (gbl-ns-vol-shr) command.
The share import failed for an undetermined reason. Run the collect diag-info CLI command to collect diagnostic information, then contact F5 Support.
An internal import operation timed out, possibly due to a filer-connectivity issue. Use the show exports command and/or ping to troubleshoot the connection to the filer.
The managed volume software supports a maximum of 1024 hard links per file. One or more files on this back-end share exceed this limit. These files are recorded in the shares import report, named import.job-id.share-name.share-id.rpt. Use show reports type Imp to list all import reports, and use show reports report-name to read a particular report. Then access the filer directly to reduce the number of hard links for all of these files.
After you correct the problem, use nsck ... rebuild volume to reimport all shares in the volume.
After you correct the problem, use nsck ... rebuild volume to reimport all shares in the volume.
For NFS exports, check your back-end filer configuration: the back-end share should allow root access to all of the ARXs proxy IP addresses. Use the show ip proxy-addresses command to list all configured proxy IP addresses.
For CIFS shares, the switch uses the namespaces proxy user as its identity. The proxy user, created by the proxy-user command, must belong to the Administrators group. The proxy-user (gbl-ns) command sets the proxy user for a namespace.
Once some space is free, you can use the enable (gbl-ns-vol-shr) command to restart the share import.
This indicates permissions problems at the back-end filer. Use the show exports command to examine all permission settings at the filer.
For NFS exports, check your back-end filer configuration: the back-end share should allow root access to all of the ARXs proxy IP addresses. Use the show ip proxy-addresses command to list all configured proxy IP addresses.
For CIFS shares, the switch uses the namespaces proxy user as its identity. The proxy user, created by the proxy-user command, must belong to the Administrators group. The proxy-user (gbl-ns) command sets the proxy user for a namespace.
The back-end device could not be located with the IP address configured for the filer. From gbl-ext-filer mode, use the ip address command to reset the filers address. Use the show exports command, expect traceroute, and/or ping to check the connection to the filer.
After the filer connection is re-established, you can use the enable (gbl-ns-vol-shr) command to restart the share import.
This may indicate a full disk on the back-end filer or permissions problems. Use the show exports command to examine all permission settings at the filer.
For NFS exports, check your back-end filer configuration: the back-end share should allow root access to all of the ARXs proxy IP addresses. Use the show ip proxy-addresses command to list all configured proxy IP addresses.
For CIFS shares, the switch uses the namespaces proxy user as its identity. The proxy user, created by the proxy-user command, must belong to the Administrators group. The proxy-user (gbl-ns) command sets the proxy user for a namespace.
You can use show cifs-service open-files to find the open file, close cifs file to close it, and then retry the share import (with the enable (gbl-ns-vol-shr) command).
Use the show exports command and/or ping to troubleshoot the connection to the filer. After the filer connection is re-established, you can use the enable (gbl-ns-vol-shr) command to restart the share import.
(CIFS) The namespace supports Kerberos authentication (see cifs authentication), but the namespace software is unable to confirm that the share is configured to support Kerberos, too.
Check the connection to the back-end filer with show exports and/or ping. Restart the import (with enable (gbl-ns-vol-shr)) after you correct the problem.
A file on this share has the same name and path as a file on an already-imported share. To fix this, you can manually go to the filer and rename the file, or you can set the modify flag on this volume. By setting the modify flag, you allow the volume to rename the file on import. (If any other shares are still importing, you must wait for their imports to finish before you can use the modify command.) You must also have the default settings for import rename-files and import rename-directories on this share.
Then restart the import with the enable (gbl-ns-vol-shr) command.
Check the directory at the back-end share, and rename it so that both versions have the same name. Alternatively, you can set the modify flag on this volume. By setting the modify flag, you allow the volume to rename the directory on import. (If any other shares are still importing, you must wait for their imports to finish before you can use the modify command.)
You may also need to set import rename-directories unmapped-unicode for this share; this allows the volume to rename directories whose CIFS names do not map to the character encoding for NFS. Then restart the import with the enable (gbl-ns-vol-shr) command.
A file on this share has the same name and path as a file on an already-imported share. To fix this, you can manually go to the filer and rename the file, or you can set the modify flag on this volume. By setting the modify flag, you allow the volume to rename the file on import. (If any other shares are still importing, you must wait for their imports to finish before you can use the modify command.) You must also have the default settings for import rename-files and import rename-directories on this share.
Rename the file at the filer share, then use nsck ... rebuild volume to reimport all shares in the volume.
The protocol(s) configured for the back-end share are not actually supported at the filer. Use the show exports command to check the protocols supported by the filer. Use the show global-config namespace command to view the required protocols for the namespace. The share must support all of the namespaces protocols.
You can remove the share from the volume (with no share), or you can add protocol support at the back-end filer. If you add the protocol support to the filer, you can then restart the share import with the enable (gbl-ns-vol-shr) command.
The import report shows the name of the conflicting file or directory. The name appears with an FC notation. The report is named import.job-id.share-name.share-id.rpt. Use show reports to list all import reports and read their contents.
The back-end filer behind this share returned an error that the ARX does not recognize. You can use the show logs syslog command to view the system log and learn more about the circumstances around the failure.
We recommend that you contact F5 Support if you see this import error. You may be requested to run the collect command, which assembles diagnostic information for F5 Engineering.
After the issue is resolved, use nsck ... rebuild volume to reimport all shares in the volume.
The import failed because the back-end filer returned a link count of zero or a negative number for a file, which is invalid. A files link count should be one or more. The ARX syslog contains the file with the invalid link count; use grep link count logs syslog to find the path. Use this path to help diagnose and correct the filer issue. Then use the enable (gbl-ns-vol-shr) command to retry the import.
Use the show exports command and/or ping to check the connection to the filer. Restart the import (with enable (gbl-ns-vol-shr)) after the connection is restored.
You can restart the share import with the enable (gbl-ns-vol-shr) command.
This share contains more files than the volume can hold. Use the auto reserve files command to automatically increase the number of files that this volume can hold as the volume grows. If you prefer to manually set the maximum files for the volume, use reserve files to manually increase the maximum. Then restart the share import with the enable (gbl-ns-vol-shr) command.
These errors each indicate an internal software problem. Run the collect diag-info CLI command to collect diagnostic information, then contact F5 Support.
The specific directory and file name appears in a syslog message labeled ERROR_MAX_HASH_COLLISIONS. Use grep ERROR_MAX_HASH_COLLISIONS logs syslog to search for this error in the syslog.
Once the external problem is resolved, use nsck ... rebuild volume to reimport all shares in the volume.
Use nsck ... rebuild volume to re-initialize the metadata share and reimport all shares in the volume.
The switch could not contact the metadata share. Use the show exports command and/or ping to check the connection to the metadata shares filer. The show export command also verifies that the share is accessible by root (for NFS shares) or the namespaces proxy-user (gbl-ns) (for CIFS shares).
(multi-protocol) The NFS character-encoding setting for the namespace does not match the character encoding supported at the filer. If this share was imported, lost NFS files could result. Reset the namespace character encoding (using the character-encoding nfs command) and retry the import. You can use the enable (gbl-ns-vol-shr) command to restart the share import.
(multi-protocol) The filer command specified an NFS export and a CIFS share over two different directory trees. This is unsupported. Retry the command with the correct share and export names, then retry the import with enable (gbl-ns-vol-shr).
(multi-protocol) During import, the volume creates a test file through CIFS and then attempts to read it through NFS. The volume was unable to read the file as root. Check the NFS configuration at the back-end share, correct the problem, and retry the import (enable (gbl-ns-vol-shr)).
(multi-protocol) During import, the volume creates a test file through CIFS and then attempts to delete it through NFS. The volume could read and write the file (as root), but was unable to remove it. This may indicate a permissions problem in the top-level directory for the share. Check the NFS configuration at the back-end share, correct the problem, and retry the import (enable (gbl-ns-vol-shr)).
(multi-protocol) During import, the volume creates a test file through CIFS and then attempts to write to it through NFS. The volume could read the file, but was unable to write to it (as root). Check the NFS configuration at the back-end share, correct the problem, and retry the import (enable (gbl-ns-vol-shr)).
(NFS) The back-end share does not support the NFS version(s) configured for the external filer. Use the show exports command to check the protocols supported by the filer. Use the filer command to change the configured NFS version(s) for the share/export.
Use the show exports command, expect traceroute, and/or ping to troubleshoot the connection to the filer. After the filer connection is re-established, you can restart the share import with the enable (gbl-ns-vol-shr) command.
(CIFS) A connection error occurred in the middle of a CIFS-permissions test. Use the show exports command, expect traceroute, and/or ping to troubleshoot the connection to the filer. Once the connection is fully restored, you can restart the share import with the enable (gbl-ns-vol-shr) command.
The namespaces proxy-user does not have adequate privileges to write to this CIFS share, so the import failed. The proxy user must belong to the Administrators group on this filer. You can choose new, more-privileged credentials for your proxy user, or you can go to the filer and add the current proxy user to a more-privileged group. The probe exports command can verify that the new proxy-user credentials pass this write test. Then restart the import with the enable (gbl-ns-vol-shr) command.
An administrator issued the cancel import command to stop this share import. You can restart the import with the enable (gbl-ns-vol-shr) command.
For NFS exports, check your back-end filer configuration: the back-end share should allow access to all of the ARXs proxy IP addresses. Use the show exports command to check the filers permissions and configuration. Use the show ip proxy-addresses command to list all configured proxy IP addresses.
For CIFS shares, the switch uses the proxy user for the namespace; the proxy-user (gbl-ns) command sets these credentials. The proxy user must belong to the Administrators group.
(CIFS) The back-end filer returned an unexpected CIFS error during import. The syslog shows the specific error. Use show logs syslog to read the syslog, or grep string logs syslog to search for a specific string in the syslog. You may need to escalate to F5 Support.
After you correct the error, use nsck ... rebuild volume to reimport all shares in the volume.
(multi-protocol) The proxy user is a Windows username and password that the volume can use as its identity for share import and for policy operations. In a multi-protocol (CIFS and NFS) namespace, the proxy user on the Windows side must map to the root user on the UNIX side.
You can select a new proxy user for the namespace with the command. If necessary, map the proxy user to root at the filer itself; the ARX Site Planning Guide has instructions for creating this mapping on common multi-protocol filers.
An administrator failed to remove the share with no share because client-visible files are still present on the share. Use the remove-file-entries option to remove all of the file entries from the volume; this produces a client-visible effect, so do this with caution.
Alternatively, you can use remove-share nomigrate.
Check your back-end filer configuration: the back-end share should have no-root-squash set for all of the ARXs proxy IP addresses. (On some filers, you accomplish this by mapping the anonymous user to UID 0 (zero).) Use the show exports command to check the filers permission settings. Use the show ip proxy-addresses command to list all configured proxy IP addresses.
(CIFS) The CIFS attributes set for the volume (with compressed-files, named-streams, persistent-acls, sparse-files, and/or unicode-on-disk) are not all supported at the back-end share. Use the show exports command to check the supported CIFS attributes for the share.
You can remove the share from the volume (with no share) or disable the conflicting CIFS attribute(s) in the managed volume. If you elect to keep the share in the volume, use the enable (gbl-ns-vol-shr) command to restart the share import.
(CIFS) The namespace supports Kerberos authentication (see cifs authentication), but this share does not. The share must support extended security negotiations for the import to succeed. Also, the ARX needs the correct service-principal name (SPN) for the filer; you can use show exports ... capabilities to verify that the ARX has discovered the correct SPN for the filer, or you can use the spn command to set it manually.
After you ensure that the filer support Kerberos and the ARX has the filers SPN, you can restart the import (enable (gbl-ns-vol-shr)). Alternatively, you can remove the share from the volume with no share.
Each back-end share must support all of the namespaces configured protocols (any combination of NFSv2, NFSv3(/UDP), NFSv3/TCP, and CIFS). Use the show global-config namespace command to view the namespaces protocols.
You can remove the share from the volume (with no share) or enable the missing service(s) at the filer. If you elect to keep the share in the volume, use the enable (gbl-ns-vol-shr) command to restart the share import.
The export name is incorrect in the external-filer configuration. Use the filer command to change the configured name for the share/export.
You can restart the share import with enable (gbl-ns-vol-shr) after you resolve the filer issue.
From gbl-ns-vol-shr mode in the CLI, use no filer to detach from the back-end share. Then choose another back-end path with the filer command, or use no share to remove the share from the volume.
To restart the import (with or without this share), use nsck ... rebuild volume to reimport all shares in the volume.
Someone attempted to remove a share (with no filer, no share, remove-share migrate, remove-share nomigrate, or remove service), and an internal error caused the removal to fail. Contact F5 Support if you see this message.
The connection to the back-end CIFS share failed due to possible configuration errors or a broken connection to the back-end filer. Use the show exports command, expect traceroute, and/or ping to troubleshoot the connection to the filer. Once the connection is fully established, you can restart the share import with the enable (gbl-ns-vol-shr) command.
Once the filer issue is corrected, use nsck ... rebuild volume to reimport all shares in the volume.
A CIFS-permission test failed at the filer for an undetermined reason. This may be a filer issue or a connectivity issue. Check the filer and the connection, and retry the share import (with enable (gbl-ns-vol-shr)). If this error stops the import a second time, run the collect diag-info CLI command to collect diagnostic information and contact F5 Support.
(CIFS) A file on this share has the same name and path as a file on an already-imported share, based on a case-blind comparison, and the volume is configured with no cifs case-sensitive. That is, some of the characters have differing cases, but the characters match (for example, index.htm matches index.HTM). If the volume is not case-sensitive, it cannot see the difference between the two names.
Set the modify flag on this volume. By setting the modify flag, you allow the volume to rename the file on import. You must wait for all the volumes shares to finish importing before you can use this command.
Use cifs case-sensitive to make the volume case-sensitive.
Then retry the import with the enable (gbl-ns-vol-shr) command.
An administrator stopped the import with the cancel import command. You may be able to restart the import with no enable (gbl-ns-vol-shr) and then enable. If the import was stopped too far in the process, you must first use nsck ... destage to shut down the volume, remove and re-add the share, then enable the volume again.
Internal problem; contact F5 personnel.
No imports are possible unless the volume is enabled. Use the enable (gbl-ns, gbl-ns-vol) command to enable the volume.
The metadata share for the volume failed to import. Use metadata share to designate a new dedicated share for metadata.
An administrator stopped the share removal with the cancel remove command. To restart the removal process, use remove-share migrate, remove-share nomigrate, no share, or no filer.
The import process was interrupted by an nsck ... rebuild force. The rebuild operation will re-import the share.
DNAS, the internal name for volume software, is shutting down. This may be the result of administrative action, such as a remove service, during the import. The volume has stopped running, so the import is canceled.
Use the filer command to assign a filer to the share, then retry the import.
bstnA(gbl)# namespace wwmed
Use the remove-files migrate command to migrate all files and directories to another share before removing it from the volume. This command was described above; see Removing an Imported Share.
bstnA# remove-share migrate wwmed /acct budget bills
To keep imported directories in the volume but remove any of the shares imported files, use the remove-files nomigrate command. This was described in Removing Shares Without File Migration. This moves all of the shares master directories into another share in the same volume, then removes the share from the volume. Any imported files disappear from client view.
bstnA# remove-share nomigrate wwmed /acct budget bills
To remove all traces of the share, you must remove all of the shares directories from the volumes directory tree. This is a serious change in the volumes metadata, and it requires that you take the volume offline. Use nsck ... destage to take the volume offline (recall De-Staging a Single Volume), remove the share from the volume, then re-enable all of the volumes remaining shares (as shown in Enabling All Shares in the Volume, on page 9-54 of the storage-management manual).
bstnA# nsck wwmed destage volume /acct
bstnA# global
bstnA(gbl)# namespace wwmed
bstnA(gbl)# namespace wwmed
bstnA(gbl-ns-vol-shr[wwmed~/acct~budget])# filer das1 nfs3 /exports/budget
The entire volume fails if its metadata-share fails or if its only share fails. In either case, you use nsck ... rebuild volume to delete the volumes metadata and completely rebuild it (as described in Rebuilding a Volume).
Important: This is service-affecting in the same way as nsck ... destage, described above.
bstnA# nsck wwmed rebuild volume /it
remove service namespace [timeout seconds] [sync]
namespace (1-30 characters) is the namespace to remove,
seconds (optional, 300-36,000) sets a time limit for the removal of each namespace component, and
sync (optional) waits for the removal to finish before returning. With this option, the CLI lists the namespace and global-server components as it removes them.
This operation generates a report, remService_namespace_date.rpt, which catalogs all of the actions that it took. The namespace in the file name identifies the removed namespace, and the date is the date and time when the command started. The CLI shows the report name after you invoke the command. Use show reports to see the file listing; use show, tail, or grep to read the file. To save the report off to an external site, use the copy ... ftp or copy ... scp command from priv-exec mode.
The command does not create the report if you use the sync option; it shows its actions at the command line instead.
bstnA# remove service medco
bstnA# show reports remService_medco_201002240751.rpt
You can use a single command to remove all rules, share farms, and other policy objects from a namespace. The remove namespace command has been described in the ARX® CLI Storage-Management Guide: see Removing a Direct Volume, on page 8-31, Removing a Managed Volume, on page 9-68, or Removing a Namespace, on page 7-26. Add the optional policy-only keyword to remove only the policy objects:
remove namespace name policy-only [timeout seconds] [sync]
name (1-30 characters) is the name of the namespace,
policy-only is the option to remove only the policy objects,
seconds (optional, 300-10,000) sets a time limit on each of the removals component operations, and
sync (optional) waits for the removal to finish before returning. With this option, the CLI lists the policy objects as it removes them.
The CLI prompts for confirmation before removing the policy objects. Enter yes to continue. This operation generates a report named removeNs_namespace_date.rpt if you omit the sync option.
prtlndA# remove namespace insur_bkup policy-only timeout 600 sync
The optional volume argument focuses the remove namespace command on one volume:
remove namespace name volume volume policy-only [timeout seconds] [sync]
name (1-30 characters) is the name of the namespace,
volume (1-1024 characters) is the path name of the volume,
policy-only is the option to remove only the policy objects, and
seconds (optional, 300-10,000) sets a time limit on each of the removals component operations, and
sync (optional) waits for the removal to finish before returning, as described above.
bstnA# remove namespace insur volume /claims policy-only
file-name is the files original name, without its extension (for example, myfile from myfile.doc),
share is the name of the namespace share,
jobid is an integer identifying the job that imported the share, and
.ext is the files original extension (for example, doc), if there is one.
where index is a number starting at 1.
bstnA(cfg)# show reports type Imp
Use show reports file-name to view the import report. A collision appears in the File Scan Phase section, with a Type of R (Rename) and NC (name collision). For example, the following report shows three collided files (highlighted in bold):
bstnA(cfg)# show reports import.3.bills2.7.rpt
base-name[.ext]
base-name is 1-8 characters,
. is optional, and
ext is 1-3 characters.
Newer Windows servers run NTFS, which supports file and directory names of any length. Other file systems that support CIFS also support names of any length. For backwards compatibility, these contemporary file systems continue to support an alternate 8.3 name for any file or directory that does not fit the above pattern. The alternate name is sometimes called a filer-generated name (FGN) since it is created by the filer. The longer name is called the primary name. Contemporary Windows clients see the primary name while older Windows applications see only the alternate name, the 8.3 FGN. Contemporary applications can use either name to access the file or directory, though, by default, they do not see the alternate name.
name-with-tilde (2-8 characters) has one tilde (~) character (such as RANDOM~2), and
ext is optional and has 1-3 characters.
name-without-tilde (exactly 8 characters) has no tilde (~) character (such as 0000D773), and
ext is optional and has 1-3 characters.
Run an nsck-inconsistencies report (recall Finding Metadata Inconsistencies) to identify 8.3 name collisions. Each file with this issue is flagged with F8, and each directory is flagged with D8.
bstnA# nsck medarcv report inconsistencies /rcrds outputfile rcrdsIssues
bstnA# show reports rcrdsIssues.rpt
The volume also blocks some client operations inside a directory with a trailing-period name. For example, creating the file, \myvol\mydir.\newFile.txt, could fail because of the period at the end of the parent directorys name, \mydir.. The volume would block this if it meant that the volume would have to replicate \mydir. on a filer that would change it into an FGN.
The final case is subtle, and may require a search through the syslog file (recall Accessing the Syslog) to prove that a trailing-period is at fault. Search for the string TRAIL for syslog messages about illegal trailing periods. Use grep TRAIL logs syslog to search for messages about trailing periods, or grep ip-address logs syslog to find all messages concerning a client at ip-address.
bstnA# show reports import.6.charts.12.rpt
You can use the show namespace command to find if a particular share converts trailing-period names into FGNs: the no-trail-period flag appears in the shares Features field.
bstnA# show namespace swic volume /users share samba1
file migrations through file-placement rules (see Placing Files on Particular Shares, on page 14-4 of the ARX® CLI Storage-Management Guide),
file or directory replications to a shadow volume (see Configuring a Shadow-Copy Rule (Source Switch), on page 16-9 of the same manual).
NFS-only entries, under rare circumstances, can also impede volume performance. The volume does not record any FGNs from its filers; instead, it probes for FGNs only when a collision with an FGN is possible. An FGN collision can only occur in a directory that has one of two problems: either it contains NFS-only entries, or it contains a name that matches an FGN pattern (like FILE~2.txt).
If CIFS clients complain about access issues or slow performance, you should identify the NFS-only entries in the volume and work toward changing their names. This is especially true for directory names, which can obscure multiple files and directories from CIFS users. Run an nsck-inconsistencies report with the multi-protocol flag (recall Focusing on Multi-Protocol Issues) to reveal all NFS-only file names and directory names. Each of them is flagged with an NF. For example, this command sequence generates and shows an inconsistencies report for the insur namespace, which reveals several NFS-only files and directories:
bstnA# nsck insur report inconsistencies multi-protocol outputfile insur_fgns
bstnA# show reports insur_fgns._claims.rpt
A case-blind collision occurs when two or more entries in the same parent directory have names that differ only in case (for example, index.html and INDEX.html). CIFS does not support case collisions, but NFS does. These are created by NFS clients, either before import or while the volume is in service.
(!) nnn_changed-file-name
''(!) '' (with the trailing space) is the prefix for all AGNs.
nnn is a different number for every AGN in this directory. This number is padded so that it is always at least three digits long.
changed-file-name is the original file name (or directory name), with all illegal characters replaced with an underscore character (_).
Some illegal file or directory names may have been created by CIFS clients before import. CIFS natively supports all Unicode characters in its file or directory names, but NFS servers must specifically have their character encoding configured to support them. Otherwise, many Unicode characters are non-mappable to NFS. A multi-protocol filer set for Latin1 character encoding may have allowed CIFS clients to use Unicode characters (such as Korean or Japanese characters) in entry names. If so, the filer accepted the CIFS name and created an FGN for its NFS clients.
where C is a character that is not supported by the filers NFS character encoding.
[ NI NM ] [shr1-old ] /images/file012b/ (Characters: U+012b)
new-dirname_share-jobid[-index][.ext]
where new-dirname is the original CIFS-side name, but with (U+nnnn) in place of each unmappable character. The nnnn is the Unicode number for the character, shown in hexadecimal format. The name is truncated if it exceeds 256 characters. For example, dir(U+30D2)(U+30AA)_myshare-2.
Any NFS-only directory is called a split directory. All descendents of split directories are flagged with an SP in the inconsistencies report; they are flagged because they are inaccessible to CIFS clients. For example, here is a split directory and its descendents:
[ SP] [shr1-old ] /tools/extractCdDocs.pl
[ SP] [shr1-old ] /tools/cleanBU.csh
Some multi-protocol directories are marked in the metadata for FGN-collision checking. A directory is marked for this processing if it contains entries with either of the following name issues:
If the directory contains either of these name types, the volume must check for FGN collisions every time a client creates a name of the other type. The FGN-collision check was described earlier, in Performance Issues. This check occurs for all types of clients, including the policy engine; that is, the volume also performs extra checking before migrating any FGN-related files or subdirectories from one back-end share to another.
Another disadvantage for a marked directory can be extra back-end copies (called stripes) for some of its NFS-only subdirectories. Before the policy engine migrates any NFS-only file (such as newFile in a directory that already contains NEWFILE), it stripes all of its subdirectories that fit an FGN pattern (such as DIR~3) to the target share. Then it migrates the file. This ensures that the subdirectories remain open to both CIFS and NFS. It also creates extra, unexpected directory stripes on the back-end target share.
After the rename(s), you must run the sync files ... recurse command to remove the NFS-only flags from the volumes renamed files and directories. The sync utility probes all of the volumes shares to confirm that no FGN collisions exist. This also removes the marks from any directories that no longer contain any NFS-only entries. The sync files command was described in an earlier chapter: recall Synchronizing Metadata with Actual Files.
bstnA# sync files insur volume /claims path / recurse
All file migrations are concerned with file attributes in addition to the files themselves. File attributes are permission settings, the name or ID of the user who owns the file, the group or groups who have access to the file, last-modified times, named streams, and other external data associated with the file. File-attribute migrations require special semantics in a multi-protocol namespace (that is, a namespace whose shares support both NFS and CIFS access). If your namespace is NFS-only or CIFS-only, you can skip this section.
If the ARX migrates the filer from Filer X to Filer Y (made by two different vendors), it takes these different semantics into account. This ensures that the NFS and CIFS file attributes are preserved as much as possible as they are migrated from one vendor to another. In some cases, file attributes are interpreted differently on the destination filer. The sections below share the details of attribute migration.
copied, then reset after file is transferred through CIFS
all copied after SD
copied, then reset after file is transferred through CIFS
copied after UNIX attributes
all copied after SD
copied after UNIX attributes
copied, then reapplied after the file is transferred through CIFS
From any mode, you can use the show policy history command to show all of the policy transactions for a given managed volume:
show policy history namespace namespace volume vol-path
namespace (1-30 characters) is the namespace, and
vol-path (1-1024 characters) identifies the volume to examine.
bstnA(gbl)# show policy history namespace wwmed volume /acct
show policy history namespace namespace volume vol-path rule rl-name
namespace (1-30 characters) is the namespace,
vol-path (1-1024 characters) identifies the volume to examine, and
rl-name (1-1024 characters) is one rule or share farm.
bstnA(gbl)# show policy history namespace wwmed volume /acct rule docs2das8
bstnA(gbl)# show policy history namespace wwmed volume /acct rule fm1
Any files that are waiting to be migrated appear in the policy queue. Use the show policy queue command to see if any migrations are pending:
show policy queue namespace namespace volume vol-path
namespace (1-30 characters) is the namespace, and
vol-path (1-1024 characters) identifies the volume to examine.
bstnA# show policy queue namespace medarcv volume /rcrds
To see all files that are currently held closed, add the auto-close option to the end of the show policy queue command:
show policy queue namespace namespace volume vol-path auto-close
bstnA# show policy queue namespace medarcv volume /rcrds auto-close
cancel migration namespace volume vol-path
namespace (1-30 characters) identifies the namespace, and
vol-path (1-1024 characters) is the managed volume with pending migrations.
bstnA# cancel migration insur volume /claims
where file-name (1-1024 characters) is a full virtual path to the file, including the path name of the managed volume that contains it. This is the file path that clients see.
bstnA# cancel migration file /claims/y2kclaims/artwork/bigpict.tif
The nsck... report inconsistencies command compares the attributes of the master directory to the attributes of each secondary directory and reports any discrepancies.
The nsck... report inconsistencies command also compares the state of striped directory attributes to the inconsistent-attributes flag in the metadata. Any discrepancies that are found are reported.
Use the nsck... sync directories command to synchronize inconsistency directory attributes.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)