Applies To:

Show Versions Show Versions

Release Note: ARX version 4.0.1
Release Note

Updated Date: 08/29/2013


This release note documents the version 4.0.1 release of the ARX software. We recommend this maintenance release for those customers who want the fixes and enhancements listed in Fixes and Enhancements in This Release.

This release is cumulative, and includes all fixes and enhancements released since version 2.6.0. You can apply the software upgrade to 2.6.0 and later. For information about installing the software, please refer to Installing the Software.

Note: F5 offers both feature releases and maintenance releases. For more information about our release policies, refer to Description of the F5 Networks software version number formats.


- User Documentation for This Release
- Minimum System Requirements and Supported Browsers
- Supported Platforms
     - New/Updated Certifications
     - Filers Supported for ARX Snapshots
- Installing the Software
     - Firmware Upgrade Required for NSM Features
- Fixes and Enhancements in This Release
     - Enhancements
     - Fixes
- Fixes and Enhancements in Prior Releases
     - Version 4.0
     - Version 3.2.0
     - Version 3.1.0
     - Version 3.0
     - Version 2.7.1
     - Version 2.7.0
     - Version 2.6.0
     - Version 2.5.2
     - Version 2.5.1
     - Version 2.5.0
- Required Configuration Changes
- Known Issues
- Contacting F5 Networks

User Documentation for This Release

In addition to these release notes, the following user documentation is relevant to this release.

These manuals are available from the ARX® GUI or CLI. From the GUI, click on the Documentation link in the navigation panel. From the CLI, use the show software command for a complete listing of the ARX manuals, then use the following command to upload the manual from the ARX:

copy software manual-name destination-url

You can also find the product documentation on the AskF5 Technical Support web site, along with an extensive solutions database.

[ Top ]

Minimum System Requirements and Supported Browsers

The supported browsers for the ARX GUI are:

  • Microsoft® Internet Explorer®, version 6.0
  • Mozilla® Firefox® 1.5, and other browsers that use the Mozilla engine
[ Top ]

Supported Platforms

This release supports the following hardware platforms:

  • ARX®500
  • ARX®1000
  • ARX®4000
  • ARX®6000
[ Top ]

New/Updated Certifications

There are no new Certifications for Release 4.0.1.

For Release 4.0, F5 Data Solutions tested and qualified the following 10-gigabit-networking devices with the ARX®4000:

  • F5 BigIP
    10GBASE-SR JDS Uniphase XFP F529937700F4
  • Cisco 4948
    Cisco X2 SR 10-gig Module
  • Force 10 S50N
    10-gig SR Module
  • SMC 8708L2
  • Chelsio NIC
    10GBASE-SR Intel XFP MYBG69N90U
  • Extreme 10G4Xa
    10GBASE-SR Intel SR XFP MYBG71G81W
  • Intel NIC
    10GBASE-SR Infineon XPAK 01564948
  • Netgear GSM7328S
    10GBASE-SR Netgear XFP SR AXM751
  • Netirion NIC
    10GBASE-SR Infineon XPAK 01564948
  • Nortel 5530-24TFD
    10GBASE-SR Intel SR XFP MYBG71G81W
  • Nortel 4526GTX-PWR
    10GBASE-SR Intel SR XFP MYBG71G81W
  • Procurve 2900
    10GBASE-SR Procurve X2 DE523RQ001
  • Procurve 3400
    10GBASE-SR Procurve X2 DE523RQ001
  • Procurve 3500
    10GBASE-SR Procurve X2 DE523RQ001
  • Procurve 4205
    10GBASE-SR Procurve X2 DE523RQ001
  • Procurve 5400
    10GBASE-SR Procurve X2 DE523RQ001
  • Procurve 8100
    10GBASE-SR Procurve X2 DE523RQ001

In Release 3.0, F5 Data Solutions has certified IBM NAS 500G file servers.

Filers Supported for ARX Snapshots

An ARX volume can coordinate snapshots amongst the filers behind it. This ARX-snapshot feature supports the following filer-software releases:

  • EMC v5.4 or newer, and
  • Netapp OnTap Release 6.5.* or newer. NTAP VFILER is also supported.

All other filers not explicitly listed above are not supported. When the snapshot subsystem attempts a snapshot on an unsupported filer, the error is written to the report and the ARX syslog.

[ Top ]

Installing the Software

For an existing installation, you can upgrade to 4.0.1 from any of the following releases:

  • 4.0
  • 3.2.0
  • 3.1.0
  • 3.0
  • 2.7.1
  • 2.7.0
  • 2.6.0

For installation instructions, refer to the Upgrading Software chapter in the CLI Maintenance Guide.

This release also includes a new version of firmware. You can upgrade the firmware during the software upgrade; the instructions in the above manual explain how and when to upgrade the firmware.

[ Top ]

Firmware Upgrade Required for NSM Features

As mentioned above, this release includes a firmware upgrade. If you are upgrading from Release 3.0 or earlier, the new firmware supports NSM recovery and NSM binary-core files. The NSM recovery feature allows an NSM processor to recover after a failure without necessarily rebooting the entire ARX. After you upgrade the firmware, you can use the nsm recovery CLI command to enable failovers between NSM processors. Refer to the "Preparing for NSM Recovery and Diagnosis" chapter in the CLI Network Guide for full details about the NSM-recovery feature and the nsm recovery command.

Warning: You must reboot the ARX to enable the NSM-recovery feature. If you have a redundant pair of ARXes, enable NSM recovery on the backup ARX first, then enable it on the primary ARX (causing a failover to the backup) during off hours. A standalone ARX endures a longer service outage as the ARX reboots; for this reason and others, we recommend redundant ARXes for sites that support extensive client traffic.

[ Top ]

Configuration Changes

Once you install the software, refer to the Required configuration changes section, which contains important information about changes you must make before using the new software.

[ Top ]

Fixes and Enhancements in This Release

This release includes the following fixes and enhancements.


Release 4.0.1 is functionally equivalent to Release 4.0. Unlike Release 4.0, this release has been fully qualified for use on the ARX®6000 as well as all the other ARX platforms.


Release 4.0.1 fixes the following software issues:

If an ARX runs active VPUs on both redundant peers (configurable only on earlier versions of ARX software), The CLI or GUI may show incorrect used-file credits for those VPU(s).

An NFS-access list with more than 128 IP addresses can cause the ARX to repetetively reboot if it is used in a presentation (or "direct") volume's attach point.

The ARX4000 allows the Control Plane to power up when the Data Plane is powered off and/or disconnected. This is an unsupported configuration that causes a software loop and prevents the ARX from fully booting.

If a client reads or writes a file with a particular byte sequence through an ARX4000 VIP, the ARX stops processing client traffic.

Note: The fix for this bug does not resolve the problem for an ARX4000 that supports jumbo frames. (You can enable or disable jumbo frames with the [no] jumbo mtu CLI command.)

A presentation (or "direct") NFS volume reports incorrect free space.

A managed volume prematurely disconnects from an unresponsive back-end filer. If the filer connection improves, this unnecessarily extends the time that ARX clients cannot access the filer's storage.

Downgrading from a 3.aa.bbb release to a pre-3.0 release triggers a re-import of all managed-volume shares on the ARX. This only occurs in a redundant pair of ARXes, where the peer is still running the pre-3.0 release. This can occur during an unsuccessful upgrade.

A managed volume may lose its NFSv3/TCP connection while importing from an EMC Celerra.

A CIFS volume may create a hidden-subshare name (for example, "_acopia_dir5_3$") on a back-end filer, and then record it incorrectly in its database. The volume is then unable to find the back-end subshare(s). This only occurs for subshares that are exported with the hidden or expose-hidden option.

A multi-protocol (CIFS and NFS) volume does not support NTFS QTrees as back-end shares if they run on NetApp Release 7.2.4.

If a CIFS client attempts to access "\\vip\C$\~snapshot" in a namespace that supports both Windows management (MMC) and snapshots, the namespace software fails. The "C$" share is a virtual share offered for Windows-management access (for example, through MMC). The "~snapshot" directory is a virtual directory for accessing snapshots within an actual share, but does not offer any snapshots in the virtual "C$" share.
For example, suppose the volume(s) in a CIFS namespace is/are shared through a CIFS service at (a virtual-IP address, or VIP). If a client maps the "G" drive to \\\C$ and then starts working in the "G:\~snapshot" directory, the namespace behind the VIP fails.

[ Top ]

Fixes and Enhancements in Prior Releases

The current release includes the fixes and enhancements that were distributed in prior releases, as listed below. (Prior releases are listed with the most recent first.)

Version 4.0

This section describes the features and fixes from release 4.0. Sites that upgrade from release 3.2.0 and earlier get the benefit of all the features and fixes described here, in addition to the features and fixes described above.


Release 4.0 adds the following features:

Release 4.0 supports the new ARX®4000 hardware platform, which is a 4U device with 10-gigabit interfaces. The ARX®4000 has storage capabilities equal to the larger ARX®6000 with 2 ASMs and 2 NSMs.

Passive LACP
The Link Aggregation Control Protocol (LACP, defined in IEEE 802.3ad) dynamically manages the member ports in a channel. For example, if a configuration change disqualifies a port for channel membership, LACP processes automatically detect the change and stop using the port in the channel. Release 4.0 supports passive LACP, which you can configure with the lacp passive CLI command. Refer to the Layer-2 chapter in the CLI Network Guide for details on LACP and LACP configuration.


Release 4.0 fixes the following software issues:

Deploying switches via template doesnt work with configuration order.

Major inconsistencies revolving around the volume hosting home directories.

When l2 failed on the senior switch, it detected a remote metalog error and causes the junior switch to fail. Since the senior is already rebooting due to the l2 failure, this causes a dual reboot.

Cannot identify volumes using namespace-level metadata.

CIFS AD forest names and Windows domain names are case-sensitive and should not be.

GUI virtual services page does not display "joined" when no exports exist.

A planned ARX reload during a large NTP-time skew can result in an unplanned reboot later.

Remove-share nomigrate incorrectly requires "force" on failed import share. The "remove-share nomigrate" command used by the GUI and from priv-exec at the CLI required the "force" option to remove a share that failed import.

A global server that references only disabled volumes can consume 99% of the CPU.

Scripted creation of a VLAN in the ARX4000 CLI may fail.

Policy is unable to move files from one share to another. When looking at the shares in the managed volume, freespace is being reported ok, yet when a place rules is enabled, policy is unable to move files.

Can't find active partition in config file.

On the ARX4000, if the data plane is powered up after the control plane, the reload CLI command reboots the control plane but not the data plane.

Cryptic error message needs to be more helpful. Superfluous text removed.

Under cifs-service, the vol-path in the exports command is case-sensitive.

If an NSM core has failed, nsm recovery is disabled, and you create a new CIFS service, the service cannot get past the "Starting" state.

Version 3.2.0

This section describes the features and fixes from release 3.2.0. Sites that upgrade from release 3.1.0 and earlier get the benefit of all the features and fixes described here, in addition to the features and fixes described above.


Release 3.2.0 added the following features:

Microsoft Windows VSS (Previous-Versions) Support for ARX Snapshots
Windows offers an interface called Volume Shadowing Service (VSS) (called "Previous Versions" in Windows Vista) for accessing snapshots. Clients can select a file or directory from their Windows Explorer, pull up the Properties sheet, and click on the Previous Versions tab. This tab displays all snapshots for the chosen file or directory. As of Release 3.2.0, a managed volume that supports snapshots can offer them through VSS.

Automated Controls for CIFS-Accessible File/Directory Names Ending In "." (28630)
Trailing spaces and periods (for example, "myFile.txt." or "myDirectory ") are illegal for most implementations of CIFS, though they are supported by the filesystem under Windows. Some CIFS vendors convert any file or directory names with trailing periods into Filer-Generated Names (FGNs). In Release 3.2.0, a managed volume probes its back-end shares for this behavior and prevents any trailing-period names from migrating to those shares. Refer to the CLI Maintenance Guide for more information on illegal trailing characters in CIFS volumes.

ARX Secure Agent Support for 64-Bit Windows 2003 DCs
The ARX Secure Agent (ASA, described in Secure Agent Installation) now runs on 64-bit Windows 2003 DCs. There are no functional changes to the ASA.


Release 3.2.0 fixed the following software issues:

NSM runs out of memory and crashes.

If a CIFS client joins a new Windows group while connected to an ARX-CIFS service, the client must disconnect from the ARX service and remain disconnected for at least 10 minutes to get the group's access permissions.

The standby ARX sends redundant Kerberos-DC traps (kerberosDCOffline and/or kerberosDCOnline) after the active ARX already sent them.

The snapshot manage command causes the ARX to reboot if it runs on a CIFS volume with a particular configuration issue. The issue is that the actual share name (for example, "MYSHARE") has different case from the one defined in the ARX volume (for example, "MyShare"). In the CLI, you define the share name with the gbl-ns-vol-shr filer command.

Microsoft-Explorer users cannot write to an empty Properties -> Summary tab for a file or directory in an ARX volume.

The GUI allows only 64 bytes in the name of a front-end-export, while the CLI correctly allows up to 1,024 bytes.

If a file-placement rule has spaces in its name, its report name does not have quotation marks ("") around it in the global-config. Without the quotation marks, the report command fails when you run the global-config in the CLI.

If a shadow-copy rule's configuration changes while it is running, the rule pauses indefinetely.

A shadow-copy rule, under rare circumstances, causes a shadow-database corruption at the shadow volume.

If a tentative file-placement rule has a share farm as its target, the rule causes all newly-created files in the share farm to gravitate to a single back-end share.

If you perform a no share or no filer command using the force argument and omitting the remove-file-entries option, all files on the removed share remain in the volume's metadata. This leaves the files visible to clients even though they are inaccessible.

On the originally-junior switch in a redundant pair, you cannot disable or enable a virtual service from the GUI's Virtual Service summary screen.

The ARX is not sending shareOnline traps for NFS shares with import errors.

A volume with the cifs path-cache feature may fail and produce a core file.

Given the following circumstances, an ARX-CIFS volume fails and produces a core file:

  • two back-end shares ("SHARE_A" and "SHARE_B") have subshares whose paths differ only in case (for example, "\\SHARE_A\topDir\nextDir" and "\\SHARE_B\TOPDIR\NEXTDIR"),
  • both subshares are exported with the same share name ("NEXTDIR"),
  • both shares ("SHARE_A" and "SHARE_B") are imported into the same ARX volume, and
  • the ARX volume has filer-subshares enabled.

The volume failure occurs on import if filer-subshares is already enabled before the import, or when filer-subshares is activated later on the already-running volume (for example, with the cifs export-subshares CLI command).


If you disable a share in a CIFS volume with filer-subshares, you cannot re-enable the same share later.

Windows Explorer's VSS (or "Previous Versions") feature does not function in a CIFS subshare exported from the ARX; no snapshots appear under the "Previous Versions" tab in Windows Explorer.

The GUI's Collect Diag-Info operation (invoked with an action button on the Maintenance screen) does not create a "cli_show.log" file.

Changes to the quorum-disk configuration, such as a change in the IP address of the quorum-disk filer, do not take effect.

Multi-protocol managed volumes do not support EMC filesystems with an "accesspolicy=MIXED" setting.

A file-placement rule does not recover from the "Failed" state if the volume stops in the middle of a placement run.

If an ARX volume has a CIFS metadata share, client access is slowed by removing a storage share from the volume (for example, with the remove-share CLI command).

30515, 30462
A remote processor times out waiting for a "watchdog" response from an ASM processor, resulting in an unplanned reboot (and, in a redundant pair, a failover).

You cannot stop and restart the GUI on the backup switch in a redundant pair.

A path or match CLI command can cause continuous reboots if you use both of the following in the command string (or the its GUI equivalent):

  • the optional ignore-case flag, and
  • a wildcard string that contains UTF-8 characters.


A CIFS managed volume with cifs path-cache enabled may create malformed Query-Path-Info packets for named streams. A CIFS client can only trigger these malformed queries in a front-end share of a subdirectory (not the root) of the ARX volume.

A volume with cifs path-cache enabled has slow performance during busy times.

Version 3.1.0

This section describes the features and fixes from release 3.1.0. Sites that upgrade from release 3.0 and earlier get the benefit of all the features and fixes described here, in addition to the features and fixes described above.


Release 3.1.0 added the following features:

Maximum CIFS Exports Increased from 9,000 to 16,000 (28867)
As of Release 3.1.0, the ARX can support a total of 16,000 CIFS front-end shares.

Add Drive Letter to MSRPCs that Require It (28337)
Some Microsoft Remote Procedure Calls (MSRPCs) require a file or directory path in their returns. Prior to release 3.2.0, the ARX omitted the drive letter from these returned paths; now a CIFS service includes the drive letter if it has browsing enabled.

Full NSM Core Dumps
You now have the option to enhance the core-dump files produced by a failed NSM processor. By default, a failing NSM processor produces an ASCII-text file with its current state. The new nsm binary-core-files CLI command enhances the files to a much-larger binary format, with more information that F5/Acopia® engineers can use for diagnosing the cause of the failure.

Faster Failover Times (28901)
The 3.1.0 release includes enhancements in failover times between redundant ARXes. Lab testing has shown failover times that have improved from 34 - 60%.

Enhancements to CLI "show health," GUI "Status," and E-mail Notifications (27313, 26514)
The SNMP-based indicators of ARX health now offer better support for redundancy features. New indicators notify you of NSM-core failovers, ARX failovers, and quorum-disk failures. These indicators appear in the CLI's show health command, the GUI's "Status" screen (under "System Health Information"), and in E-mail notifications.

The CLI "wait-for migration" Command is Fully Supported
The CLI command, wait-for migration, was formerly accessible only if the terminal beta flag was raised. As of release 3.1.0, this command is fully qualified, accessible, and documented.

Timeout Option for all CLI "expect" Commands (26737)
Every CLI expect command now has a timeout option, which sets a time limit on the operation. The CLI documentation contains the full syntax.

Reload Option for the CLI "clear nvr" Command (28697)
In previous releases, the clear nvr command halted the chassis at the end of the operation, so that you had to turn the power back on manually. This was designed for preparing the chassis for shipment. In 3.1.0, you have the option to reload the chassis instead of halting it.

Beta Option: Defer Setting "Trust for Delegation" During a Domain Join Operation
If an ARX-CIFS service supports Kerberos authentication, you must perform a domain-join operation to join the service to an Active-Directory domain. The CIFS Service must also have "Trust Computer for Delegation" set at the domain controller. By default, the CLI domain-join command (and its GUI equivalent) requires a username and password with sufficient credentials to set the "Trust Computer for Delegation" flag at the DC. The 3.1.0 release offers a beta option to avoid setting the flag from the ARX:

domain-join domain-name no-trust-for-delegation

You can use lesser credentials to run the command with the no-trust-for-delegation flag raised, then log onto the DC with stronger credentials and raise the flag from there.

This is a beta option that has not been fully qualified. You must use the terminal beta command from the CLI to enable this and other beta features.


Release 3.1.0 fixed the software issues below. Fixes for these issues are also included in the current release:

A cryptic error appears in the shadow-copy report when the source volume is undergoing an nsck ... rebuild.

When an import fails for a CIFS share with a corrupt file system, the show namespace command shows an uninformative import error: "...DTFS Operation has error status [-51]."

If you remove a CIFS export at the same instant that the backup ARX reboots, the ARX may incorrectly remove all CIFS exports.

The ASM occasionally hangs during a firmware upgrade operation.

The show exports command may spuriously indicate a successful mount on an NFS share that the ARX cannot import.

The show exports external-filer filer-name command defaults to a spurious IP address,, if the ARX definition for filer-name has an undefined IP address. The command should return an error instead of defaulting.

A busy ARX may emit spurious shareOffline traps for shares named "acopia#:...". These shares are internal to the ARX, and should not be reported in SNMP traps.

If a back-end filer uses NFS filehandles that do not align with four bytes (that is, the number of bytes is not evenly-divisible by four), the ARX may reboot repetitively. Only unsupported NFS filers, such as those from Permabit, use NFS filehandles that cause this problem.

A redundant pair of ARX6000s cannot join if the redundancy link has excessive latency; the backup switch repeatedly reboots without ever fully joining its peer.
Solution: For sites with great distances between ARX6000 peers, F5 Support can extend the redundant pair's tolerance for a long latency.

An inconsistencies report (invoked with the nsck ... report inconsistencies CLI command) occasionally misses some replica-leaf directories that it should have recorded as "SD" entries.

A file-placement rule stops scanning directories if a filer returns a serious scan error (such as "path too long") for a single directory.
Solution:: The rule now logs the failed directory in its show policy statistics and continues the scan. The rule retries all such failed directories after the scan is otherwise complete, and marks the rule as "failed" if the scan errors persist.

If a direct volume "attaches" to a managed volume at the same time a client disconnects from the same managed volume, an NSM processor may fail.

In some cases, a CIFS service does not support both NTLM and Kerberos authentication in the same CIFS-client session.

Under rare circumstances, NFS/TCP clients are briefly blocked out of a managed volume if any direct volume in the same VPU Domain is "attached" to it.

The copy reports command (or its GUI equivalent) truncates reports larger than 2GB.

Version 3.0

This section describes the features and fixes from release 3.0. Sites that upgrade from release 2.5.2 and earlier get the benefit of all the features and fixes described here, in addition to the features and fixes described above.


Release 3.0 provided the following features and enhancements:

Snapshot integration (CIFS only)
Release 3.0 provides the ability to manage the generation, removal, and scheduling of periodic snapshots on a per ARX virtual volume basis across heterogeneous filers. Additionally, the ARX can control access and presentation of snapshots.

  • Release 3.0 does not support Microsoft VSS or Shadow Copies for Shared Folders.
  • Release 3.0 does not support NFS snapshot support beyond what is currently supported with direct (presentation) volumes.

Automatic Volume Sizing (AVS)
With AVS, the number of reserve files is automatically set to 4 million files when an ARX managed volume is created. The reserve file limit is automatically increased by 4 million files every time the number of available file credits falls below 2 million. AVS is automatically disabled if the new required limit exceeds the maximum number of reserve files supported within the managed volume or VPU. For information on the maximum file limits supported per ARX platform, see the Site Planning Guide.

Auto Close File Migration
Prior to 3.0, the ARX policy engine would not migrate CIFS files that remained persistently open. The policy engine attempted to migrate an open file for a fixed number of retries. If unsuccessful, the policy rule proceeded to the next file. When complete, the policy engine marked the rule as "FAILED" and generated a report indicating which files where not migrated.

With Release 3.0, you can optionally configure a file-placement rule to automatically close any file opened by a CIFS client. The policy engine holds the file closed until it has finished migrating or until the migration request is cancelled.

SNMP Traps and E-Mail Notifications
The smtp welcome command was added to send an introductory (welcome) E-mail to all members in an email-event group. The introductory message informs the recipients of the types of system events they will be receiving through E-mail.

A description field was added to the email-event command.

The warmStart trap has been modified to append the cause of reboot in the message text (traplog and email). All reboots are now recorded in the reboot history log file. The SNMP trap text has not been changed.

Robust SID Translation
Prior to 3.0, mis-translation of Security Identifiers (SIDs) could occur if local and domain groups had the same names. With V3.0, the SID translation algorithm has changed so that only locally-defined user and group SIDs are subject to translation. This enhancement permits identical user and group names to be defined both locally on a file server and within an Active Directory domain.

CIFS Sub-Share ACL improvements
Prior to V3.0, with CIFS sub-shares enabled, an ARX managed volume did not support multiple CIFS shares on the same filer. V3.0 removes this limitation, and enables migration, tiering, load balance share farms on a single file server where CIFS sub-shares are configured.

CIFS AD Forest-to-Forest Trusts
In a Windows 2003 Active Directory forest, you can link two disjoint Windows 2003 forests together to form a one-way or two-way trust relationship. A two-way forest trust is used to form a transitive trust relationship between every domain in both forests.

Forest trusts can provide the following benefits:

  • Simplified management of resources across two Windows Server 2003 forests by reducing the number of external trusts necessary to share resources.
  • Complete two-way trust relationships with every domain in each forest.
  • Use of user principal name (UPN) authentication across two forests.
  • Use of Kerberos V5 and NTLM authentication protocols to improve the trustworthiness of authorization data transferred between forests.
  • Flexibility of administration.

V3.0 allows for support for CIFS Kerberos authentication across Windows 2003 two-way (or bi-directional) forest-to-forest trusts.

CIFS AD Auto-discovery from the ARX switch
Prior to 3.0, Active Directory forest information had to be manually collected from customers and manually configured in the ARX switch.

V3.0 enables the ARX switch to perform automatic discovery of all Active Directory information. The auto-discovery feature works within a single AD forest and does not auto-discover forest-to-forest trusts. This feature greatly simplifies and makes less error prone the installation of the switch in CIFS Kerberos environments.

Deterministic directory mastership when using NSCK Rebuild
Prior to V3.0, in some configurations directory mastership was not deterministic after an nsck ... rebuild operation. After the operation dis-assembled all volumes in the namespace and re-imported them, directory mastership was distributed across all shares. In 3.0, the ARX software determines directory mastership based on configured place-rules. For example, if age-based tiering is configured, then all master directories will be assigned to tier-1 share(s).


Release 3.0 also included fixes for the following issues. Fixes for all of these issues are also inlcuded in the current release:

19365, 26774
Alarming error messages and logs appear during a firmware upgrade.

26275, 26557
Windows-mgmt-auth information is missing from the show global-config security command.

The show interface command logs OM read errors in syslog.

SSL error with the show ntlm-auth-server command.

Scheduler time is off by 1 hour.

If you perform a domain-join operation from the GUI, the system exposes the password in clear text.

Changing the next-hop gateway for the out-of-band management interface stops all routing through that interface until the next reboot.

The SCM may send redundant nvramECCError traps.

Possible deadlock between NLMD/DNAS with destructive rename.

Import report incorrectly flags collision.

Policy/schedule wrong times.

A shadow-copy rule fails/disables for no reason.

Unable to migrate from one share farm to another.

Cannot enter gbl mode after an upgrade followed by a disk replacement.

SRMount error reported for logon failure.

Redundant switches have a database-transaction leak on backup switch.

The show cifs client-activity command can possibly fail and cause a reboot.

GUI access results in many tiny daily access logs.

Make quorum-disk transitions less aggressive when the peer is offline.

NSM crashed but no core file was collected.

POLICY_SHADOW log message enhancement.

Shadow volume continuously performs full recursive scans when files are open during initial scan.

Some workstations are having problems and not dropping to NTLM after Kerberos fails.

CIFS SHIM messages on DR switch.

After failover, the show health command does not show metaDataOffline status.

Write probes fail but the share is not offline.

GUI columm sorting is not always accurate.

Incorrect GUI prompt appears when you remove a Windows management ACL.

Description of GUI sync button incorrect at share level. The Tool Tip displays incorrectly.

Client could not delete a zero-byte file.

Object Manager transaction leak.

The show processor command is not showing valid output.

Share Offline traps displayed for online shares.

Using a SAM-reference file server which has no enabled/active/present user backend shares on it produces bad results.

Log message if no DVolumeRecords are found.

Deconfigured switches crash.

Multiple occurrences of NSM cores.

NSM core.

Latency reported from remote site post DST upgrade.

CPU failure.

CIFS clients are unable to access a file or directory with a German umlaut in its name.

NSM-resource-threshold reaching 100% utilization.

avlDbDeleteFromTree crash from cifs_process_reply.

NSM core found on switch. Processor showing as Failed.

TEM cores at primary site.

Enabling browsing defeats Windows-mgmt protection.

Windows restricted accounts denied access.

TEM cores at customer site.

Enhance error message.

Volume stuck in stopping state.

Traps didn't clear.

Need a change in the TRAP subsystem to send email and log a trap when a database corruption is hit and a reimport initiated.

System should allow destage of stopped volumes.

collect logs doesn't collect the switch configuration.

3 cores found on primary switch.

SCM/NVR issues.

Virtual Service not showing in GUI.

Need more accurate messages for NSM cores, etc.

The import is stuck in Starting status.

A rule uses only a single timestamp in its report names if invoked by an age fileset's internal schedule; this causes each report to overwrite its predecessor.

Version 2.7.1

This section applies to installations that are upgrading from Release 2.7.0 or earlier.

Release 2.7.1 contained fixes the following issues. These fixes are also included in the current release:

Volume software fails with a core file if you disable the volume while it has a file-placement rule in progress.

CIFS clients in a tree domain may be unable to authenticate to a VIP in another domain, even though the parents of the two domains have a valid two-way trust relationship.

If a file-placement rule receives an excessive number of inline notifications (i.e., notifications of client changes), volume software may restart.

A managed volume may become inaccessible if a client changes the attributes of a directory and one of the volume's back-end filers is slow to perform the change.

If the same share name is used in multiple volumes, the nsck ... report commands cannot always find the desired share.

In rare cases, nsck ... report inconsistencies fails to report some found directories (marked as "FD" in the inconsistencies report) until after a client renames or deletes them.

NFS/TCP mounts can take several seconds on a busy ARX.
Additional Recommendation for ARX®6000 Platforms: Use the resource gateway command to dedicate two network processors to policy. See the CLI Network Guide for details on using this command.

Under rare circumstances, the internal syslog process can trigger a spontaneous reboot.

An ARX CIFS service cannot find files with this standard syntax: \\cifs-service\path\file.

In rare cases, a volume that failed an earlier import may cause a larger service outage for the duration of a redundant-switch upgrade. All of the volume's front-end services are inaccessible until both switches complete their upgrades. During this outage, the volume repeats the following message in the syslog:
"non-persistent database corrupted. Reinitializing volume."
This only applies to a specific and uncorrected import failure, to redundant-switch upgrades, and to upgrades from 2.7.0 (or earlier) to 2.7.1 (or later).

A sync files operation halts when it encounters a missing replica (or "stripe") directory. It should report the missing directory and continue.

A CIFS volume backed by NetApp filers is slow to open files with named streams. Only certain client applications (such as Windows Defender) have experienced this problem.

In a system with a large configuration (for example, hundreds of attach points in a presentation/direct volume), front-end services may not appear on the newly-active ARX after an otherwise-successful failover.

When a CIFS client copies a large directory into an ARX volume, the copy operation occasionally fails.

If an ARX experiences an NVRAM-hardware failure on boot-up, and an administrator allows the ARX to finish its failed boot, a rare race condition may occur between the ARX and its redundant peer. The effect of this race condition is to stop all storage services at the peer.

In a presentation (or "direct") volume with an attach point to a managed volume, NFS clients hang when they attempt to create a hard link within the attached managed volume.

A sync shares operation can cause multiple ARX reboots if applied to a disabled volume with enabled shares.

In a presentation (or "direct") volume with an attach point to a managed volume, some CIFS directory listings get an incorrect directory path from the ARX volume.

A presentation (or "direct") volume with more than 4,000 attach points can perform an excessive number of redundant operations. This results in excessive syslog messages and slow processing for clients.

If a directory in one CIFS share (for example, "longnameddirectory") has an alternate "8.3" name (e.g., "LONGNA~1") that collides with a directory in another CIFS share (with an actual name of "LONGNA~1"), the sync files command mistakenly assumes that all of the files in the first directory("longnameddirectory") actually reside on the other share.s directory (with the actual name of "LONGNA~1"). Clients cannot access the files unless someone runs another sync files operation.

NFS3 UDP clients occasionally get incomplete directory listings from ls.

A ron evict command can result in a growing packet storm among the RON's remaining ARXes, possibly resulting in one or more ARX reboots.

If a volume's CIFS client attempts to set the FILE_ATTRIBUTE_OFFLINE attribute (often used in stubs for filer-ILM applications), and one of the volume's filers cannot accept it, the volume may lock out all client access.
Current Solution: Specific errors in the syslog indicate that this attribute was rejected by a particular filer, and F5/Acopia® personnel have tools to work around the issue. Contact F5 Support if a CIFS volume blocks out client access and you see any TRANFS-...-INVOFFLINE or TRANFS-...-INVPARAM errors in the syslog.

A no share, remove-share, or similar share-removal operation can be excessively slow in a large shadow volume, or in any managed volume with thousands of link files.

A shadow-copy rule with the inline-notify feature may skip some directories if the source volume is very busy, with files changing in more that 50 directories per second.

A shadow volume may copy more files than were selected by the source fileset.

If a paused file-placement rule has a share farm as its target, the share farm's auto-migrate rule also pauses.

If a file or directory in a source volume is renamed between shadow copies, and the new name is different from the old name in case only (e.g., "myfile.txt" becomes "MYFILE.txt"), the later shadow copy fails with a STATUS_OBJECT_NAME_COLLISION error. This only occurs in a shadow volume that supports CIFS.

When a directory changes in a shadow-copy rule's source volume, the rule attempts to syncronize its parent directory first. If the parent-directory fails to syncronize, the rule skips the changed directory.

If a shadow-copy rule's source-volume scan is somehow truncated, the rule deletes any un-scanned files and directories from the shadow volume.

MTU path discovery is not negotiated properly, and this sometimes causes disconnects between the ARX and its back-end servers (such as a Kerberos DC).

When a back-end directory is promoted to "master" on particular back-end share, all of its subdirectories go to the same share regardless of the constrain-directories setting for the subdirectories.

Configuring the same XIPs on both switches can prevent a VIP from starting.

During DNS lookup, the domain name is translated to lowercase regardless of what is supplied by the user or configured on the switch, and the lookup fails.

[ Top ]

Version 2.7.0

This section applies to installations that are upgrading from Release 2.6.0 or earlier.


Release 2.7.0 added three features, also included in this release:

  • Persistent statistics for shadow-copy rules after failed runs of the rule
  • Enhanced resiliency for shadow-copy tree-walks.
  • Improvements to the output for the show active-directory CLI command, to help with diagnosis of Active-Directory issues.


Release 2.7.0 fixed the following issues. Fixes for these issues are also included in this release:

A memory fault in the Physical Address Extension (PAE) can lead to unpredictable issues, including an nsck destage that never completes, new VIPs that are unreachable, or even a chassis reboot.

The slot erase command does not properly clean up the configuration database.

Shadow-volume statistics restart from 0 (zero) after a shadow-copy run is interrupted by a failure (such as a reboot).

A shadow-copy rule can pause indefinitely on a delta for a large file.

The initial walk of a shadow-copy rule runs to completion after encountering a common error (such as a file opened by a CIFS client), then it restarts from the beginning.

Volume software can fail (and write a core file) when a CIFS client has files open in two different volumes and the client's connection is lost.

Certain client applications may crash unless the CIFS path-cache feature is disabled.

NFS clients for a presentation volume experience occasional timeouts when accessing storage that is attached to a managed volume in the same VPU.

NSM processors occasionally fail with a core file.

Cannot press for prompts through customer's Java SSL terminal.

Metadata-Inconsistency reports do not report large directories correctly.

An ARX with a large number of exports (more than 7200) sends an excessive number of nsmResourceThreshold traps. This resource trap is inappropriate for exports.

The delete capture command causes a "Dynamic SQL Error" in the syslog.

The ARX sends spurious vcifsSearchNotFound traps when CIFS clients search for filenames with invalid CIFS characters (such as ":").

A Windows rmtshare query fails on a valid ARX CIFS share.

Pasting a running-config into the CLI generates errors within the cfg-channel commands.

After a failover, many place rules report an inability to retrieve free-space information (shown in the show policy output).

The output of the collect diag does not contain the output of the show vpu command.

An ARX where all configuration was removed can experience reboots due to software faults.

A place rule stops trying to migrate an open file after only five retries (two minutes and thirty seconds total); the timeout should be much longer. The solution was to increase the timeout to several hours.

The Windows rmtshare remark command fails on a valid ARX CIFS share.

The policy pause command and its GUI equivalent leave a share farm in an irreversible state, "Manually Paused."

In a multi-protocol (CIFS and NFS) volume, file migrations to a UNIX Qtree caused UNIX permissions to change. This applies to Qtrees on NetApp 7.2.x filers.

A place rule with duplicate inline notifications (migrations triggered by some client action) can reach a state where it perpetually restarts its volume scans.

A managed volume fails with a core file if you remove one of its shares with the force option, then import another share while clients access the volume.

The show namespace report shows a cryptic import error, "DTFS Operation has error status (-51)," when the back-end filer does not allow sufficient TCP sessions for the import to succeed.

In environments where client and server clocks are unsynchronized, Kerberos authentications fail persistently for some applications.

File migrations can stall indefinitely as they repeatedly attempt to get inaccessible directory locks.

If a client modifies a file's CIFS SD through a presentation volume attached to a managed volume, a subsequent copy may result in a dual failure for both redundant ARXes.

The policy engine continues running on the backup switch in a redundant pair, resulting in multiple "POLICY_PDP-0-3-POLICY_DB_OP_FAILED" messages in the syslog.

Clients are unable to access ARX CIFS services through an SSL VPN.

Kerberos authentications/logins are excessively slow (up to two minutes long) on an extremely busy ARX.

NSM processors occasionally fail, writing a core file, when they have a CIFS connection to an EMC file server.

The GUI is unresponsive when adding CIFS exports

If you remove a volume and recreate it, the volume may stay in "Starting" state indefinitely.

The show active-directory status command does not necessarily display active DCs that the ARX is using for Kerberos authentications.

The domain-join operation, when performed in the GUI, leaves the administrator's password in clear text in the procdat log file.

The policy engine can get into a state where it uses too much memory, eventually causing the ARX to reboot.

A shadow-copy rule occasionally causes a policy-engine failure, resulting in one or more core files.

The ARX cannot support 64 VIPs and 24 VPUs at the same time.

If an NFS client renames one file so that it overwrites another, a deadlock can result in the NFS Lock Manager (NLM) software.

The ARX drops some SNMP shareOnline traps.

A back-end file name with a mixture of UTF-8 and 8859-1 characters can cause volume software to crash and produce a core file.

The collect diag CLI command (and its GUI equivalent) includes system reports in the collected data; the diag option is supposed to omit reports, to keep the collected data at a reasonable size.

[ Top ]

Version 2.6.0

This section applies to installations that are upgrading from Release 2.4.3 or 2.05.00x.


Release 2.6.0 added two features, also included in this release:

Forest-to-Forest Trusts (Kerberos)
The ARX now supports authenticating users across multiple Win2003 Active Forests when a bi-directional trust exists between the forests. This allows clients in one of the AD forests to access a CIFS service in the other forest. In Release 2.6.0, the ARX can support these forest-to-forest trusts, allowing clients from a remote AD forest to authenticate with services in the local AD forest.

Shadow-Copy Support for CIFS Open Files
In release 2.6.0, you can use the optional allow-shared-access command to shadow-copy files that are already open for write or delete by others. By default, a shadow-copy rule blocks any writes from CIFS clients while it opens a file to copy it. No other client can write to the file or delete it in the middle of the copy operation. This prevents any corruptions in the shadow-copy of the file. However, if some other application is already holding the file open for writes before the shadow-copy rule opens it, the shadow-copy rule cannot open the file with read-only access. This can block the overall shadow-copy operation. In Release 2.6.0, you can use the optional allow-shared-access command to successfully shadow copy any such open files.


Release 2.6.0 also added fixes for the following issues:

Stale MAC addresses are not removed from a network processor after the processor returns from a failure.

The ARX tends to reboot if its redundant peer fails and it has an unreliable quorum disk.

In an unreliable network, NFS clients may cause dual failures in a redundant pair of NSM processors. This results in a failover to the backup ARX.

A volume with cifs path-cache enabled rejects all requests for the "/" path (such as mount requests) from Mac Dave clients.

If a managed volume's metadata filer is slow for an extended time, the volume may spontaneously re-import.

If enough NFS clients hold open TCP connections to a VIP for an extended time, rpcinfo queries may fail and possibly cause a failover.

[ Top ]

Version 2.5.2

This section applies to installations that are upgrading from Release 2.4.3 2.5.0, or 2.5.1.

When a thread fails during a managed-volume import, the other threads continue instead of aborting the import job.

An NSM processor may fail if it is running nearly its maximum number of CIFS sessions, 16,000.

The no capture session command can, in rare circumstances, lead to a system failure.

An expect command can hang for an indefinite time.

CIFS clients cannot access directories whose names begin with a ".", such as ".myFiles."

26812, 26773
Some Excel-spreadsheet Macros fail when accessing the Excel files through the ARX.

[ Top ]

Version 2.5.1

This section applies to installations that are upgrading from Release 2.4.3 or 2.5.0.


Release 2.5.1 offered these enhancements, also included in this release:

Forcing a Volume to "Take Ownership" of a Back-End Share
A managed volume can now take ownership of a filer share that is evidently (but not actually) owned by another managed volume. This is an option for the CLI command, enable, for a share (in gbl-ns-vol-shr mode); refer to the CLI documentation for use cases and other details.

Flexible Naming for CIFS Services
CIFS services now support NT domain names that do not match their AD domain names. Refer to the documentation for the CLI command, windows-domain (gbl-gs).

Performance enhancements
for removing shares from a managed volume.

Latency Statistics for Quorum Disks
The CLI command, show redundancy quorum-disk, now shows latency statistics of the quorum disk over time. This is useful for anticipating redundancy-related issues.

Time Windows for Log Collection
You can focus the collection of log messages by choosing an optional start time and end time. Refer to the documentation for the CLI command, collect logs.

Monitoring for CIFS-Client Activity
A new CLI command, show cifs-service client-activity, shows details about a CIFS-client connection to the ARX, as well as the proxy connections from the ARX to the filers behind it.


Release 2.5.1 included fixes for these issues in addition to the above enhancements:

24423, 25956
In installations with high-numbered IP addresses (140.x.x.x or higher) and many simultaneous connections, the ARX periodically loses contact with a back-end filer.

A misleading redundancy error may appear when reloading the active peer.

26184, 26334
The SSH key changes after the software upgrade, requiring administrators to update their copy of the key.

(Enhancement) Increase the maximum number of CIFS exports to 9,000.

File or directory creates occasionally failed in CIFS managed volumes.

At a particular moment during startup of a Kerberos-and-NTLM service, it is possible for a Kerberos client to cause a CIFS-service failure.

Alternate names are not supported in CIFS volumes.

In the show namespace output for a namespace that is importing, the import status shows "N/A" for the first few seconds.

A misleading error may appear when using the GUI to remove a volume.

The Create Virtual Service wizard does not allow you to change the service's namespace after you have defined one export from it.

You cannot enter an Organizational Unit (OU) with a name longer than 71 characters from the GUI.

[ Top ]

Version 2.5.0

This section applies only to installations that are upgrading from Release 2.4.3.


Release 2.5.0 offered the following features, also included in this release:

Faster Imports into Managed Volumes
In previous releases, managed volumes import options were not configurable. V2.05 allows the user to select various import options such as multi-scan and protections on a per volumes basis. Additional internal architecture changes where also made to significantly improve import performance. Additionally, a managed volume does not spend time protecting its metadata during the import; metadata protection is rarely necessary until the volume is running. Both options are configurable. Managed-volume imports are significantly faster with these options enabled, along with some other internal optimizations.

Support for CIFS subshares and their ACLs
This release supports CIFS subshares and their share-level ACLs. A subshare is a CIFS share that is nested within another share. The top-level share often has a different share-level Access Control List (ACL) than each of its subshares. By default, a managed volume accesses directories through the filers top-level share, even when a client connects to a subshare on an ARX CIFS service. The managed volume connects to the top-level share, subjecting the client to the ACL there, and then descends to the desired subdirectory. With this new feature, the ARX can pass a client from a front-end subshare directly to the corresponding back-end subshare where the filer will enforce share level security.

No Client Restrictions in Multi-Protocol (NFS and CIFS) Volumes
Clients of a multi-protocol managed volume can now create directories with any name. In previous releases, volumes did not permit any names that resembled filer-generated names (FGNs, such as "myDir~1").

Ability to Migrate a Metadata Share
There is a new option to migrate a managed volume's metadata from one dedicated share to another.

Firmware Upgrades
You can use a new CLI command, firmware upgrade, to install any new firmware bundled with the latest software release. This command is documented in the software-upgrade chapter of the CLI Reference.


Release 2.5.0 included fixes for the following issues:

Report-prefix names cannot contain slash (/) characters.

A misleading message appears when you use the CLI to remove the redundancy-link channel.

The Disable button is ineffective in the GUI Namespace screen.

If a volume's only metadata share is unavailable during import, you cannot nsck ... destage the volume.

If a simple-age fileset starts on the 29th-31st, shorter months confuse the scheduler.

A file-placement rule configured by a script may hang in "Initializing" state.

A shadow-copy rule does not duplicate changes in a directory's alternate data streams (ADS) if they change after the first run of the rule.

When namespace-level metadata share goes offline, show namespace continues to display an "Online" metadata-share status in most of the volumes that use it.

If the ARX reboots during a migration, the "pending" status of the migration is lost when the ARX comes back up.

[ Top ]

Required Configuration Changes

This section only applies to installations that upgraded from Release 3.0 or earlier.

Once you have installed the software, you must make the following required configuration change(s).

Upgrade Firmware and (Optionally) Set NSM Recovery

As mentioned above, Release 3.1.0 includes a firmware upgrade. This upgrade is required to support NSM recovery and NSM binary-core files. The NSM recovery feature allows an NSM processor to recover after a failure without necessarily rebooting the entire ARX. After you upgrade the firmware, you can use the nsm recovery CLI command to enable failovers between NSM processors. Refer to the "Preparing for NSM Recovery and Diagnosis" chapter in the CLI Network Guide for full details about the NSM-recovery feature and the nsm recovery command.

Warning: You must reboot the ARX to enable the NSM-recovery feature. If you have a redundant pair of ARXes, enable NSM recovery on the backup ARX first, then enable it on the primary ARX (causing a failover to the backup) during off hours. A standalone ARX endures a longer service outage as the ARX reboots; for this reason and others, we recommend redundant ARXes for sites that support extensive client traffic.

For Sites with Windows Filers, New Filer Setting Required for NTLM Connections
Before Release 3.2.0, the ARX used "non-extended security" for its NTLM-authencated connections to back-end filers. To correct Issue 27316, the ARX started to use "extended security" for its CIFS connections. However, newer Windows servers require NTLMv2 (not NTLM) for its "extended security" connections. To prepare for an upgrade to Release 3.2.0+ in an installation with Windows filers, verify that the following parameter (from the Windows security-policy UI) allows NTLM connections:

Network security: minimum session security for NTLM SSP based clients.

This policy parameter should be set to "No minimum;" none of the four flags for this parameter should be raised.

The following parameter must also be set so that it does not refuse NTLM from clients (such as the ARX). This was required for ARX Releases before 3.2.0, so you only need to investigate this for new Windows filers or new ARX installations:

Network security: LAN Manager authentication level

You must reboot the Windows server for this (or these) changes to take effect.

[ Top ]

Known Issues

The following items are known issues in the current release.

The ARX4000 Data Plane (NSM side) cannot recover from a power failure until the Control Plane (ASM and SCM side) reboots. (29444)
If the Data Plane (the lower half of the chassis with the network ports) loses power independently of the Control Plane, the Data Plane cannot recover by itself. If both halves of the chassis lose power at the same time (a more-likely event), both halves reboot normally.

Best Practice: The Data Plane and Control Plane each have two power supplies. Connect one power supply from each Plane to one power source, and the other power supply from each Plane to an alternate power source.

Recovery: Stop and restart power on the Data Plane (the upper half of the ARX). This causes both modules to power up in the proper sequence.

UTF-8 Chinese characters are truncated in namespace name. (30941)
If a user enters Chinese characters that exceed the GUI's limit for any input field, the GUI will not issue an error message but instead simply truncates the input.

The GUI input fields limit input based on characters and not bytes. When entering multi-byte characters, the input may be truncated if the total number of bytes representing the characters exceed the internal byte limit.




The CLI "show clock" output does not always show the correct time after a time-zone change. (24526)
You can use the clock timezone CLI command to set the time zone of the ARX. On rare occasions, the output from the show clock command does not show the correct time after this change. For example:

ARXa500# clock set 14:43:00 01/11/2007

ARXa500# show clock

Local time: Thu Jan 11 14:43:02 2007 EST -0500 America New_York

Universal time: Thu Jan 11 19:43:02 2007 UTC

ARXa500# config

ARXa500(cfg)# clock timezone America Denver

ARXa500(cfg)# show clock

Local time: Thu Jan 11 14:43:13 2007 EST -0500 America Denver

Universal time: Thu Jan 11 19:43:13 2007 UTC

The time does not conform to the new time zone, though the correct new time zone (America Denver) does appear in the output.

Workaround: Log out of the CLI and log back in.

During the hour of transition from daylight-savings time to standard time, the clock set CLI command incorrectly interprets times in some time zones. (24709)
Times are ambiguous in the hour when daylight-savings time reverts to standard time, once per year. Suppose the transition occurs at 3 AM on the day of the daylight-savings change: time passes from 3 to 4 AM in daylight-savings time, then the clock goes back to 3 AM for standard time, and then time passes from 3 to 4 AM again. In some time zones, if you reset the clock to a time between 3 and 4 AM, the clock set command may not interpret your time correctly. If this occurs, the ARX assumes that the transition to standard time has already occurred.

This only occurs in time zones that are East of the Prime Meridian, with positive offsets from UTC.

Workaround: Avoid the clock set command during the day and hour of transition.

A client IP address remains in the output of show nfs-service mounts after the client unmounts. (24478)
The output of the show nfs-service mounts command is a table of NFS mounts from client machines. For each currently-active client mount, the table displays the Global Server, the mount point, the VIP, and the client IP address.

When the client is unmounted, there may be a slight lag in the update of table information, and a repeat of the show nfs-service mounts command may show the client still mounted.

Workaround: Retry the show nfs-service mounts command.

An ARX500 drops untagged packets on VLAN 1 (the default VLAN) after you re-play its running-config. (31435)
Replaying a running-config is a necessary final step in replacing an old ARX500 with a new one. This is only a problem if the ARX500 uses untagged layer-2 packets on the default VLAN, VLAN 1.

Recovery: Reboot the ARX after replaying the running-config. From the CLI, you can use the reload command to reboot the ARX.

The ARX cannot send E-mail messages through the out-of-band (OOB) management interface. NTP, DNS, RADIUS, and snapshot-management services (SSH and RSH) are also unsupported through the OOB interface. (24595)
All e-mail notifications from the ARX go out through an in-band (VLAN) management interface, configured with the interface vlan CLI command. At least one in-band-management interface must have a route to the E-mail server for E-mail notifications to function. The same applies to NTP, DNS, and RADIUS services, as well as SSH and RSH for managing filer snapshots.

Workaround: Use the cfg-mode ip route command (without the mgmt flag) to add a static IP route to the E-mail server(s), NTP server(s), DNS server(s), and/or RADIUS servers. All filers and file servers must have a route to be useable by the ARX at all, so this is less likely to be an issue for SSH and RSH.

The management address for an external filer cannot be on the out-of-band (OOB) management subnet for the ARX. (25487)
To support coordinated snapshots in an ARX volume, the volume requires the management-IP address for the filer. You set this with the ip address a.b.c.d management CLI command, or its GUI equivalent. This address cannot be on the same subnet as the ARX's OOB interface. This is related to issue 24595, above.

Changes to the global-config may be lost while the standby switch is still booting. (28844)
After a failover, the standby switch may take several minutes to reboot. During this time, while the active and standby switches are syncronizing their databases, it is possible for changes in the global configuration to fail with a database error.

Workaround: Wait for the standby switch to finish booting before making any changes to namespaces, policies, or other storage-related objects. In the CLI, all storage-related objects are under gbl mode.

Spurious errors appear in the syslog after an NSM failover. (25782)
NSM processors have redundant peers, even in an ARX that is not configured for overall redundancy. If an NSM processor fails, its peer processes packets for both. If nsm recovery is enabled, the failed processor comes back online and waits to take over for the running processor. The failed processor may repeatedly put the following message in the syslog:

NAT rule TCP/ip-address:port for remote action ip-address-2:port-2 type 3 not found.

This syslog message is spurious.

The show ntlm-auth-server status CLI command gets an OPEN_SSL_ERROR string if the NTLM-server password is too long. (31029)
The Acopia Secure Agent (ASA) applet and the ARX CLI allow an ASA password of up to 64 characters, but underlying encryption software supports a maximum of 22 characters.

Workaround: If you see this error, change the password so that it is 22 characters or less. This change must occur in two places: at the NTLM-Authentication Server (where the ASA is installed) and at the ARX CLI. For instructions on modifying the ASA password, both on the ASA and in the ARX CLI, refer to the Secure Agent Installation manual.

You must separately export a CIFS managed volume if you use it as a "managed volume" in a CIFS direct volume. (21231, 24359)
If a CIFS-managed volume is used as a managed volume in a CIFS-direct volume, its CIFS front-end service must export the managed volume separately. This is in addition to the export for the direct volume. (The same CIFS service must export both volumes.)

NSCK reports do not identify "marked" multi-protocol directories where you should run a sync files operation. (23891)
Some multi-protocol (NFS and CIFS) directories are "marked" for special processing. These directories contain files and/or subdirectories one of these naming issues:

  • the name resembles a Filer-Generated Name (FGN, such as "myfile~1.txt"), or
  • the name produces an FGN on its back-end filers (such as "my:file.txt," or "MYFILE" in the same directory as "myfile").

If a directory is marked with one of these naming issues, the volume performs extra processing whenever a client tries to introduce an entry with the other naming issue. Depending on the outcome of the processing, the new client entry could become NFS-only (inaccessible to CIFS clients). Refer to the CLI Maintenance Guide for details.

Clients can resolve these issues by accessing the volume through its VIP and renaming the directory's entries. However, the directory mark persists after all of its child entries have been correctly renamed; you use the sync files CLI command to remove the mark.

The issue is that there are no reports that identify a directory as "marked" after its entries have been correctly renamed.

Workaround: Use sync files to clear the directory mark immediately after renaming its entries.

Under rare circumstances, an nsck ... rebuild on a shadow volume can make the volume stall in "importing" state. (18135)
If a shadow volume meets all of the following criteria when someone issues an nsck ... rebuild command, the shadow volume stays in "importing" state for a long time (perhaps hours), and is inaccessible to clients:

  • The shadow-copy-rule has its publish command set to group (the default),
  • The source volume contains millions of files,
  • The shadow-copy rule was near the end of a run, so most of the files were copied into the shadow volume's staging area (the hidden .acopia_shadow directory in the root of each share).

The root of the problem is that the .acopia_shadow directories contain millions of files, and the nsck ... rebuild must remove those directories at the beginning of its process. Clients cannot access the volume until all the filers are able to delete this directory.

If this occurs, messages appear in the syslog that describe the problem.

The ntp server command allows v1 and v2 of the NTP protocol. (30634)
v1 and v2 are not supported. Refer to the CLI Reference Guide for details.

In ssb degraded mode, slot reload does not recover the system. (30623)
Slot reload does not reset PCI link when link is already down.

Shadow Volume sync performance for ARX4000 is poor compared to ARX6000. (30406)
This issue is being actively worked. The issue is alleviated when pursuing the following Best Practice:

  • Set "receiver-threads" to 1 on your shadow rule before initial treewalk ONLY with a pre-seeded target on CIFS.
  • Set "receiver-threads" back after the treewalk is complete.

This will give a speedup of up-to 4x during initial treewalk vs. default settings, but ONLY with a pre-seeded target on a CIFS volume.

Contacting F5 Networks

  F5 Online Knowledge Base:
F5 Acopia Services Support Online:
F5 Online-Request Form:
Telephone: 1-866-4Acopia (1-866-422-6742)

Follow this link for a list of international Support numbers:

For additional information, please visit

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)