Applies To:

Show Versions Show Versions

Release Note: ARX version 5.2.2
Release Note

Original Publication Date: 08/29/2013


This release note documents the version 5.2.2 release of the ARX software. This is a maintenance release. We recommend this 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 4.0.0. You can apply the software upgrade to 3.2.3 and later. For information about installing the software, please refer to Installing the Software.

Note: F5 offers general availability releases and general sustaining releases. For detailed information on our policies, refer to SOL8986: F5 software life-cycle policy.


- User Documentation for This Release
- Minimum System Requirements and Supported Browsers
- Supported Platforms
- New/Updated Certifications
- Installing the Software
- Configuration Changes
- Downgrading to an Earlier Release
- Fixes and Enhancements in This Release
- Features
- Fixes
- Fixes and Enhancements in Prior Releases
- Version 5.2.0
- Version 5.1.9
- Version 5.1.7
- Version 5.1.5
- Version 5.1.0
- Version 5.0.7
- Version 5.0.6
- Version 5.0.5
- Version 5.0.1
- Version 5.0.0
- Version 4.1.3
- Version 4.1.1
- Version 4.1.0
- Version 4.0.1
- Version 4.0.0
- Required Configuration Changes
- For Upgrades from Older Releases
- Known Issues
- Authentication and Security
- Boot Software
- CIFS Proxy/Virtualization
- Disaster Recovery
- File Tracking
- Logging
- Policy
- NSM Software
- Redundancy
- Namespace Software
- File Servers
- Snapshots
- Supportability
- Third Party Source Acknowledgements
- 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
[ Top ]

Minimum System Requirements and Supported Browsers

The minimum supported browsers for the ARX GUI are:

  • Microsoft® Internet Explorer® (IE), version 6.0
  • Mozilla® Firefox® 1.5, and other browsers that use the Mozilla engine

Later versions are also supported, such as IE 7 and Firefox 3.x.

[ Top ]

Supported Platforms

This release supports the following hardware platforms:

  • ARX®500
  • ARX®1000
  • ARX®2000
  • ARX®4000
  • ARX®6000

New/Updated Certifications

There have been no new certifications with this release.

For a complete list of vendor equipment that is useable with this release, refer to the ARX Compatibility Matrix.

New/Updated Certifications in Release 5.1.5

F5 Data Solutions has certified the following back-end servers for use with ARX snapshots:

  • the EMC Data Domain system, version, and
  • Windows Server 2008 R2 with WinRM 2.0.

F5 Data Solutions has also certified the HP Polyserve system for use as a CIFS file server. Specifically, version was certified.

New/Updated Certifications in Release 5.1.0

With Release 5.1.0, Windows 2008 was certified as a Domain Controller (DC) in the ARX's Domain. This certification includes all variations of Writable DCs (WDCs), but does not include Read-Only DCs (RODCs). The ARX does not discover any RODCs in your Active-Directory forest, nor does it use RODCs to obtain Kerberos tickets. However, the ARX does honor tickets that clients have obtained from RODCs.

Windows 2008 clusters were certified as file servers behind the ARX.

Data Domain systems were certified as file servers behind the ARX.

Windows 7 machines were certified as clients for ARX services.

New/Updated Certifications in Release 5.0.0

In Release 5.0.0, F5 Data Solutions certified Windows 2008 for use as both a file server (behind the ARX) and as a client machine (in front of the ARX).

Windows Filer Servers that Support ARX Snapshots

The following Windows file servers have been certified for use with ARX snapshots:

  • Windows Server 2003
  • Windows Server 2008

The ARX manages snapshots on these file servers through Windows Remote Management (WinRM). This is included with Windows Server 2008, but you must install it on a 2003 server. After installation, create at least one WinRM listener, listening on HTTP port 80 (encrypted or unencrypted). Whether or not the HTTP connection is encrypted, the ARX authenticates through Kerberos.

You must use WinRM v1.1 or later

New/Updated Certifications in Release 4.1.0

In Release 4.1.0, F5 Data Solutions certified the following file servers and client machines for use with the ARX.

Filers and File Servers

F5 has tested and qualified Data ONTAP Release 7.3 and 7.3.1 for use on the following back-end filers:

  • NetApp, and
  • IBM N Series.

F5 has also tested and qualified EMC DART 5.6 for use as a back-end file server.

Client Machines

F5 has tested and confirmed the interoperability of the following client software with the ARX:

  • Mac OS X 10.5.5 with
  • Thursby DAVE 7.1.2.

Release 4.1.0 also supports photocopier/scanners as CIFS clients. These scanners can use their "Save As" feature to save a scanned image to a file on an ARX share. The ARX namespace must have a security setting disabled through the CLI (with the new cifs anonymous-access command) or the GUI to support this option.

F5 Data Solutions has tested and qualified the following Kyocera photocopiers/scanners:

  • KM-C2525
  • KM-C3232
  • KM-C3232E
  • KM-C4035E

New/Updated Certifications in Release 4.0.0

For Release 4.0.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
  • HP Procurve 2900
    10GBASE-SR Procurve X2 DE523RQ001
  • HP Procurve 3400
    10GBASE-SR Procurve X2 DE523RQ001
  • HP Procurve 3500
    10GBASE-SR Procurve X2 DE523RQ001
  • HP Procurve 4205
    10GBASE-SR Procurve X2 DE523RQ001
  • HP Procurve 5400
    10GBASE-SR Procurve X2 DE523RQ001
  • HP Procurve 8100
    10GBASE-SR Procurve X2 DE523RQ001
[ Top ]

Installing the Software

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

  • 5.2.0
  • 5.1.9
  • 5.1.7
  • 5.1.5
  • 5.1.0
  • 5.0.6
  • 5.0.5
  • 4.1.3
  • 3.2.3

For installation instructions, refer to the Upgrading Software chapter of the CLI Maintenance Guide. If you must upgrade from an earlier Release (such as 2.7.1) or an interim release (such as 4.1.1), upgrade both peers to one of the above 3.x, 4.x, or 5.x releases before upgrading them both to the current release.

In a redundant pair, you must invoke an additional failover after both peers are upgraded beyond 5.2.0. The final failover, with both peers at 5.2.0+, makes it possible to upgrade the internal database for quota tolerance support.

WARNING: This release also includes a new version of firmware, but you cannot perform a firmware upgrade on any ARX-4000 device until Bug 351863 is resolved. This only applies to ARX-4000 devices.
For an ARX-4000, please install the latest 5.01.nnn release possible and upgrade to the firmware with that release. Perform this earlier installation and upgrade the firmware on both peers, as instructed in the Upgrading Software chapter of the CLI Maintenance Guide. Then install the 5.2.2 release (without the firmware) on both ARX-4000 peers.

For other chassis types, please upgrade the firmware as instructed in the above manual. If you upgrade from a release before 5.2.0, this firmware includes new BIOS firmware, which requires 30 minutes to install.

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.

Downgrading to an Earlier Release

You can downgrade back to any of the above releases, as advised by F5 Support.

The 5.2.0 release included a database upgrade, so installing an earlier (pre-5.2.0) release requires a full database rebuild. This means erasing both running and global configuration from the ARX, replacing both the running-config and the global-config, and then re-importing all managed volumes. Upgrades to future, higher releases will not have this issue.

In general, downgrades are not recommended. Contact F5 Support if you feel you need to downgrade to an earlier software release. For detailed instructions, refer to the Upgrading Software chapter in the CLI Maintenance Guide; this contains a section specific to downgrades.

Warning If you downgrade to Release 5.0.5 or earlier, do not downgrade the firmware with it. Earlier firmware could render the ARX unresponsive.

[ Top ]

Fixes and Enhancements in This Release

Release 5.2.2 includes several new features and fixes, described in the sections below.


Release 5.2.2 contains a feature enhancement for tracking statistics. The new show statistics global server CLI command provides traffic statistics for communication between ARX clients and any ARX front-end (NFS or CIFS) service.


Release 5.2.2 adds the following fixes to the ARX:

Some upgrades of redundant pairs failed with an error on the upgraded (backup) peer, visible in the show redundancy output. The error prevented the redundant pair from forming. The error cleared when both peers were upgraded. Now, the error no longer occurs on upgrade.

A rare race condition between a CIFS-client disconnect and an internal "cancel- search" command could potentially cause a software failure. The software failure produced a core-memory file. The race condition has been corrected.

Many CIFS clients were unable to connect to ARX storage during failovers and failbacks between NSM cores. The client outages sometimes lasted for several minutes. This fix addresses issues in the control plane that contributed to the outages.

An SNMP get operation sometimes caused the ARX software to fail, produce a core-memory file, and reboot. The failure occurred only if there was at least one CIFS-authentication failure in the database, the failure was one of a small set of failures, and CIFS-authentication statistics were included in the returned data.

343058, 342994, 342941
After the following sequence, redundant peers failed to pair:

  • There is an exceptionally long export path in the external-filer configuration and/or an exceptionally long description for a policy schedule.
  • You upgrade your ARX cluster from Release 5.0.6 or earlier.
  • One of the peers in the cluster irrevocably fails, and you replace it.

If all of the above conditions were met, the replaced peer (in the Backup role) could not rejoin the cluster. The current release makes it possible for the pair to form under these circumstances.

351553, 350947
A problem in the NSMs memory allocation could cause the NSM to be shut down by the control plane. This has been fixed by ensuring that the internal watchdog is serviced in the memory heap management routines.

The Network Services Module no longer generates a core file when bad server message blocks are received from the network.

340643, 35742
The ARX now sends out all varbinds for all SNMP traps.

Erroneous syslog messages are no longer generated when navigating a filer for which streams are disabled.

Log messages related to the mounting and connection of quorum disks have been improved to facilitate the troubleshooting process when access to the quorum disk is interrupted.

Displaying chassis information using the GUI sometimes displayed Disk Status as Good when the actual status was, in fact, Degraded. The criteria used to determine Disk Status has been modified to characterize that status more accurately as Optimal or Degraded.

The ARX supports the creation of VLAN IDs ranging from 1 to 4009, and now provides adequate warning against creating a VLAN with an ID higher than that.

A problem that caused error messages to indicate that SMB signing was not enabled, when, in fact, it was, has been fixed.

Snapshots no longer lock up on ARX 6000s when filer subshares and SID translation are enabled.

347303, 345679
A problem that occurred when an attempt to mount a CIFS quorum disk failed has been fixed, and the corresponding logging has been improved to translate the CIFS error/status code to a text string.

The ARX-2000 no longer gets stuck at the GRUB menu during the boot process.

A problem that caused firmware mismatch error messages to be displayed even after a successful firmware upgrade has been fixed.

A problem that caused OMDB transactions to stay open for extended periods of time has been fixed.

Adding vlan-tag entry to channel config should not automatically add vlan entry to running config display

Auto-migration now works correctly when the "no volume scan" option is used with the place rule.

When executing the "quorum disk" command for CIFS and using the optional "spn" argument, it is no longer necessary to capitalize the fully-qualified domain name.

Need to increase banner.txt size limit from 768 bytes to 1.5 KBs

The "collect diag-info nfs" command now collects state information and core files correctly.

343813, 347086
Changing a metadata share for an existing managed volume no longer causes an unexpected exit of the ARX GUI.

341077, 344350, 348438
The cfg-if-gig no redundancy protocol CLI command caused a network (NSM) processor to fail.

When a CIFS file-server unexpectedly closed its connection behind a namespace with cifs filer-signatures required, the namespace software occasionally failed. The failure produced a core-memory file.

[ 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 5.2.0

Release 5.2.0 included several new features and fixes, described in the sections below.


Release 5.2.0 contained several CIFS enhancements, supportability enhancements, and some options designed to take advantage of popular file-server features. These are all described in the subsections below.

CIFS Service Enhancements

Release 5.2.0 contained several enhancements for CIFS front-end services. These are designed to tighten security and to improve ease-of-use for administrators.

Constrained Delegation

An ARX-CIFS service delegates its storage services to the filers behind it. Release 5.2.0 supports constrained delegation, so that you can constrain the CIFS service to delegate only to the file servers it uses. (Former software releases allowed the ARX to delegate its services to any filer.) If you use constrained delegation, the namespace behind the service no longer requires an NTLM-authentication server to support NTLM or NTLMv2, and you no-longer need to install an ARX Secure Agent (ASA) on any of the CIFS service's DCs.

Constrained delegation is only possible for a domain if the Domain's functional level is Windows 2003 or later.

A domain administrator can upgrade an ARX-CIFS service to constrained delegation at a Windows Domain Controller (DC). On the DC, the administrator invokes the Active Directory Users and Computers application, finds the machine account for the ARX service, trusts the account for "delegation to specified services only," and identifies all of the CIFS servers behind the ARX. On the ARX, the probe delegate-to command provides a list of all CIFS servers behind a particular ARX service, and confirms that they are properly configured at the DC.

After upgrading a CIFS service to use constrained delegation, it is possible for the service to require a configuration change. Refer to Required Configuration Changes for instructions.

NOTE: Constrained delegation is more secure than unconstrained delegation, and requires that all of the CIFS service's filers be joined to the same Windows domain as the CIFS service itself. Also, all of the filers must support Kerberos authentication.

SMB Signatures

ARX CIFS services and namespaces can now support SMB signing. SMB signing is the process of adding digital signatures to every Server Message Block (SMB) between a CIFS server and its clients. This protects against man-in-the-middle attacks, but creates a performance penalty.

If you implement SMB signing at your site, the ARX can support it as needed. You can enable SMB signing between CIFS clients and one of your CIFS services, and you can enable SMB signing between an ARX namespace and all of its filers.

Active-Directory Site Awareness

The ARX software uses its Active-Directory (AD) site to calculate its preferred Domain Controllers (DCs). In large AD deployments with multiple sites, the AD administrator can identify the sites and assign DCs and subnets to each site. The AD administrator performs this site configuration externally, on a DC. When the ARX automatically discovers the AD configuration (with the active-directory update seed-domain CLI command, or its GUI equivalent), it "prefers" DCs in the same site as its proxy-IP subnet. This removes the administrative burden of manually setting DC preferences on the ARX.

The subnet for the proxy-IP addresses must be assigned to an AD site for the automatic discovery to function properly. You assign a subnet to an AD site at the DC. Use the show ip proxy-addresses CLI command to find the subnet for your proxy-IP addresses.

CIFS-Subshare Enhancements

This release includes several enhancements for the CIFS subshare feature. A CIFS subshare is any CIFS share that exists in the directory tree of an imported CIFS share. Given the correct configuration, a client connecting to an ARX subshare also connects directly to the corresponding file-server subshare, instead of connecting to the import share above it. This ensures that the file server uses the subshare ACL instead of the root-share ACL.

This release enhances the subshare feature by making it easier to manage, especially in large configurations:

  • Subshare replication between back-end filers is now automatic, and no-longer requires the replicate flag in the filer subshare operation.
  • Former releases replicated all subshares discovered on the first-imported share. The ARX ignored any subshares on the second or subsequent imported shares. This release discovers all subshares on all back-end shares, and fully replicates them.
  • Formerly, subshare replication generated new share names in the format, "_acopia_native-name_id$," where the native-name was the name of the subshare that was being duplicated. Now the ARX only generates these names when a naming collision makes it necessary. In most cases, the native-name is duplicated on all back-end shares.
  • The new sync subshares from-namespace operation synchronizes all filer subshares behind a volume and then exports them through a CIFS service. This is done with a single CLI command or GUI operation.
  • A reverse operation, sync subshares from-service, takes all subshare definitions from a front-end CIFS service and replicates them on all the filers behind it. This provides a method for repairing a front-end subshare that is not fully backed by its back-end counterparts.
  • When you export a filer subshare, the ARX automatically replicates all subshare and ACL information on all required back-end subshares.

Two former CLI commands, sync shares and cifs export-subshares, are now obsolete. They have been removed from the CLI, and their GUI counterparts have been adapted to the new operations.

In releases prior to 5.2.0, in ARX Manager, there was a Discover button for subshares in the Create Virtual Service Wizard. In 5.2.0, the subshare "discovery" mechanism was changed/enhanced to include an asynchronous operation that changes the back-end file server configuration by adding subshares to any shares that don't include them already. This enhancement was deemed too heavy to be done as part of a wizard, so the button was removed. The new work flow is to create your virtual service, then edit your managed volume, click the share tab, and click the Sync button. This will sync all back-end subshares and export the sub-shares out the virtual service.

Managed-Volume Shares Dedicated to Snapshot Repositories

The 5.2.0 release supports replica-snapshot shares in managed volumes. A replica-snapshot share is a constantly-updated duplicate of one of the volume's standard shares. You use standard file-server-replication tools to copy the primary share's files to the replica-snapshot share, then the managed volume can snapshot the data at the replica-snapshot share. This allows you to keep a much smaller number of snapshots on the primary share. The managed volume's CIFS clients can access these snapshots through standard means (such as the "Previous Versions" tab in some Windows releases).

Disaster-Recovery (DR) Support for ARX Sites

A redundant pair of ARXes, called an ARX cluster, can now be used as a backup for an ARX cluster at a primary site. This feature is designed for sites where the back-end file servers independently synchronize data between the two sites. To prepare an ARX cluster for a disaster, you can copy the ARX's global configuration to its backup cluster on a regular schedule, so that the backup cluster always has an updated copy of the active cluster's configuration. In the event of a disaster at the active site, an administrator at the backup site can load and activate the configuration there. ARX clients can then connect to their services and storage at the backup site. The client-side names of all services and shares remain consistent after the site failover.

You can also fail over individual services from one site to another, so that some services run on one ARX cluster and other services run on the second cluster.

Active-Directory Authentication for ARX Administrators

ARX administrators can now use their Windows credentials to log into the CLI or GUI. This requires some minimal configuration to provide one or more Windows groups (such as "Domain Admins") with administrative privileges on the ARX, and to allow Active-Directory authentication into various access points (such as SSH for the CLI or HTTPS for the GUI). Use the authentication CLI command to allow AD authentication, and use the group CLI command to start provisioning a Windows group for ARX administration. For detailed instructions on these commands, refer to the CLI Reference.


This release also contains the auto-diagnostics feature, which can regularly collect usage statistics from your ARX and send them (through E-mail, encrypted) to F5 Support. The engineers at F5 Support can analyze this data over time, watching for trends and, if necessary, contacting you about preventative actions. The feature is recommended, but it is optional; you can use the gbl-mode auto-diagnostics command (or its GUI equivalent) to activate the feature.

More Logs in "collect state" Payload

The collect state command (and its GUI equivalent) now includes important log files to aid with problem diagnosis, but still produces a zip file that is small enough to be portable. The collect state file requires a much shorter upload time than the zip file from collect all or collect diag-info. You can use collect state for an initial diagnosis, and possibly follow up with a later collect all if further diagnosis is required.


Release 5.2.0 supports a SOAP-based API for monitoring ARX configuration and file changes in its managed volumes. You can use third-party software that acts as a client for this API.


Release 5.2.0 added the following fixes to the ARX. These are also included in the current release:

In releases before 5.2.0, a CIFS-only managed volume occasionally included user-based and path-based storage quotas in its free-space calculations. For example, if a CIFS client had a quota of 5G on a back-end Windows share with 500G of actual space, the CIFS client only saw 5G for that Windows share. If filer subshares were configured in the ARX volume, path-based quotas were also taken into account on some occasions.

These quota-based free-space calculations were inconsistent, so they were eliminated in Release 5.2.0. After that release, all CIFS clients see the full free space on all back-end shares behind their ARX volumes, regardless of any space quotas those clients may have on the back-end Windows Servers.

If the previous behavior of reporting the storage-based quota free space is desirable, the recommendation is to not upgrade to this release of software and instead wait until the release of the freespace cifs-quota functionality in the 6.1.0 release to get the desired behavior.

When a sam reference filer is configured for a namespace but is unreachable on the network, no SNMP traps were generated and the condition was not reported in show health. In the current release, the ARX sends the samReferenceOfflineRaise trap, which raises an alarm condition.

By default, Windows 2008 R2 servers require 128-bit encryption for their NTLM SSP sessions. This encryption was not supported for filers behind the ARX. Now the ARX supports 128-bit encryption for NTLM SSP sessions.

A problem that prevented policies from being viewed or changed after upgrading the ARX software to Release 5.2 or higher has been fixed.

The ARX logic that monitors shares on file servers to detect offline conditions was enhanced to take into account recently encountered timeout failures for different shares on the same file server. This lets the ARX more rapidly detect an offline condition that affects many shares on a server.

The internal configuration database within the ARX failed to properly handle an error condition. The error handling code has been improved and now properly handles this error condition.

A problem that caused share farms to be duplicated upon creation has been fixed.

343205, 348017
Domain join fails with ADJOIN_GENERIC Error

Under rare circumstances, an upgrade to ARX Release 5.2.0 resulted in namespace-software failures and unplanned reboots. This only occurred if share farms existed in more than one managed volume. Now the 5.2.0 upgrade software can support this share-farm configuration.

File pathnames now can be renamed to consist of more than 256 characters. previously, pathnames longer than 256 characters in length caused the ARX session to terminate unexpectedly.

351078, 351352
Clients using Mac OSX 10.4.11 now can copy files via their mapped drives while using the GUI finder without receiving an error.

The problem had been caused by client PIDs being sent to the filer with values of 0 rather than with their correct values.

File tracking archive searches no longer hang and cause OMDB transactions to be held open for extended periods of time.

Under certain circumstances, a place rule may re-scan directory contents if it encountered an error during the volume scan. If the rule re-scanned directory contents of any directories, them the "Files Scanned" field in the output of "show policy" no longer displays a "% complete". Note that the "Files Scanned" value may exceed the total number of files in the volume. The "First Time Migrates" field and the "Re-queued Migrates" field no longer get out of sync and incorrectly display 4294967295 as a value.

Previously, there were issues with how objects were handled by Active Directory. An optimization in the code path was made to improve the way internal communication is done between Secure Agent components.

A customer requested we add Sync Share functionality to the ARX Manager. You can locate this functionality now in the ARX Manager on the Managed Volumes Details Share Tab, with the Sync Shares button.

A customer running ARX Secure Agent saw that temporary services were not removed and that the anti-virus software was not restarting. This was fixed by adding a hot fix to this release.

Previously, there were policy free space issues after a failover. The event processor now waits for the volume to be up and getting free space before events are processed.

Automatic Volume Sizing (AVS) was running too slow. When Automatic Volume Sizing was disabled, the AVS_NEAR_MAX_CAPACITY trap would trigger too early on small capacity volumes. It now traps when there is either 10 percent or 2M files free in the volume, whichever is smaller

The file tracking archive behavior was holding database transactions open for so long. We now we use a separate transaction for each rule. This limits the time a transaction is open to one set of archive operations.

After removing the smtp configuration, the box continued to send emails. This has been fixed in the software by reissuing some commands, including the exit command.

The software raised fan failure traps as a result of running a collect. This was remedied with a simple FPGA fix.

When calculating internal mappings for a subshare in a particular CIFS service to back-end shares in a volume, the ARX is no longer confused by like-named subshares that point to other volumes.

Constrained Delegation on the ARX did not function for multiple-tier authentications where an SFTP server was tier 1. That is, if an SFTP server delegated to the ARX-CIFS service, and the ARX-CIFS service in turn delegated to a CIFS server behind it, the SFTP clients could not get directory listings.

32938, 39223
If you have a router between the metadata file and the ARX, its possible that the ARX will receive an an ICMP unreachable from the router causing a service interruption(DNAS crashing and restarting). The ARX now handles ICMP unreachable from NFS metadata filers or routers in between.

Samba-based filers are implemented without "Domain Admin" privilege configured within the proxy-user. The samba server privilege probe now verifies that the proxy user is properly mapped to root.

The source IP in a message should be the ARX proxy-IP address, but for some reason, it's was the file server's IP. The fix was to correctly log the ARX proxy-IP address as the source IP address in the log message (instead of whatever information was left over in the buffer).

The interface was not removed from the vlan that had just been deleted. The code now removes the dangling interface.

Customers requested that ARX Secure Agent not use windows temp directories. The new version of ARX Secure Agent now uses regular directories within the Secure Agent folder instead.

Under heavy load, it was possible for the NSM periodic cleanup functions to be starved and not run to completion and return filer connections that have gone down to the free pool. This could cause the NSM to run out of connections and be unable to service more clients. The periodic cleanup functions were changed so that this situation no longer happens.

The ARX previously considered a domain controller (DC) in another Active-Directory forest to be "unusable" if it had a particular security setting. (This status appeared in the output of the show active-directory status CLI command, or its GUI equivalent.) The DC security setting was "Minimum session security for NTLM SSP based (including secure RPC) clients", set to require 128 bit encryption. Now, you can enable this security setting on a Windows 2003+ DC in another forest and the ARX recognizes it as useable.

34630, 31831
All operations are now queued and executed asynchronously. Furthermore, TCMD does not reorder operations and always insert new operations at the end of the programming queue.

An NSM cored after a customer failed over its peer. This was due to a rare race condition and we implemented a solid reference counting scheme for this affected object.

We added a configurable parameter (maxResilverMinutes) to extend the timeout used for re silvering NVRAM to its peer for hardware redundancy.

Previously, no warning was provided when a reload was issued and startup-config was deleted. One is now provided.

An ARX-4000 became unresponsive until it was rebooted and logging failed. This was fixed by a firmware upgrade for midplane raid controllers.

The ARX now has increased capacity for NFS ACLs from 512 to 1024.

show firmware upgrade now indicates the correct status messages.

After issuing a reset, the box took too long to respond to pings. The fix was to make the raid status reporting software do the right thing when one of the physical raid drives is either physically missing or behaving as if it is physically missing.

When shares in a presentation volume have multiple attach points to managed volumes, the 'show host... path' used to display wrong path information. The fix was to use additional qualifier for the attach name when querying the OMDB for path information.

Due to an atypical configuration, a customer experienced a dual NSM core when restarting the ARX Manager. The fix consisted of cleaning up state when a user removes a file server whose connection is down. Previously, this left over state prevented a user from reusing the IP address.

A customer added an NFS list and experienced a core. This was fixed by fixing a lock around a call record.

The ARX had HA synchronization issues and now the ARX now has improved HA capabilities.

There was a display issue with show channel stats with Good Oversize Frames = 0. Now you can see Good Oversize Frames value increase as you send jumbo frames.

The ARX4000 display is counting frames that have a size between 1519 and 1521 bytes in the 1522-2047 bucket. The display correctly counts frames in the 1522-2017 range.

A tier1 rule got reset because it could not put a notification on the notification queue. The notification was the result of a rename. Renames will no longer cause the rule to reset.

A customer experienced errors in the show system status output due to incorrect CPU data. The code now uses CPU scaling and CPU data now displays correctly.

A policy appeared to be aborted. The code has been fixed so that we will not exempt internal admin client connections from tearing down file server connections/sessions. As long as policy releases all the connections, the file server sessions should get refreshed and any credential change in the back end should take effect. In addition, there is a new option to terminate all outbound file server connections used by the internal admin service.

The ARX filer-subshares feature sometimes creates shares on back-end file servers that begin with the prefix "_acopia_". Such share names have a well-defined syntax, and the ARX assumes that it is free to manipulate these shares. With this fix, the ARX is now more robust in its handling of "_acopia_" shares that do not follow the correct syntax (for example, shares created manually by a curious and inquisitive admin user). F5 strongly discourages manual creation of back-end shares whose names begin with the string "_acopia_".

In some cases, a busy file server and a busy ARX can cause the login process from the ARX to the file server to be altered - changing the timing of messages. In some rare cases, when authorization fails on the first attempt to the file server, the NSM that initiated the login would crash. This condition is now handled and the second authorization attempt will proceed normally.

Since upgrading, a customer got warning messages in the ASA log and Application section of the event log. We now include the V5.1.5 HF2 secure agent kit, which fixes the problem. in the ARX software

21759, 36546
There were issues found with parent rename and directory renaming. Windows file servers will not allow the manipulation of directories that look like DOS device names (for example: COM1, LPT1, AUX). Unfortunately, Windows doesn't prevent the creation of such directory names. The ARX has to prevent the creation of directory names that would cause offense on file severs that won't accept them. These restrictions are enforced dynamically, and only happen if there are Windows filers in the volume. If a pathname includes a DOS device name as a pathname component, files/directories underneath that directory cannot be placed or migrated to a Windows file server. Also, a rename that would create such a pathname on a Windows file server is not allowed. Additionally, if such a name is discovered to exist on a Windows filer, the ARX will not import it. sync/import/inconsistency reports note the reserved names when they are encountered. Client-initiated proxy operations fail with ACCESS_DENIED and a log message. The corrective action is to rename the directory to something acceptable.

The number of supported attach points was not clearly define or enforced. We now count and enforce the maximum number of attach points that are allowed to be configured. Second, we now restrict the length of the front-end and back-end paths. This reduces memory consumption.

A customer was reloading the primary switch in an HA pair to recover from an NSM core. During the shutdown, the secondary switch lost access to the quorum disk. This caused the secondary switch to reboot per design because it cannot access the quorum and does not have heartbeat from the primary. The code has been fixed to keep the switch from losing access to the quorum disk.

A customer experienced CPU spikes and a performance degradation due to subtree notify changes. We now have a default ignore-subtree-flag setting that fixes this issue.

The ACLs are not migrated when tiering data to T2. We now treat oversize ACLs correctly.

A customer experienced a state where no "cifs auth stats" information could be retrieved with an snmp get command. Code changes were made to provide this information.

Syslog messages were coming every 5 seconds instead of once. Now we only report if the state has changed.

When trying to setup a trust between two domains, a customer got errors back that one of the DCs are offline, while the AD status shows them online. The ARX now checks the forest function level from any reachable DC and it only checks in the forest-trust configuration (Windows Active Directory ensures that only Windows 2003/Windows 2008 servers are used as DCs, checks to see if the forest function level is 2003 or above, and the forest function level can NOT be downgraded.

In NFS, a duplicate request sent by a client can, in very rare cases, receive two different replies from the file server: the first response yielding an error and the second response yielding a success. The NSM did not deal with this sequence properly (the verifiers did not match), which caused a crash. The ARX now handles this situation properly.

When doing a show global server, the WINS aliases did not appear. Now the code displays the WINs aliases.

37858, 36483, 37793
A customer experienced an NSM core. We modified the NSM watchdog mechanism to improve our chances to diagnose these types of issues.

A user outage was caused by a share import. The code has been fixed so this won't happen.

When a share was enabled for the first time, from the GUI or CLI, and that share had no free space, it used to return an error that needed to be either more clear or changed entirely. This error message has been updated and known results of the write test be returned to the user.

A customer experienced a core because a file request timed-out. Now we do an extra look up for the object and rely on the file server response and not the object for the valid response.

Under load, a CIFS client may issue multiple close requests to close a file (since there can be a delay in the response to the first close). When this happens, it was possible for the NSM to crash upon receipt of the response to the second close request since the NSM would access a freed object. This situation has been fixed to account for this possibility.

A customer experienced a failover event that took 15 minutes for the VIPs on switch A to become accessible. Whereas the two VIPs on switch B are accessible instantly. This was due to a MAC addressing issue and this issue has been fixed.

Some clients who ran Excel macros at the end of the day said that the macros took a lot longer to complete than expected. We have fixed the software to no longer require OMDB access and no longer require a listener.

Previously, when the Shadow Copy Rule Edit page was accessed, the Publishing Mode drop-down was set to "Individual" regardless of the active shadow copy rule configuration on the ARX. The Publishing Mode drop-down box now sticks and matches the global-config.

The software has been enhanced to include a new feature on the import report. When an import fails, for "Pathname not found during lookup" an entry now displays the actual path name.

We have enhanced the software to help define disaster recovery terms more clearly. We removed the "force" argument from the "remove-share nomigrate' command. We now say "remove-share offline" instead of "remove-share nomigrate force". For the global namespace volume share "no filer" command the "force" argument has been changed to "offline." And lastly, for the global namespace volume, the optional "force" argument was also changed to offline.

The ARX Manager became inaccessible after a core. The software has been fixed to restart automatically.

On a customer cluster, the ARX Manager is very slow to respond to listing request. We have restructured the way we store the policy configuration information in the ARX so that we can more efficiently retrieve the information when the CLI or GUI request it.

The ARX did not allow RADIUS authentication of users when RADIUS network device filters were turned on. We made fixes to the radius client code on the switch and the NAS-IP-Address is now returned.

When "haPairQDiskFreespaceWarningRaise" trap was created, it did not list in "show health". The code has been fixed to display this trap under show health.

The code was enhanced to move this message to LOG_DEBUG: "Could not properly determine the "active LIP" PIP; the SCM LIP address defaults to INADDR_ANY"

A customer experienced an NSM core. We fixed the assumption that the transaction2 operation responses always come from the file server. Transaction2 operation responses also come from the control plane. This log parameter mismatch was fixed.

A customer experienced a frequent pop up message concerning ARX Secure Agent. This was caused by a race-condition in the code between use of an object and freeing the object and this conflict has been fixed.

Watchdog timeouts caused two NSM cores. The code was fixed by changing the timer from 32bit to 64bits.

The ARX Manager has been enhanced to allow setting the WinRM port. This setting is now configurable from the File Server Add page or when you configure managed volumes using the wizard.

Occasionally, a shadow copy had failed during target volume rebuild. We change the way that the shadow volume receiver decides database rebuild by making the shadow volume receiver less sensitive to a single not found error.

The ARX Manager now displays the Place Rules report on the Place Rules Details page Current Scan Stats and Last Scan Stats.

Polling to a configured time server would continuously fail transmit and/or receive if it was configured on the ARX prior to an ARX network interface change. This sometimes happen when executing a saved running-config script, where numerous configuration commands are executed in rapid succession. The ntpd daemon was modified to automatically reconfigure its association with a time server after a maximum number of transmit/receive failures.

When a back-end share filled up behind a managed volume, and one of its CIFS clients attempted to change permissions on one of that share's directories, all of that managed volume's CIFS sessions hung. An administrator needed to increase the size of the share (or, in some cases, the NetApp quota) to restore CIFS service to the managed volume.

The ARX now detects disk-full conditions on its back-end filers, blocks client operations that could result in a widespread loss of service, and allows CIFS clients to resolve the problem by removing files. The ARX also sends SNMP traps to alert you of any directories or shares that are adversely affected by an out-of-space share. (See the SNMP Reference for full documentation on all SNMP traps.)

When an SNMP trap raises an alarm condition, the alarm appears in the output of the show health CLI command until it is cleared by another trap. In previous releases, there was no manual method for clearing these alarms. Release 5.2.0 introduced the clear health CLI command for this purpose.

In a filename fileset, recursion did not function when matching directory paths.

Snapshot delete operations on NetApp filers now retry when the snapshot is busy due to a snapmirror operation.

The /acopia/var/log/raidupgrade.log file now includes an entry for each time that the upgrade script was executed.

A problem that caused user-defined login banners set from a file to not survive reboots has been fixed.

The output of the collect state CLI command now includes syslog, procdat, and traplog output. For more details, see More Logs in "collect state" Payload.

Only the single cluster name is displayed now in the GUI when configuring disaster recovery and only one cluster has been configured.

A problem in which the renaming of a file on one share failed because a file with the new name existed already on another share has been fixed.

A firmware upgrade failure that caused the software upgrade process to fail when migrating to Release 5.2.0 has been fixed.

The show cifs-service client-activity CLI command has been improved to display the accurate number of user sessions per client.

A problem that caused filename collisions during the use of the nsck rebuild CLI command has been fixed.

The show cifs-sessions open-files CLI command now displays virtual pathnames accurately.

An internal error that caused errors accessing data on managed volumes, along with insufficient resource error messages, has been fixed.

A problem that caused age-based filesets to be displayed incorrectly has been fixed.

An internal problem that caused the creation of a core file has been fixed.

An internal problem that caused the creation of a core file has been fixed.

Many attempts to find files across directories with very large numbers of files no longer result in stranded or unresolved searches.

An issue in which performance degradation was caused by an excess of notification messages when a volume was accessed has been fixed.

A background process configures all attach points (in presentation, or direct, volumes) after a failover. In a system with a large number of attach points, this sometimes required several minutes. If another failover occurred before the process was finished, that failover sometimes required nearly one hour to complete. This fix dramatically increases the speed of attach-point configuration and failovers: the same configuration now takes approximately 1 minute.

Version 5.1.9

Release 5.1.9 included the following enhancement:

Enhancements were made to the readdirplus operation to improve performance for some clients.

Release 5.1.9 also included the following fixes:

When a managed volume imported its shares using NFSv2, some files and directories were occasionally missed. The import succeeded, but the missed files/directories appeared as inconsistencies. Now an NFSv2 import captures all back-end files reliably.

Back-end snapshots went to the wrong NetApp volume when the NetApp volume met the following criteria:

  • it had a physical path that was different from its "masqueraded" NFS-export path
  • the "masqueraded" path matched the path of a different physical volume,
  • the "masqueraded" path started with "/vol", and
  • the "masqueraded" path was imported into an ARX volume that supports snapshots.

Now the ARX takes snapshots of the correct (physical) NetApp path.

At some customer installations, two Microsoft Windows Server 2003 hot fixes (KB2478971 and KB2478960) were causing the ARX to mark the server's shares as "offline."

348799, 39560, 348979
Previously, when an NTLM server was removed while thousands of NAT rule actions were installed and in the initial state, the NSM watchdog could expire because the removal of the rules took longer than the watchdog allowed. Now, the watchdog continues to be serviced while the removal of NAT rule actions completes.

340621, 349934, 343576
If an ARX failover occurred while the redundant peers had connectivity issues, the ARX peers sometimes failed to re-pair. Now the pairing succeeds if connectivity is restored within six minutes, possibly even if the connectivity is only sporadic.

When a switch replacement in a redundant pair repeatedly failed, clients had difficulty accessing the active ARX's front-end services.

Windows 2008 snapshots no longer fail when the Windows file server has more than 20 mount points.

Temporary files that are created in /acopia/reports/tmp during report copy operations now are deleted properly following execution, and no longer prevent the generation of new reports.

A problem that caused slow performance ("WORKSLOW") messages to appear in the syslog has been fixed.

347298, 347192, 348800, 350191, 350964
The Network Services Module could generate core files when it receives multiple client requests that need to be sent to a filer, but the authorization credentials to that filer generate a failure (for example, a LOGON_FAILURE). This issue has been corrected.

Displaying the security for an NFS mount from a client no longer causes the ARX to show the security for the mount incorrectly as "none".

344676, 342783
This fix involves changes made to assure Db-scope garbage collection is set to every 10,000 transactions after creating a new database.

A problem in which a report of space running out on one share caused loss of access to other virtual IP addresses and exports has been fixed.

341991, 342263, 343348
NSM cored due to taking too long when reassembling a long packet when there are many fragments. This issue has been addressed and fixed.

When a presentation (or direct) volume has an attach point into a managed volume with snapshots, the "~snapshot" directory was not always visible in the attach point. This only occurred if the attach point attached to one of the managed volume's subdirectories. For example, suppose a presentation volume, "/pvol", attaches one of its directories ("/pvol/attachDir") to a managed volume, "/mvol", at "/mvol/dir1/dir2." A client's directory listing of "/pvol/attachDir" did not include a "~snapshots" directory before this fix; now it does.

When a CIFS client's password expired in the middle of a connection to an ARX service, the ARX network software failed and created a core-memory file.

The Temporary file attribute for files and directories now is ignored.

The show file-history archive ... contents operation failed for volumes with very large numbers of files (20 million or more).

When a file migrates to the ARX Cloud Extender (ARX-CE), the ARX-CE compresses the file and sets its "sparse file" attribute. Formerly, a file that migrated to the ARX-CE, then to an EMC Celerra, and back to the ARX-CE would be corrupted on the final migration. This is a file-server issue, caused by different uses of the "sparse file" attribute. Now the ARX works around this issue, so this migration path does not corrupt files.

Version 5.1.7

Release 5.1.7 included the following fixes, also included in this release:

Improvements were made to the performance of CIFS directory enumeration in very large directories.

Some operations (in particular metadata migration) failed to use the configured SPN as they should have. This prevented the operations from working when using a clustered Windows file server. This has been fixed to use the configured SPN.

A customer experienced a problem after performing a "shutdown" as part of DR test. When the box was powered back up, there was an error with the object manager database (which was then renamed), and the box came up without a configuration. This problem has been fixed.

343426, 27298
A problem that prevented users from deleting directories from home drives when using Windows 7 and DFS has been fixed.

When an NFSv2 client used the chmod, chown, or chgrp command on an ARX-volume directory, future ls -l commands erroneously showed a timestamp of December 31, 1969. The timestamp display issue has been corrected in this release.

ARX was unable to sync folder attributes. We made a change code so we log an internal error instead of sending a back packet. Debug logging now shows the exact type (MSGX_TOOBIG == 5).

38544, 38346, 38587, 38588,
An NSM crash could happen in cases where there are connectivity/networking issues with a domain controller. While waiting for an authorization response from the control plane, the back-end file server could tear down the TCP connection, causing memory corruption when the domain controller finally responds. The NSM now detects and corrects this situation to properly return an error to the client.

An NSM crash could occur during network outages - specifically when back-end file servers tear down TCP connections to the ARX. This was fixed by more properly handling internal objects when this happens and not cause memory corruption in the NSM.

An NSM crash could happen in cases where there are connectivity/networking issues with a domain controller. While waiting for an authorization response from the control plane, the back-end file sever could tear down the TCP connection, causing memory corruption when the domain controller finally responds. Now, the NSM detects and corrects this situation to properly return an error to the client.

Previously, the client never cached any directory information, so it was forced to always run ls to ask the ARX for all the information. Using ls would always appear to be uniformly slow. A user would not see this with NFS clients & servers, since there is always some locality of reference. Now, repeated references to the same directories can be satisfied (almost) completely from the client's local directory cache, so it is much faster.

A customer experienced an NSM core on an HA pair, for twice on each, and a total of 4 times. We no longer process TCP ACKs for RON packets which have not finished being transmitted.

There was a corner case where DNAS and the NSM lost communications of the DT message path and the NSM began to reconnect. In the meantime, the NSM was still processing NFS requests and attempted to send a lookup to DNAS, which failed. As part of the cleanup processing there was an attempt to release a DT message that was never allocated. This resulted in the NSM coring. We now check that the DT message path is in the connected stated before attempting release any DT resources.

During a forest-to-forest trust configuration the Win2K8 R2 DC was not accepted. This is now fixed, but you must not configure the forest trust, but instead configure the kerberos-auto-realm-transversal.

Two new CIFS shares were added, one to the /data volume and one to the /data directory, which resulted in a core. The boxes ping-ponged until they reached the bounce limit. This was caused by a piece of code that was used to protect us from a volume name of "/". We now double check for the volume name and avoid this issue.

336269, 35475
An NSM core happened due to a double free of a presto packet in an NFS path coupled with a network outage,which resulted in a buffer corruption. The NSM can now send traffic to a file server in this situation without corrupting the buffer.

37422, 37992
During an upgrade, a virtual server hung in the starting state until browsing was disabled and then the global server went to enabled. Browsing could then be enabled again without incident. Now the volumes are enabled and assigned to an instance,which fixes this problem.

38789, 39336, and 39818
The ARX failed to reboot and fail over after an internal-disk (RAID) failure.

Shortly after a failover, the ls command hung in one of the ARX's NFS exports. This was due to a rare race condition in one of the network processors. The race condition is resolved in this release.

Database (DB) access through an ARX-CIFS volume failed when several DB-access commands were run in a macro. The ARX volume sometimes returned a "Disk or Network Error" message to the CIFS client running the macro.

If an NFS client issued a /bin/ln command in a direct (or presentation) volume, the ARX volume sometimes responded with a spurious ESTALE error.

Version 5.1.5

Release 5.1.5 included the following fixes, also included in this release:

Previously, when the "count" form of "ip proxy-address" was used after the hardware was set up, then the resultant EIP records were delivered in non-ascending order of EIP address. If the EIPs are processed out of order, then the LIPs for XIPLIP assignments were also out of order (and incorrect). The code has been modified to so that any out-of-order processing of EIP listener events won't cause any problems.

The CLI daemon now correctly reports that no transactions are left after completing CLI commands.

Fix to ensure "no modify" import failures continue for non-mappable directories.

etch bash had a memory leak in the built-in read function.

Linux kernel bug that caused services to be unavailable after aborting a CLI "copy" when using NFS.

Enhancement to provide CLI option to change the Minimum Retransmit Timeout (RTO Min) in effort to better manager packet retransmissions.

CLI option to change the value we use to re-initialize the RTO after we've recovered from a period of packet retransmissions.

Apple and Kerberos compatibility improvements.

Fix to improve share removal function by making retries more robust.

38714, 38511
The CLI daemon no longer crashes\cores when running "show reports".

Fix to prevent DME from crashing and triggering a reboot.

Packet capture using the "proxy-all" option was not capturing all packets.

MAC OS 10.6.X clients were unable to see sub folders.

Added CLI command to optionally change the LACP timeout from "short" to "long".

Fix to address SSB read failures and falsely indicating fan failures.

Fix to preserve the "Modify" time when doing a migration.

System wouldn't boot with long host name. Host names now limited to 32 characters.

Setting the nfs-param rsize or wsize failed for direct (presentation) volumes.

A share that failed import and subsequently removed from ARX configuration left remnants in DNAS system which then prevented the share from being imported later.

When changes are made in a directory, the wrong number of files is returned when doing a directory listing.

If an ARX file system erroneously mounts a partition as read-only, the ARX now triggers a reboot to restore function.

Disallow importing admin shares such as C$.

An attempt to use a connection to a filer to add a share failed after a previous failed attempt did not delete the failed connection.

Small IP fragments were being handled incorrectly.

The clock on an ARX6000 ASM could drift in time if the SCM did not respond to a request to provide the correct time. ASM clock synchronization function now times out if the response is not received in timely manner.

If the backup peer rebooted while an administrator was changing the global configuration (such as managed-volume configuration), an internal fault could occur that only manifested itself during a later failover. The error rendered the global configuration incomplete on the backup ARX. When a managed-volume configuration was incomplete because of this issue, CIFS clients were unable to access the volume's storage.

Fix to ensure that when you press the key on the no enable namespace command, you drop back to the CLI with no action taken.

A software change to help identify who has open files on system mount point when an un-mount fails.

39645, 39394
A fix to prevent an NSM core by ensuring disconnect cleanup.

Erroneous error message (SSRM-0-ERR-SSRM_TOO_MANY_VSRECS) has been removed. This only manifested if multiple volumes used the same metadata share.

Device nodes in a multi protocol share that have case collisions could not be transferred.

An import missed files because a failed import share was re-enabled before the other shares had finished importing.

Multi protocol import was very slow due to volume being locked. Lock type changed to improve performance.

Delayed acknowledgement methodology caused NFS migration performance problems.

The Prune Target check box in the GUI's Edit Shadow-Copy Rule screen was persistently checked. If the prune-target feature was disabled previously, either from the GUI or the CLI, the GUI always displayed it as "enabled."

There was a bug in the ARX500 Macau FPGA upgrade handling.

The migrate close-files failed with "access not permitted". Now, in a multi-protocol namespace that contains ntfs-qtrees, the ARX will check if the file is open before trying to migrate it.

When DCs in the local Active Directory gave repetitively slow responses to Kerberos/UDP queries, the ARX's network processors sometimes ran out of UDP ports.

37121, 37945
Previously, in the presence of authentication failures (typically due to mis-configuration), the NSM would crash while attempting to properly logoff in-progress CIFS sessions on a file server.

The SNMP trap, dnsServerOffline, did not include the failed server's IP address in its message text. The CLI show health command, which shows only the name and the message text of each active trap, therefore did not show which DNS server had failed.

Reports from a file-placement rule did not include the rule's namespace or volume names.

The ARX was mishandling incoming 'Query Path Info' requests that were fragmented over more than one TCP segment.This is a regression that was introduced in 5.1.0 and is now fixed.

Previously, the ARX Secure Agent, using fgdump, was stopping and restarting the anti-virus software. Now, the SA won't stop and restart anti-virus software during its scan phase.

An ARX Manager error report option was confusing as it was different between Edit Place Rules and Edit Snapshot. It now reads "Auto delete if no errors" in both places.

The CLI help text for the cifs authentication command neglected to mention NTLM. Now it mentions NTLM.

The reporting of no modify import for directories that are DFS links was incorrect. Now, the report should list an error of 'DF' which indicates that a DFS was found. In addition, the report should lists the directories that failed.

A failed import of a higher priority share in one volume no longer impacts the scheduling of an import of a lower priority share in another volume contained in the same VPU.

The start-time option for collect logs was not adhering to the specified time constraint. Now the CLI help spells out the correct time formats to use for collect logs.

If an import of a share with no-modify enabled resulted in a case-blind directory name collision the process failed with a -70 internal error. A -70 internal error will no longer be returned for import reports or in syslog.

After entering start (without a date/time) for a schedule, the place rule moved the wrong files. This has been fixed by removing the auto-adjust start time.

Email home did not check slot temperature. Now it does check slot temperature.

A core was generated by a race condition and memory leak.

Users were unable to view the contents of the snapshots from the previous version tab. When they clicked on the snapshot, it produced an error.

There was inconsistent output between the global-config and namespace.

The ARX Manager was not displaying proxy-user in the file history archive. The proxy-user now displays correctly.

The snapshot reconstitution script is not working with reports generated by ARX. The reconstitution script now works correctly.

The kernel.log file contained an excessive number of the following messages:

EDAC i5000 MC0: NON-FATAL ERRORS Found!!! 1st NON-FATAL Err Reg= 0x80000 

EDAC i5000: THERMAL Error, bits= 0x80000

The ARX kernel now logs an appropriate number of these messages whenever the issue occurs.

The ARX code spuriously declared its Domain Controllers (DCs) to be "slow" if its DNS server required more than 2 seconds to respond. Most of the DNS queries from the ARX were unnecessary, and this caused the ARX-Kerberos processes to repeatedly switch from one redundant DC to another. The ARX Kerberos processes no-longer send out unnecessary DNS queries.

The capture session operation unnecessarily duplicates internal TCP-ACK packets, and continues to duplicate them after you stop the capture session. (This duplication does not occur for an ARX500 chassis, or for any capture session that captures packets to/from all proxy-IP addresses.) Now the no capture session operation stops the internal packet duplication.

The domain-join operation resulted in an ADJOIN_PWCHANGE error for some network configurations. This occurred when an external routing device allowed traffic from the ARX's proxy-IP addresses to the domain controllers (DCs), but dropped traffic from the ARX's management-IP address. An internal ARX issue caused the ARX to incorrectly send some domain-join packets from the management-IP address instead of a proxy-IP address. As of this release, the ARX sends all of its domain-join packets from its proxy-IP addresses.

Disk drive numbering in the ARX2000 Installation Guide has been corrected to identify Bay 1 as the top drive and Bay 2 as the bottom drive. This numbering matches the CLI drive designation and the labeling on the switch. The LED documentation has been updated to indicate that flicker indicates drive activity.

There was a problem with the default route in NSM, which caused several NSM cores around pro_arpcache.

Member itemization was not right in an error message. The correct variable now displays in the error message.

A customer experienced an XSDD core.

If a volume had a connection failure with its CIFS-metadata share, and then someone attempted a metadata migration before any client accessed the volume, the metadata migration failed with a VOL_MDMIGRATE_FILER_PROBE_FAILED error.

37067, 37331
An NSM-core processor, on rare occasions, failed when a CIFS client performed a FIND operation.

A Linux client with cifsvfs could not copy one file over another. The error was "Permission denied."

The GUI screen for setting a schedule (Policy -> Schedules -> Add...) sometimes created schedules that never fired. The check boxes under Interval -> Weekdays were ineffective.

The GUI field for editing a Place Rule's report prefix had no effect. The specific field was Policy -> Place Rules -> rule-name -> Edit -> Reports -> Prefix.

The GUI did not allow a storage-engineer to delete or verify snapshots. (A "storage-engineer" is an administrator's login account where the assigned admin role is "storage-engineer.")

A drop-down menu was malfunctioning in the GUI. The malfunctioning menu was at the following path: Policy -> Snapshots -> rule-name -> Rule. Whenever you used the drop-down menu, it reverted back to the first snapshot rule in the volume instead of the selected rule. Now it stays set to the selected rule.

When importing a volume in no-modify mode with multiple shares that are expected to merge, and you have "no import sync" and "no import rename-dir," and when the import hits a Case Collision or potentially some other variables, instead of continuing and doing a delayed fail as it should, the import fails immediately. There are two solutions. If you have run an import with "no modify", "no import rename-directory" and "no import sync-attributes", then with an attributes collision during import the report will show the directory which has attribute condition is marked as "skipped." If you do an import with "no modify", "no import rename-directory", with "import sync-attributes", then if you have an attributes collision it will log the inconsistency, stripe the directory, and continue to descend into that directory.

If you ran the show policy details on a volume with a rule that never ran before, the show operation reported an XSL transformation error. This error also appeared for collect diag-info, which invoked the show policy details command.

A file-placement rule failed at volume-scan time whenever a higher-priority rule with no volume-scan matched any the same files or directories. A no volume-scan rule can now co-exist with any other rule, without causing the other rule(s) to fail.

After removing an active-directory alias that was never accepted by any DC, the ARX software did not send an spnAliasUpdateClear trap. This left a persistent alarm condition, spnAliasUpdateRaise, on the ARX.

The no active-directory alias spn CLI command did not remove the SPN from the ARX database until the local DC removed it from the Active Directory DB. Now the ARX DB removes the SPN immediately, and the ARX software continues a background process to delete it from the Active Directory.

When the spnAliasUpdateRaise alarm appeared in the output of the show health CLI command, its Description field started with a "." character.

The active-directory alias operation failed for an ARX VIP unless the VIP's CIFS service was joined the "COMPUTERS" OU.

A crash resulting from race condition during file attributes update no longer occurs.

An error in the power-supply numbering has been corrected in the ARX4000 Hardware Installation Guide.

The following spurious message kept repeating in the error.log file;

SnapshotOp::setupSnapshotCreateGroup: Waiting for 'n' - 'm' more ckpt config records.

The ARX software no longer generates this log message.

The following unclear message appeared in the syslog whenever a volume lost its connection to its metadata share:

bdb_get_metadata_size(): cifs_shim_fstat on fd=134217738 failed [-1].

This message has been suppressed in favor of clearer log messages.

The show statistics cifs-auth command had incomplete statistics for unsupported protocols. If a client attempted to authenticate with an unsupported CIFS protocol, the resulting failure was not counted in the main output of show statistics cifs-auth. Now it is.

The ARX's Network Services Module (NSM) terminated abruptly if a filer responded with a different SMB command code than the one that the ARX had sent. The ARX now compares the filer reply with the request and drops the reply in the event that they do not match.

The ARX's NFS proxy was not sending keepalives on all connections to the filers. This was addressed by forcing the transmit thread to use the connection from the keepalive process.

Using the CLI to copy files within a CIFS namespace sometimes caused an internal database failure.

Under certain conditions, the active ARX global configuration could become corrupted if the initial pairing of an HA pair failed due to timeout conditions. This problem has been fixed, and the active global configuration is no longer affected if the backup ARX does not pair with the active ARX.

On the ARX 500, when an IP address was added to an interface that was on VLAN 1, the IP address could not be removed completely, because it remained in the ARP cache. VLAN 1 was being re-mapped to the primary interface when the IP address was added to the interface. The functionality for removing IP addresses was changed to correct this.

Timeouts pertaining to certain internal operations occasionally caused volumes to go offline, preventing the ARX from acquiring the free space of targets. This has been corrected.

Large numbers of TCP duplicate packets were being generated and were visible in network traces. This has been corrected.

An issue with the ARX's file-tracking functionality that caused failures in some cases has been fixed.

A problem that caused an outage during the import of shares has been fixed. Now, if a higher priority share fails to import its root directory, any lower priority shares will fail to import as well.

A problem in which the deletion of a snapshot rule for which there were snapshots present prevented the browsing of other snapshots has been fixed.

Mac OS X 10.6.3 clients were timing out when copying large directories into direct volumes.

Mac OS X clients were timing out when copying large directories into an ARX managed volume.

Long role names were causing SNMP traps to be sent to an E-mail address after that address had been removed from the trap-recipient list.

Version 5.1.0

Release 5.1.0 included the following fixes and enhancements, also included in this release:


Release 5.1.0 added the following new features to the ARX:

Release 5.1.0 supports the new ARX®2000 hardware platform, which is a 2U device with 12 1Gbps interfaces.

The ARX Secure Agent was causing excessive logging. The code has been fixed to squelch excessive health checking.

A Multi-Protocol Volume Supports NFS Symbolic Links (Symlinks) for its CIFS Clients
As of Release 5.1.0, a multi-protocol (NFS and CIFS) volume can display NFS symlinks to its CIFS clients, and allow its CIFS clients to traverse those symlinks. For example, if an NFS client creates a symlink named "pointerDir" that points to "randomDir," any CIFS client can cd to the "pointerDir" symlink to access the "randomDir" directory.

After an upgrade, this feature is disabled in any multi-protocol volume that existed before the upgrade. You must enable the feature for the volume's CIFS clients to see or access NFS symlinks. Refer to the Required Configuration Changes section for instructions on enabling this feature. Any new multi-protocol volumes, created after the upgrade to 5.1.0+, support CIFS symlinks by default.

This feature does not support absolute symlinks (such as a link to "/vol/vol2/myDir"). It supports relative symlinks, such as a link to "../myDir" from the current directory.

Limiting CIFS Connections To Tier 2 Filer Servers
Some Tier-2 file servers cannot tolerate a large number of simultaneous CIFS connections. Release 5.1.0 accommodated those file servers with a feature that allows you to set a maximum number of CIFS connections to such a filer. You can use a CLI command, cifs connection-limit, or its GUI equivalent to set this maximum.

Policy Enhancements
The policy engine offers a number of enhancements as of Release 5.1.0, including the following.

  • Finer Control Over Share Free Space
    Release 5.1.0 added per-share controls over free space. For each share, you can establish a volume or percentage of free space to maintain. All policy rules, including share-farm directives, avoid consuming this free space. If a rule attempts to migrate any file to any share, it first verifies that the file will not reduce the share's free space below this level. If the file would violate this free-space limit, the rule pauses and monitors the share's free space. Once the share's free space rises to a higher level (perhaps because of other rules), the rule can resume migrating to the share.
    For any given share, you can control the amount of free space to maintain and the amount of free space required for the share to resume accepting file migrations.
  • Regular Reports on Inline Migrations
    A file-placement rule migrates files between volume scans. This occurs inline, whenever a client changes the file so that it no longer belongs on its current back-end share. For example, if a client changes the name of a file so that it fits a new fileset, a placement rule for that fileset migrates the file as needed. As of Release 5.1.0, you can create hourly or daily reports that show the number of migrated files, their combined size, the number of failed migrations, and other useful statistics.
  • Scheduling Enhancements
    One or more file-placement rules, snapshot rules, or other rules can use a schedule to run on a regular basis. Release 5.1.0 added more options to the schedule, such as options to run on the first or last Tuesday of the month, or to run on the 1st and 15th of every month.

Support for NTLMv2
The Release 5.1.0 software supports NTLMv2 authentication for its CIFS clients.

NOTE: The 5.1.0 release of the ARX Secure Agent (ASA) also supports NTLMv2, and is required for the NTLMv2 implementation. Upgrade all ASAs to the 5.1.0+ release after you upgrade the ARX beyond 5.1.0. Refer to the Required Configuration Changes section for instructions on upgrading the ASA software.

Kerberos Enhancements
Release 5.1.0 offered two enhancements for CIFS clients that authenticate with Kerberos:

  • Better Reliability in Lossy Networks
    The Kerberos software now uses TCP for its network communication instead of defaulting to UDP first.
  • Support for Forest-to-Forest Trusts with "Selective Authentication"
    In a Windows network, you can design a forest-to-forest trust with "Selective Authentication," where a specific list of Windows users in Forest A are allowed to access any services in Forest B. In previous releases of ARX software, Kerberos clients in Forest A could not use ARX services in Forest B. As of Release 5.1.0, you can configure the ARX software to use a special algorithm, auto-realm traversal, to fully support clients from the other side of a selective-authentication trust. From the CLI, you can use the Kerberos auto-realm-traversal command to use this algorithm.

Share-Import Priority
Release 5.1.0 introduced the import priority command to make a managed volume's file and directory mastership deterministic. A master directory is a directory in a managed volume that has duplicates on multiple back-end shares; one share has the master instance of the directory and the other shares have stripes with the same name, permissions, ACLs, and other attributes. A master file keeps its name, whereas matching files on other shares must change their names. You can use the new import priority command to set some shares to priority 1, so that they win mastership for all of their files and directories. This mastership is deterministic; higher-priority shares win mastership on every import and re-import.

Together with Seamless Import, which imports multiple shares while allowing full client access, this feature is a stepping stone toward a full DR solution. An import at Site A can now yield the same file/directory mastership as an import of the same data at DR Site B.


Release 5.1.0 added the following fixes to the ARX:

The CLI show exports command is intended to examine the shares on a filer or server before you define the server in the ARX database. However, the ARX requires a Service-Principal Name (SPN) to examine a Windows 2008 cluster, and the show exports command did not support an SPN option. Now it does.

Some users were facing "user known" when authenticating via NTLM. The code now includes a fix to remedy this issue.

Large file copies sometimes failed with "Error code 64: Network name is no longer specified."

Active Directory domain controllers would go into reboot cycle after installing Secure Agent 5.1.5 HF1.

A fix to ensure a user can browse into a newly created snapshot entry.

ARX-4000 units were erroneously raising traps indicating the nvram battery had failed. Implemented fix to raise the temperature threshold to appropriate level, thereby eliminating message.

A particular race condition during a managed-volume import could trigger an unnecessary auto-sync operation. The race condition occurred when one ARX client attempted to remove a file while another attempted to rename it. The auto-sync operation, designed to refresh a volume's metadata after import, had no effect.

If a client renamed a file to a similar name during a managed-volume import, such as "file.doc" to "FILE.doc," the import could hang indefinitely. This also caused hangs for client operations during the import. Renames no longer cause these import issues.

The ARX policy engine never recognized that a previously-full target share now had free space. If a placement rule's target share filled to capacity, the rule never resumed after someone added free space.

When the Path and File fields where left blank in the GUI's File History Query page, the query failed without specifying the entry problem. Now the GUI prompts for the missing fields.

In the CLI and in the ARX Manager GUI, the collect operation failed whenever you attempted an NFS-copy to a multi-protocol volume. Now, you can use both NFS and CIFS to send a collect file to one of the ARX's multi-protocol volumes.

The copy nfs|cifs operation, which copies files to an ARX volume, is not supported from the backup ARX. Former releases did not include an explicit error message to explain this; an error message in the current release explains the issue clearly.

If a non-critical process failed to start properly, the ARX rebooted and created a core-memory file. Now a reboot (and failover) only occurs if a critical process fails to start.

The file-tracking daemon sometimes failed to start after an ARX reboot.

GUI did not sort cells correctly when they contained both alpha and numeric characters.

The no shadow operation did not properly remove the shadow-copy database from the volume's file servers.

The policy pause namespace volume operation, followed by a no policy pause, inappropriately caused a volume scan to start.

The output from show load-balancing sometimes displayed the incorrect slot/port number.

The output from show policy sometimes showed a volume as 'offline' when it was not.

The show ip route command on an ARX4000 did not display "Mgmt" for the out-of-band management routes. It showed a VLAN instead.

This release resolves some Open-SSH vulnerabilities in previous ARX releases.

The ARX UI allowed a CIFS export with an illegal CIFS character, such as ":". It now blocks a name with any illegal CIFS character.

The ARX did not adequately support the removal of multiple shares from a single volume. Now it allows you to remove multiple shares from the same volume without any errors.

The CLI failed and created a core-memory file if an administrator entered the critical route command with an invalid subnet mask (such as "").

An internal metadata inconsistency caused a share removal to fail. (From the CLI, you can use remove-share migrate and similar commands to remove a share from a managed volume.) Managed-volume software can now successfully remove a share with these inconsistencies.

The online help was inaccurate for the windows-mgmt-auth CLI command, and it appeared next to the incorrect option.

If an administrator used an incorrect syntax for the copy command, the administrator's SSH connection hung.

The no wins command did not allow optional arguments for ease of use. Now it does.

When a managed-volume import failed due to a slow metadata share, there were no syslog messages indicating the cause of the failure. Now, syslog messages appear to describe the problem with the metadata share, and to associate the metadata-share issue with the failing import.

When a CIFS namespace had an NFS export and someone invoked the GUI's Virtual Services page, the GUI failed. The current release does not allow a CIFS-only namespace to offer any NFS exports.

The virtual server arx-name ? command should list the single valid VIP for the server, but it listed all the VIPs on the ARX. Now it only lists the correct VIP.

The show snmp-server command displayed no output unless there was at least one host to receive SNMP traps. (The snmp-server host command adds a host to receive traps.) Now the command displays the current SNMP configuration under any circumstances.

Kerberos was causing failure errors in DC logs.

NFS write throughput to Data Domain dropped to zero.

Neither the ARX4000 or the ARX2000 were fully supported for SNMP walks.

The ARX was in a "too many open files" condition.

The ARX was persistently stuck due to metadata inconsistencies.

Reboot required after running config applied in order to get NTP to work. This issue has been fixed by by moving ntp server config to the end in running-config, so that ntpd starts polling the ntp server after running-config is done, without additional reboot or reset ntp server.

A CIFS client could not traverse an NFS symlink to a directory. Release 5.1.0 introduced CIFS-Symlink Support to address this issue.

The serial number was truncated in the GUI. This issue has been solved by adding the 2-digit manufacturer code before the serial number.

Adding SNMP server information with a port number created two entries. Now it does not create two entries.

Managed Volume went offline after an upgrade. This no longer happens.

A Data Domain filer behind a managed volume caused the volume to advertise "FAT32" as its file system. Now there is a CLI command that you can use to set the advertised file-system name.

The ARX boot-config file was lost after a software upgrade. This problem has been fixed.

Asymmetric network reboots, even when not joined back in the pair. This issue is now fixed.

A VIP Created in the GUI was offline, but was online when created in the CLI. Netbiosd has been fixed.

A shadow copy from a pre-5.0.0 site to a post-5.0.0 site caused a failover at the source site. The current release allows a shadow copy to cross between these releases without causing a reboot.

The GUI's Status page reported an incorrect value for available Files Allocated. This issue was fixed in the GUI by calculating the remaining files based on hardware type not configured VPUs.

The GUI displayed a working CIFS service as disabled. This issue has now been fixed.

The GUI and CLI warning When disabling a share, have GUI and CLI warning messages match. The GUI warning has been updated to reflect the warning.

MPNS namespaces had poor CIFS performance, due to using UDP. The default now is for Kerberos to request TCP.

Asymmetric read-only enabled by default on new share config. As of 5.0.1, we support NetApp environments where the cifs.ntfs_ignore_unix_security_ops option is set to "on."

Forest to Forest Trust did not work with selective authentication. Now there is a CLI command, kerberos auto-realm-traversal, that can configure the ARX to function with selective authentication.

Accessing GUI through IE took a very long time.This issue is fixed in this release and the pages no longer take a long time to load.

NTLM authentication server incorrectly shows offline if the IP address cannot be resolved by the ARX. This was fixed by adding 60 seconds before starting NTLM Secure-Agent monitoring during system startup.

In a redundant pair where one ARX is upgraded to 5.1.0 and its peer is manufactured with 5.1.0, an administrator experienced a delay in logging in after a reboot. A login was not possible until the ARX reached global scope (that is, until it was possible to enter gbl mode in the CLI).

Kerberos clients were unable to connect after an update 4.0.1. This issue is fixed and the ARX no longer advertises NTLMSSP in Kerberos namespaces unless they also have NTLM[v2] or else have anon-access enabled

A customer experienced a failure to replicate a subshare. This issue is fixed and now the ARX deletes all subshare mapping records instead of generated only records.

Full tree walks were happening after database rebuild, which was caused by the lack of synchronization in the shadow receiver. This issue was fixed by enabling the path lock at the right time and on right paths.

An internal error caused the show chassis command to hang, and it caused the ARX to send fanFail traps.

Watchdog reboots of slot 3 on both ARXes after upgrade. The fix prevents a possible reset of an ARX due to watchdog timeout for ARX6000s that are not directly connected on the redundancy link.

The ARX 1000 failed to send a Linkup trap after channel configuration. Linkup traps for each physical interface and the channel now work.

LIP_LIB & L2SW_LVL7 messages kept appearing every 5 minutes. The problem is cause because the ARX asks for Slot 2 processor 2 on an ARX 500, which does not exist this problem has been fixed.

On an ARX 500, GSMD (an internal software process) occasionally cored during ARX startup.

On an ARX 1000, the OOB mgmt no shutdown command did not work until reload. This problem has been fixed and it now works without a reload.

Smtp server names did not allow digits as their first characters. The ARX now complies with RFC1123 section 2.1, which allow smtp servers to have a hostname that starts with a digit.

The managed-volume software failed and generated a core-memory file during import. This problem has been fixed.

The ARX MIB was not compliant with RFC 2578. Now, the ARX MIB is compliant.

The Remove Share report did not indicate shares that had an "access denied" problem. The software now indicates in the remove report whether the error came from the share being removed or he relocate-dirs share.

The ARX would sometimes experience an NSM crash when processing CIFS traffic from previously disconnected trees. The ARX now properly drops this traffic.

GUI: Added new status icons to the Exports page. These now include all of the following: Offline (red star), Degraded (yellow triangle), Online (green circle),Read Only (yellow triangle), Not Found (red star), Unavailable (red Star), and Snapshot (green circle).

If power is lost to the ARX during the firmware upgrade process, the ACM processor gets stuck in downloading while booting up. This was due to a software change and the software has been fixed.

A Windows 7 client could not see any ARX snapshots in the "Previous Versions" tab. This tab now displays snapshots for Windows 7 clients.

In an ARX with thousands of direct-mapped shares, with at least one CIFS export per share, the GUI operation to show their mappings consumed all system memory.

An anti-virus (AV) scanner on a DC can potentially block the ARX Secure Agent (ASA) installation. (For details, see the in the Note in the Secure-Agent section of Required Configuration Changes, below.) Now a pop-up appears during the installation, prompting the installer to re-configure AV scans as needed.

Version 5.0.7

This was a Maintenance Release for the 5.00.nnn series of software releases. It did not include any new features or enhancements beyond those of Release 5.0.5. It contained the following fixes:

343546, 343015
A problem in ARX redundancy software prevented clients from accessing mounted directories.

A problem with TCP port allocation by the ARX that caused an NFS server to be unresponsive after ARX failover has been fixed.

345277, 343105, 345892
The issue with NFS clients experiencing access issues after a failover has been fixed.

346648, 346301
A bug in the NFSv3 TCP proxy code caused a buffer overflow, which resulted in memory corruption and crashes when a 64K WRITE was forwarded to the control plane by the NSM. This forwarding happens only when a client sends a WRITE request with a stale file handle as all other WRITEs are handled completely in the NSM. This has been fixed.

The ARX now reports correctly when a directory imported for multiple protocols uses the same name with different case characters.

Version 5.0.6

This was a Maintenance Release for the 5.00.nnn series of software releases. It did not include any new features or enhancements beyond those of Release 5.0.5. It contained the following fixes:

The cifs proxy could crash when enumerating files in a directory that contained many thousands of files which the user was prevented from seeing because access- based-enumeration was enabled. The cause of the crash has been fixed. DNAS cored because it hit an internal count limit during a Find-First operation. The internal limit has been raised so that the same event is not likely to happen.

A problem that prevented the customer from logging into the management console has been fixed.

If a CIFS-client application sends a packet with a pass-through Information Level, the ARX (which does not support pass-through levels) should reject it with a STATUS_INVALID_PARAMETER response. Before this fix, it was incorrectly responding with STATUS_SUCCESS. This created unpredictable results for the client application.

If the Active-Directory (AD) forests were configured manually on the ARX, it was possible to create a CIFS-access problem. The problem was that CIFS clients from trusted domains could not connect to front-end CIFS shares on the ARX.

The ARX didn't do symmetric routing w.r.t. VIP when NFS clients were on locally attached VLANs. The code change was to give precedence to the per-vlan default route if available.

A customer with an unusual VLAN configuration experienced asymmetric routing issues. This was fixed with a patch.

37512, 37464, 37472
Some customers experienced that NFS volumes were inaccessible until failover. Several changes have been made to the NFS proxy server and support software to correct the issue.

Policy rules were stuck in a "Migrating" state after all selected files moved.

An NFS service occasionally created a very large database file, and that file caused reboots to take a very long time. The file grew at a fast rate for NFS clients that mounted, unmounted, and remounted the NFS service at a high frequency. Now, the database file grows at a slower rate for constant NFS mount and unmount operations.

An NFS volume sometimes encountered an error, NSM_PRESTO_PKT_MUTEX_ERROR, when a file-history-archive rule took snapshots on back-end filers. This stopped all NFS access to the volume, and required a restart of its front-end NFS service(s).

The snapshot-create reports from a file-history-archive rule contained incorrect file-server information for the metadata share. The incorrect information was the filer name and NFS-export name.

A snapshot remove operation for a particular back-end share would always time out after 50 seconds. This was insufficient for some back-end servers. After your ARX gets the fix for this issue, F5 Support can set a higher timeout for snapshot-related commands if required for your site.

When a shadow-copy operation copied a file over 4 Gigabytes, it occasionally failed and produced a large core-memory file. This issue was related to issue 35679.

Version 5.0.5

Release 5.0.5 included the following fixes and enhancements:


Release 5.0.5 is functionally equivalent to Release 5.0.1.

ARX 5.0.5 is a maintenance update that provides support for new ARX4000 hardware; specifically a new control plane with new power supplies.

You can identify whether or not you have the new hardware by a physical examination. The original version of the ARX4000 used a control plane containing six 3 1/2 inch disk drives. (The serial numbers of these commodity servers start with BZDS.) The new ARX4000 uses a control plane that contains two 2 1/2 inch disk drives. (The serial numbers of the new chassis start with 0700.)

If your installation has upgraded existing ARX4000 systems instead of upgrading to the new platform, the ARX4000 documentation for 5.0.5 contains some information that does not apply to your model. For former versions of the ARX4000 chassis, consult:

  • Rev E of the ARX4000 Hardware Installation Guide
  • Rev C of the ARX4000 Installation Card

These are included in your 5.0.5 release; you can retrieve these earlier versions from the GUI or download them from the CLI.


There was a DNAS core and continuous reboots of cluster.

Release 5.0.5 added the following fixes to the ARX:

Snapshots fail with a managed volume with a share farm with two shares. Timeouts for the snapshots have been increased and this fixes the problem.

If you issue a Snapshot Remove command, then all of the contents of the virtual snapshot you are removing will be removed regardless of the current snapshot contents settings.

Spurious battery temperature values were being reported.

There was an error in CPU speed calculation logic. Now the CPU speed is correctly reported.

Previously, deleting a report would only unlink the report name from the file system. The disk space for the report file would only be freed when all references to that report were removed (unlinked). Other references to a report could include being opened for copying or collection, and so on.

Now, when a report is deleted, it is first truncated meaning that the report is terminated. There can be no remaining references to the report. After that, when the report file is removed, not only will its name be removed from the file system but its disk space will be freed immediately. Therefore, there can now be no discrepancy between the amount of disk space that is reported for /acopia/reports before and after the switch is reloaded.

The ARX Manager can take a null pointer exception while editing an Export due to Back button use. Do not use the Back button in releases prior to 5.0.5. You can use the back button in 5.0.5 and higher.

The no ip address command for the NTLM authentication server was not fully implemented. This operation is now allowed as long as the NTLM authentication server is not in use by a namespace.

Previously, the maximum snmp-server entry limit was being checked prior to adding and deleting an entry. If the maximum snmp-server entry limit had already been reached, the operation failed. The fix was to only check the limit when adding a new entry.

ARX4000+ Control plane power supply LEDs do not change to amber (or otherwise indicate failure).

It is difficult to detect a power supply fan failure on the new ARX4000 control plane. The control plane power supply LEDs do not change color or indicate failure in any way that you can detect visually. However, if you think a fan failure has occurred, you can inspect each power supply fan to determine if the fan is dead and to detect air movement (or the lack of air movement).

If you have access to the CLI, enter the show chassis chassinfo command which shows the status of all 4 power supplies. It is best not to rely on the LEDs because the LED states are different for each power supply manufacturer.

Prior to release 5.0.5 the ARX4000 power supply numbering was inconsistent between the data plane and control plane.

Prior to 5.0.5, when facing the back of the ARX4000, the control plane power supplies were designated 1/1 (top) and 1/2 (bottom). The data plane power supplies were designated left-to-right as 2/2 and 2/1, respectively.

Starting with 5.0.5, the ARX4000 includes a new control plane (with new power supplies) and a re-numbering of the data plane power supplies. When facing the back of the box, the control plane power supplies are designated left-to-right as 1/1 and 1/2, respectively. The data plane power supplies are designated left-to-right as 2/1 and 2/2, respectively.

When upgrading an existing ARX4000 to 5.0.5, take note of these changes. If you experience a data plane power supply failure and consult the output of the show chassis chassinfo, it reflects the new designations. For example, the following output indicates a failure of the left-hand data plane power supply.

bstnA# show chassis chassinfo 


Hostname UUID

------------------------------------ --------------------------------------

bstnA d9bdece8-9866-11d8-91e3-f48e42637d58


Chassis Type Model Number HW Ver. Serial

------------ ------------------------------------ ------- -------------

ARX-4000 SR2500ALLX-F5 0700000006

Chassis Environment:

Base MAC Address Power Fan(setting) Temperature

----------------- -------------- ------------- -------------

00:0a:49:17:78:00 Online Online Normal(<62>

Power Details:

Supply State

------ -----

1/1 Online

1/2 Online

2/1 Failed

2/2 Online

An ARX cored during the import of share, due to an uninitialized structure. Import now correctly initializes this structure and this problem has been fixed.

Version 5.0.1

Release 5.0.1 included the following fixes and enhancements, also included in this release.


Release 5.0.1 is functionally equivalent to Release 5.0.0.


Release 5.0.1 adds the following fixes to the ARX:

The CIFS security-id/name translation daemon was incorrectly handling cached information on untranslatable security-ids, causing assertion failures.

After an upgrade from 3.2.2 to 5.0.1 some MAC OSX users were not being able to login or they experienced degradation in network response.

Older snapshots were not being deleted by an ARX volume. Now older snapshots are being deleted correctly.

Mac users were getting significant performance hits through the ARX. This issue has now been fixed.

If a managed volume already imported a share from an NTFS qtree, it was unable to import another share from an NTFS qtree with the "ntfs_ignore_unix_security_ops" option. The new share stayed indefinitely in the "Pending Import" state. This only occurred if the first share was imported before an upgrade and the remaining shares were imported after an upgrade.

When CIFS clients unexpectedly cancelled their connections in the middle of a "find" operation (such as Transaction2FindFirst), NSM software allocated memory without freeing it. If this happened often enough, the ARX sent nsmResourceThreshold traps for the "cifsSidBitmap" resource. Eventually, some CIFS clients were unable to connect. The problem is resolved in this Release.

A client could send a non-Latin 1 character sequence file name to a Latin 1 namespace during an import. We now restrict and deny non-Latin 1 sequence files during an import to a Latin 1 namespace.

A direct (or presentation) volume could not attach to an NFSv3/UDP export unless the export also supported NFSv2. Direct volumes can now attach to NFSv3/UDP exports whether or not the exports also support NFSv2.

An integer overflow prevented the shadow volume copy from copying files over 4G. In addition, there was the large memory consumption by shadow receiver. A fix was put in place to prevent integer overflow when the file size is over 4G. A throttle was implemented to prevent the potential large memory consumption by the shadow receiver.

The NSM was generating a core when the NSM failed to handle an error reply from a file server for a transaction of snapshot. The issue occurred when multiple transactions were done at the same time while the ARX was waiting for response from the file server, the ARX deleted the cache information incorrectly, then caused an NSM core.

Mac OS X clients using SMB file sharing components that are part of the OS were unable to mount shares hosted on the ARX. This was caused by a crash of the NetAuthAgent component on Mac OS X. ARX software in this release works around this problem.

Administrators were unable to change the quorum disk location when the quorum disk was offline. Administrators now can change the location of the quorum disk when it is offline.

Previously, shadow volumes encountered sharing violations in .acopia_shadow and then cored. This has been fixed.

The ARX erroneously allowed you to assign the same secondary-IP address to multiple external-filer configurations. Now the CLI and GUI prevent this mis-configuration.

Version 5.0.0

Release 5.0.0 included the following fixes and enhancements, also included in this release.


Release 5.0.0 adds the following features to the ARX:

File Tracking
An ARX managed volume moves files through tiers of back-end storage as time passes. Some installations use data-protection systems that perform backups and restores directly on their back-end filers. If a backup occurs on Filer A before an ARX volume migrates some files to Filer B, it is unclear which files should be restored to which filer. The new file tracking application resolves this issue.

You can configure an external file server as a file-history archive and configure a volume's snapshot rules so that they regularly store their file locations in that archive. Later, you can make queries about current file locations as well as their locations as they moved from tier to tier in the past. From the GUI, access the File History Query option from the navigation pane. From the CLI, use the commands described in the chapter, Tracking Files on your Back-End Storage in the CLI Maintenance Guide.

Seamless Managed-Volume Import
Previous ARX-software Releases blocked certain client operations, such as renaming directories, while a managed volume imported storage from its file servers. Release 5.000.000 lifts all client restrictions during a managed-volume import, so that clients can access the managed volume's storage as soon as it is enabled.

Kerberos Authentication for the ARX Proxy User
An ARX proxy user is a set of Windows credentials (a username, Windows domain, and password) that a managed volume can use as its identity for autonomous operations. A proxy user in previous releases always authenticated with back-end file servers using NTLM; as of Release 5.0.0, it can use Kerberos as well.

Copying Files Between ARX Maintenance Directories and ARX Volumes
Release 5.0.0 offers a new option for transporting maintenance files: you can transfer them to and from ARX volumes. This is designed for sites that do not permit FTP access (or other Internet access) to their data centers. You can use the copy {nfs | cifs} CLI command, or its GUI equivalent, to copy software-release files, diagnostic files, logs, or other maintenance-related files. Refer to the CLI Reference for detailed instructions on using the CLI command.

New Online Help in the GUI
The 5.0.0 GUI now offers extensive online help, with indexing, book marking, and a search interface. These new navigation tools give administrators the opportunity to pursue any given topic and learn more as needed.

Minor CLI Change for Shadow-Copy Rules
The allow-shared-access CLI command (and its GUI equivalent) is now hard-coded for all shadow-copy rules. The command no longer appears in the CLI, and the equivalent option no longer appears on the GUI. Contact Customer Support if you wish to disable this feature.


Release 5.0.0 fixes the following software issues:

When clients repeatedly performed a metadata modifying operation (create, delete, or rename) on the same file or a permission/attribute modification on the same directory during import, the import software unnecessarily rescanned the modified object's directory. The import software no longer performs these redundant scans.

Snapshot rule spuriously reported that it failed when it experienced a minor communication error. The failure appeared in the snapshot report, along with the following message at the bottom of the report:

Unable to notify policy engine to resume any active migrations.

The ARX CLI failed if you entered multi-byte characters (such as Japanese characters) through a terminal emulator that did not support UTF-8.

The output from collect was inaccessible unless you explicitly specified a .tgz extension. The CLI and GUI formerly accepted this directive without the proper extension; the current release prompts for the .tgz extension if it is missing.

The management address for an external filer, set with the ip address a.b.c.d management CLI command, could not be on the out-of-band (OOB) management subnet for the ARX. That restriction is now lifted.

The show ntlm-auth-server status CLI command got an OPEN_SSL_ERROR string if the NTLM-server password was longer than 22 characters. It now allows up to 64 characters, as indicated by the documentation and online help.

If you incorporated a non-existent filer snapshot into an ARX-snapshot rule (with the snapshot manage CLI command), the ARX erroneously created an empty ARX snapshot.

Under rare circumstances, an nsck ... rebuild on a shadow volume made the volume stall in "importing" state.

The ntp server command allowed v1 and v2 of the NTP protocol, two versions that were not supported. The command no longer offers those options.

An ill-timed filer error sometimes resulted in a spurious "Completed" state for a file-placement rule. In the current release, all reports correctly show a failed migration whenever a filer issue causes a failure.

The report for a failed file-placement rule may terminate with the RULE_INTERRUPTED error. This error is designed for rules that were interrupted by configuration changes and reboots. In former releases, it was also inappropriately used for filer errors and connection issues.

The 'Files in Fileset' counter was incorrect in a File-Placement report and the 'show policy' (detailed) output. The counter for 'Files in Fileset' was higher than the actual number of files when it was incorrect. The counter is accurate in the current release.

Incorrect "Snapshot State" appeared in snapshot reports and the output of the "show snapshot" CLI command. The "Snapshot State" of a sparse snapshot should appear as "Sparse" if any of the volume's shares are excluded for any reason. The snapshot state appeared as "Complete" when shares are excluded because of filer configuration. In this release, the snapshot state correctly appears as "Sparse."

Shadow Volume sync performance for ARX4000 was poor compared to that of the ARX6000. Sync performance in the current Release is equivalent between the two hardware platforms.

The output of the show global-config command displayed reserve file settings for direct volumes.

Could not attach directory to . for a Windows file server.

Conflicting place rules caused a deadlock when simultaneously migrating files between two separate share-farms. Each rule was asking the other rule for a particular share's index while holding a lock preventing simultaneous access.

Dual switch reboot fixed by ignoring a latent disk heartbeat, which caused the junior switch to reboot.

Too many alerts sent due to a transaction leak.

Users could not log on due to authentication errors which were fixed with health check and load balancing improvements.

A standard NFS error resulted in extra "DFM_FILE_ASSERT" messages in the syslog. The ARX no longer logs these unnecessary messages.

When the dncd tried to send message with too many entries it cored. The NSM can only support up to 64K attach points. When processing a directory with a large number of sub directories, break up the request into multiple messages, which will keep dncd from coring.

Previously, there was a problem display the Japanese character set in a share using a MAC 10.4 GUI on an ARX. This issues is resolved now in the handling of the RPC.

Previously, the LED link light did not come on for 100Mbps setting for the 500+. This issue has been resolved.

Removing an empty direct/presentation volume will cause disruption to all clients that are attached to that volume. A message now warns the user when the volume is still in use by an active global service (Virtual Service in ARX Manager) and asks if they want to destage anyway.

Previously, log messages contained the use of forward and back slashes for path names. They used to use forward slashes in some cases and now they are consistent.

Previously, If a file server was very busy, it was slow to respond to CIFS file close messages. Some clients would resend the close if they don't receive a response after some period of time. Multiple closes on the same file identifier would cause the internal state in the ARX to become corrupted resulting in a failure in an NSM processor. This is now resolved.

A shadow-copy rule produced ambiguous errors when its target volume had no more file credits. The errors appeared in the shadow-copy report in the Target Information section, similar to this error:

% ERROR: (38): 

Read source file attribute data failed; Unable to read file attributes;



File: partial-file-path

Now the report includes a clearer message:

Shadow volume target has no free files

The copy ... ftp CLI command (and its GUI equivalent) occasionally failed with the following error:

FTP Put error: 'remote file appears to be the same as the local file, upload is not 


This rare failure no longer occurs.

The redundancy software did not send an SNMP trap when the heartbeat directory was restricted to read-only access. The heartbeat directory is on the external filer used as a quorum-disk. Now the redundancy software raises the haPairQDiskOffline trap whenever this write failure occurs.

The ARX had insufficient algorithms for checking the health of its remote Domain Controllers (DCs) and for quickly switching to a healthy redundant DC. As of Release 5.0.0, the ARX began using an LDAP query for its health checks, and offers an option to declare a set of "preferred" DCs in a given Windows Domain. The CLI Storage Guide contains instructions for setting DC preferences and changing the timeout for DC health-check queries.

The ARX kept two copies of each core-memory file. Core files contain important diagnostic information for processes that failed; they typically consume large amounts of space on the internal disks. The ARX now keeps only a single copy of each core file.

User access issues resolved by adding a separate auth queue to vcifs. This is used for incoming NEGOTIATE and SESSION SETUP requests.

The Mibs.tgz file, available in the "software" directory, contained the Secure Agent code as well as the MIBs. The Secure Agent packages have been removed from the Mibs.tgz file. They are still available on the ARX, in the "software" directory alongside the Mibs.tgz file.

A file-placement rule kept trying and failing to migrate files after its target share ran out of space.

A syslog message from the policy engine, RULE_UPDATE_INLINE_FAILED, contained cryptic references to internal processes.

If a file server behind an ARX volume ran out of space, directory renames locked out all other client access for 10 to 15 seconds. The directory renames now fail immediately, without locking out clients.

Workaround: Disable the rule that is scanning.

The clear statistics cifs-auth CLI command did not clear all of the CIFS-authentication statistics. The Failure Reason Table at the end of the show statistics cifs-auth output retained its error strings. Now the clear command clears the full contents of the corresponding show command.

The cancel import CLI command (or its GUI equivalent) failed for a share that had not yet started its import scan. This failure made it impossible to cancel the share import. It also prevented future import cancellations and volume controls in the share's volume.

The POLICY_PEP logging component wrote misleading messages to the syslog during normal tiering operation:


- no target specified.

These messages appeared when the POLICY_PEP component was at a logging level of "debug." They were not errors. We have rewritten these log messages to be less confusing in the current release.

This redundancy configuration caused a dual reboot:

  • The quorum disk and a managed volume's metadata share are on the same back-end file server,
  • the metadata share is configured as a "critical resource" on the ARX, and
  • file server goes offline.

In the current release, no reboot or failover occurs.

Share discovery used to not preserve back-end share descriptions. When creating ARX exports by scanning back-end storage, the ARX now initializes the ARX export description from the back end. ** Subsequent changes to the ARX export description will NOT be propagated to existing back-end shares or subshares.** .

If a multi-protocol volume had a non-latin1 character (such as a Japanese character) in its name, the volume software sometimes failed and produced a core file. The failure only occurred if the namespace's NFS-side character encoding was set to "iso-8859-1;" from the CLI, you can set this with the character-encoding command.

A reboot issue had no immediately client-visible effects, but had the potential to take services offline at a later time. An NSCK destage of one of the affected volumes could trigger the service loss. (From the CLI, you use the nsck ... destage command to destage a volume.) At the time of the destage, all of the volume's front-end services went offline. The root cause of this outage has been corrected.

The show namespace CLI command and the GUI's Managed Volume Details screen both display the number of files used and files available on a volume's shares. The number in the CLI output was different from that of the GUI; one was rounded and the other was exact. In the current release, the numbers match in both interfaces.

The option to ignore a back-end file/directory name was applied to directories during import, and it was applied to both files and directories after import. The CLI command was named ignore-directory, and its GUI equivalent had a similar name. As a result of this inconsistent treatment of ignored names, a file could successfully import into a managed volume and then be ignored by volume software, making it inaccessible to clients. The CLI command (and function) has been renamed to ignore-name: this command and its GUI equivalent now ignores all directory and file names that it matches.

Version 4.1.3

Release 4.1.3 was a maintenance release that fixed the following software issues:

37329, 37521
A file-placement rule sometimes stopped migrating with 199 files in a "pending migration" state. This was due to an internal resource-contention issue that is resolved in this release.

37815, 37939
A shadow-copy rule frequently stopped without finishing. This issue occurred when a client renamed a directory in the source volume. This was due to an internal issue that is now resolved.

Version 4.1.1

Release 4.1.1 was a maintenance release that fixed the following software issues:

35416, 35648
A failed CIFS directory rename to the volume root of a multi-protocol namespace used to result in the retry operation failing. The solution was to specify a NFS protocol when updating the parents filehandles.

Policy migrations were failing due to a rare internal failure. The internal failure has been corrected.

If ARX-4000 internal temperature exceeds 45 degrees C, box did not reload properly unless fully power cycled.

If a back-end server stopped responding to an open CIFS session, and the NSM processor with the CIFS session had an increasing number of client queries for the server, the NSM processor sometimes failed.

If you enabled a managed volume on an ARX500, failed over to its redundant peer, and then enabled the volume's CIFS service on the peer, the CIFS service sometimes got stuck in the 'starting' state.

Mac OS X 10.4 & 10.5 "DAVE" CIFS clients were losing sight of files and/or folders exported from an ARX service.

The internal hard drives supplied to F5 Networks, Inc. for some ARX-500s and ARX-1000s had a firmware issue. The issue sometimes caused the drives to be remounted as read-only, thereby taking the chassis offline. F5 issued letters to all customers known to have this issue, and replaced the faulty drives.

Previously, when a user is tried to find a previous version of a file or directory using the Previous Versions tab in the Properties dialog box from Windows Explorer, previous versions of the file or directory that were part of at least one snapshot of the managed volume did not appear in the list of previous versions. In this case, the snapshots were available by browsing the available snapshots in the snapshot directory (whose name is configurable, but is "~snapshot" by default) on the managed volume. This has been fixed.

After the maximum amount of NTP servers were configured, someone attempted to move one and it failed. This command now works as expected, and moving an NTP server is successful.

Previously, a forced storage remove left old replica filehandles around with storage IDs that no longer existed in the volume. This problem has been fixed and old replica filehandles are no longer left behind.

After the maximum amount of NTP servers were configured, someone attempted to move one and it failed. The command now works as expected.

Two administrative operations often resulted in omTransactionsRaise traps from the ARX: those invoked by the collect and remove-share ... migrate CLI commands, or their GUI equivalents.

If a managed volume with browsing enabled was importing when a process requested the volume's free space, the import slowed noticeably.

UPN support. Added UPN support for NTLM.

The cancel sync files CLI command had an issue with command completion. The syntax below showed all volumes on the ARX instead of the set of volumes in namespace:

cancel sync files namespace volume ?

Now the command shows only the list of volumes from the specified namespace.

An ARX-snapshot removal is designed to remove each component snapshot from the ARX volume's file servers. If any file server failed to delete its snapshot, the ARX noted the failure and then removed all records of the ARX snapshot from its database. This made it impossible to delete the file-server snapshot from the ARX. Now the delete-snapshot operation keeps the ARX snapshot as a "sparse" snapshot; the sparse snapshot only includes the file-server snapshot(s) where the delete failed.

EMC Checkpoints fail with error "Unable to find file system ID ." It is possible that the query can fail to find the file system ID. The usual cause of this problem is that the management IP address set for the external-filer object does not identify the correct EMC Control Station for the file system. To view a list of file system IDs and names, run the command 'nas_fs -list' on the EMC Control Station's management console. If the file system ID reported in the error message is not in the list, then it is likely that the wrong Control Station IP address is configured for the external-filer.

33126, 33676
Previously, the LED link light did not come on for 100Mbps setting. This issue has been resolved.

In a particular VPU configuration, a share-removal operation could cause volume software to restart and produce a core file. The restart occurred for a volume that shared its VPU domain with 63 other volumes. (You can remove a share with the remove-share CLI command or its GUI equivalent.)

A shadow volume sometimes failed if it was backed by an NTFS qtree. The problem was that the shadow-copy rule was using NFS to write its database to the qtree. This release uses CIFS to write the shadow-copy database to an NTFS qtree.

The policy engine failed to detect a rare metadata failure that made it impossible to operate successfully. File-placement rules continued to take CPU cycles without successfully migrating any files. The place rules added many messages to the syslog with this statement: "(No policy queue exists for this volume.)." In the current release, all rule processing stops for a managed volume with this failure.

The snapshot manage CLI command had an unclear error message. The error message is clearer in this release.

An NSM-core processor could fail with a rare combination of NLM transactions (from NFS clients) and file-server outages. These combinations no longer cause an NSM failure.

The snapshot manage CLI command (or its GUI equivalent) failed unless it was preceded by a snapshot create operation in the same managed volume.

When a CIFS-only volume on the ARX attempted to import a CIFS share from a NetApp filer, the import could fail due to an NFS security setting on the filer. The failure occurred only for an ARX volume configured for CIFS subshares, and for a NetApp share backed by a Unix qtree. The NetApp's Unix-security setting is now properly ignored by the CIFS-import process.

In previous releases, no output appeared for the show statistics namespace fastpath CLI command.

Version 4.1.0

Release 4.1.0 included the following fixes and enhancements, also included in this release.


Release 4.1.0 added the following features to the ARX:

CIFS Access-Based Enumeration (ABE) Support
Release 4.1.0 adds CIFS support for Access-Based Enumeration (ABE). If an ARX volume has ABE enabled, its CIFS clients can only see the files that they have permission to read. That is, inaccessible files and directories do not appear in directory listings. This feature is designed to eliminate client curiosity about files and directories that they do not have permission to view.

The following ABE-supporting filers have been qualified for use behind ABE-supporting volumes:

  • EMC Celerra, software version 5.5.
  • NetApp, software versions 7.2.3 and 7.2.5.
  • Windows 2003 R2 SP2.
  • Windows 2003 SP1.

NOTE: For any ABE-supporting volume backed with NetApp filers, the volume's namespace requires a proxy-user with new access privileges. The proxy-user account must belong to the "Administrators" group on each ABE-supporting NetApp share. This is a higher level of access than the "Backup Operator" privileges required for file migrations.

Support for Maximum Age for Kerberos-Machine-Account Passwords
Some Domain Controllers (DCs) support a "Maximum Age" option that you can set for Machine-Account passwords. This is a secret password exchanged between a machine account (such as an ARX-CIFS service) and the DC when the machine/service first joins the Active-Directory domain. By default, the password lasts indefinitely. Administrators have an option on some DCs to set an expiration period, called a "maximum age." If the machine-account password expires for an ARX-CIFS service, the service can no longer use Kerberos to authenticate its CIFS clients.

Release 4.1.0 adds an operation to resolve this issue. For a site where the maximum age is set and about to expire, you can use the cifs rekey CLI command (or its GUI equivalent) to regenerate the key(s) for your ARX-CIFS service(s).


Release 4.1.0 fixed the following software issues, also fixed in this release:

On an ARX6000 system, certain types of network control packets could exhaust all internal memory associated with the networking hardware in the system. No further network communication can occur on this port until an ARX failover is performed. This problem is fixed with this release.

The FILER_CREATE_FILE_FAILED message caused an NSM core. We fixed memory corruption occurring in the NSM logging subsystem when formatting a log message longer than 130 bytes.

A reboot failed to recover an ARX4000 in SSB-degraded mode. SSB-degraded mode means that the PCI connection has failed between the DP and the CP. In this release, the connection recovers after a CLI reload or its GUI equivalent.

The snapshot timeout client-tolerance command is unsupportable in some file-server topologies. The solution to this issue is to automatically generate a suitable timeout value for ARX snapshots, and to remove the command.

When an NSM fails in an ARX6000, certain CLI commands and GUI operations hang without ever completing.

When removing a back-end share from a managed volume, a transient connectivity problem with the share's filer can stop the share-removal operation. The share-removal operation now retries for a longer period of time before canceling. (You can invoke a share-removal operation with the no share, no filer, or remove-share CLI commands, or their GUI equivalents.)

Share-removal reports may contain spurious FF ("Found File") entries.

The solution to this problem is to issue a new CLI command, expect change-mfg-date.scr serial-number, where the serial-number is the one on the chassis label. This changes the output of show chassis chassinfo.

Some processes on the SCM or ACM use progressively-more memory, causing the ARX to eventually refuse administrative logins and offer progressively-slower service to its clients.

The ARX supports a single default route; this may be a problem in a multi-VLAN network with a certain firewall configuration.
The new ip route ... per-vlan CLI command allows an administrator to work around this issue. Refer to the CLI Reference for details on this command.

An alarming syslog message, "xsdd_aipc_task: IPC service error 3...," may appear repeatedly on an ARX, often when the ARX is processing a large number of SID translations. This message does not typically indicate a service-affecting problem, so its severity has been downgraded.

The CLI online help does not line up its options with the correct descriptions. For example, the description below should line up with the generic "Text" option instead of the specific "" choice:

my-arx(gbl)# cifs ? - Specify the global server hosting this CIFS service. -

nfs1.test.lab -

Text<1-128> -


If an ARX with two internal disks (an ARX1000, ARX2000, ARX4000, or ARX6000) loses both of them, it fails to reboot so that its redundant peer can take over its storage services. The resolution to this issue is a proper reboot and a faster failover.

An NSM processor fails and produces a core-memory file if it receives a particular error from a back-end-CIFS filer. This only occurs in a presentation (or "direct") volume.

The following circumstances lead to progressively-more memory consumption on the SCM or ACM processor, 1.1:

  • a presentation (or "direct") volume uses a managed volume as one of its "filers", and
  • that managed volume is deleted.

The bespd daemon uses up progressively-more memory until it fails and restarts. This daemon's memory consumption is visible in the output of the show system task CLI command.

If an ARX4000 NSM experiences certain driver issues, the driver writes an excessive number of repetitive log messages to the serial Console. This slows the performance of the network drivers, and masks useful driver logs.

A DAVE 7.x client application can create an issue when opening directories in an ARX volume: if the ARX has a particular failure while opening the directory, the directory remains open after the DAVE client has left it. A directory in this state cannot be deleted or renamed by other clients.

A pair of NSM processors can unexpectedly fail, causing a failover in a redundant pair of ARXes. This is due to the NSM software's incorrect assertion that an internal-memory buffer (for log messages) has overflowed.

The ARX4000 does not reliably process jumbo frames. (You can enable or disable jumbo frames with the [no] jumbo mtu CLI command.)

Version 4.0.1

Release 4.0.1 included the following fixes and enhancements, also included in this release.


Release 4.0.1 is functionally equivalent to Release 4.0.0. Unlike Release 4.0.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 fixed the following software issues. These fixes are also included in the current release:

The ARX does not re-create its error.log or fastpath files if an administrator deletes one of them. (You can delete these files with the delete logs error.log or delete logs fastpath CLI commands, or their GUI equivalents.)

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 repetitively 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.

Version 4.0.0

This section describes the features and fixes from Release 4.0.0. Sites that upgrade from Release 3.2.3 get the benefit of all the features and fixes described here, in addition to the features and fixes described above.


Release 4.0.0 adds the following features:

Release 4.0.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 an ARX®6000 with 2 ASMs and 2 NSMs. This platform supports a total of 10Gbps throughput.

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.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.0 fixes the following software issues:

The no monitor module CLI command did not completely disengage its network ports from their port-mirroring roles.

The policy status showed scan complete/migration complete but the metadata report showed files left on source share.

Deploying switches via template didn't 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 caused the junior switch to fail. Since the senior is already rebooting due to the l2 failure, this caused 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 correctly, yet when a place rule 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.

[ Top ]

Required Configuration Changes

There are no required configuration changes that pertain specifically to the 5.2.2 release. If you upgrade from release 5.2.0, there are no configuration issues to consider.

For Upgrades from Older Releases

If you are upgrading from an early release, you may require additional configuration changes based on the features you use. The subsections below explain the configuration changes required for various upgrade paths.

For Upgrades from Before 5.2.0

Release 5.2.0 introduced constrained delegation for its CIFS services, and we strongly recommend implementing it for your existing CIFS services. A member of the "Domain Admins" group can implement this at a domain controller (DC). Constrained delegation is a more secure method for running your CIFS services than the unconstrained delegation that was available before 5.2.0. Additionally, clients can use NTLM or NTLMv2 to authenticate to a CIFS service without the aid of an ARX Secure Agent. This is not a required change, but it is strongly recommended.

Rejoining a CIFS Service to its Domain

A CIFS service with a long name may need to rejoin its domain after the change to constrained delegation. If the CIFS service has a name longer than 15 bytes, DCs will reject NTLM or NTLMv2 authentications from the service's clients. (The service name is the first part of the service's FQDN; for example, "myco" would be the name of the service at "") The CIFS-service software raises an SNMP trap if it detects this condition. See the SNMP Reference for details on SNMP traps.

To correct this condition, use the domain-join CLI command or its GUI equivalent. This operation truncates the CIFS-service name and creates a new machine account at the DCs with the shorter name. The CLI or GUI displays the shorter name after you invoke the domain-join operation.

Verify that All Proxy Users Use an FQDN Domain

Any namespace that supports CIFS access has a proxy user that it uses as its identity. The proxy-user configuration is a username, password, and Windows domain that is valid in your Windows network. The proxy user's Domain should always be an FQDN (such as "") instead of a short name (such as "mysrvr"). This ensures that the ARX can authenticate with Kerberos, which can be vitally important in some situations. This is required to support Constrained Delegation.

  1. Use show namespace namespace-name to find the name of the "proxy-user" for a given namespace.
  2. Use show proxy-user proxy-user-name to see the configured Windows Domain for the proxy user.
  3. If the Windows Domain is a short name, you can use the windows-domain command in gbl-proxy-user mode to change it to an FQDN. (Use the pre-win2k-name argument if you need to specify both the FQDN and a short name that is completely different from the FQDN.)
Rediscovering the AD Forest

The ARX database now keeps the pre-Windows-2000 names for every domain in its active-directory (AD) forest. If your AD forest has a domain with a pre-Windows-2000 name that is not the first component of the full domain name, you must re-discover the AD forest. For example, if a domain in the forest is named "" but its pre-Windows-2000 name is "COMPANY" instead of "myco," the ARX software needs to know that some CIFS clients may use "COMPANY" as their domain name. Otherwise, those clients cannot authenticate. You can use the active-directory update CLI command or its GUI equivalent to re-discover the AD forest, including all pre-Windows-2000 domain names.

For Upgrades from Before 5.1.0

This section only applies to installations that upgrade from a Release than 5.1.0. After the upgrade beyond Release 5.1.0, you require the following configuration changes to support all of the release's new features.

Upgrading the Secure Agent for NTLMv2 Support

The ARX cannot support NTLMv2 until all of its ARX Secure Agents (ASAs) are upgraded beyond 5.1.0, too. After you upgrade the ARX to this release, you must also upgrade at least one ASA. We recommend upgrading all of them. There are two versions of the ASA kit: a 32-bit version and a 64-bit version. Refer to the ARX Secure Agent Installation Guide for detailed ASA-download and upgrade instructions.

NOTE: The ASA formerly used pwdump to access a database on the DC; the 5.1.0 release of the ASA software uses other means instead. Please update any anti-virus (AV) application running on your DCs before you use the new ASA version. Refer to Solution Note 10026 for detailed instructions.

CIFS Symlinks: New Scan for Existing Volumes

If your system contained any multi-protocol (CIFS and NFS) volumes before the upgrade to this release, the volumes require a configuration change to take advantage of a software feature. The feature is symlink support for CIFS clients, described above. To activate CIFS symlinks for a multi-protocol volume, use the no cifs deny-symlinks CLI command. You can run this command from gbl-ns-vol mode for the multi-protocol volume. Once you allow CIFS symlinks, the volume must scan its back-end servers for NFS symlinks and record them in its metadata. A CLI prompt allows you to run the scan as a background process; enter yes to proceed with the scan.

For example, this command sequence adds CIFS symlinks support to the "insur~/claims" volume. The prompt indicates that a back-end scan is required, and offers the opportunity to run it in the background:

bstnA(gbl)# namespace insur volume /claims 

bstnA(gbl-ns-vol[insur~/claims])# no cifs deny-symlinks

This volume's configuration has been upgraded from a prior software release.

If symlinks exist in the volume, the volume's metadata must be synchronized

before CIFS clients can take advantage of this feature. You can synchronize

the metadata at any time. User access is not affected by this process but it

may run for hours or days if the volume contains hundreds of millions of files.

Synchronize the metadata for the '/claims' volume now? [yes/no] yes

bstnA(gbl-ns-vol[insur~/claims])# ...

To perform the scan (and fully-activate CIFS symlinks) later, you can run the sync files namespace-name volume vol-name command on the volume's namespace. You can run this at any time.

The ARX Manager UI also provides an interface for running the no cifs deny-symlinks and/or the sync files operations.

This operation is not necessary for any multi-protocol volume created after the upgrade to 5.1.0. By default, new volumes allow CIFS clients to use symlinks, and the symlink scan is performed during the initial import of the volume's back-end shares.

Windows 2003 Clusters

If you previously used a Windows 2003 cluster behind a managed volume, you require one of two configurations to continue using the cluster. The first is recommended as a best practice, and the second is for sites where the cluster does not have a shared Service-Principal Name (SPN):

  1. Add the cluster's shared SPN to its configuration on the ARX. From the CLI, you can use the gbl-ext-filer spn command to set this. For example, spn This must be a virtual SPN, one that persists after a cluster failover.
    This implies that the cluster's virtual-CIFS service must join the local AD domain. For sites where this is not possible, use the option below.
  2. Do not configure any SPN for the Windows 2003 cluster. This is contrary to the user documentation, which states that an SPN is recommended for any Windows cluster or Kerberos-supporting server.
    From the CLI, you can use the gbl-ext-filer no spn command to remove the SPN configuration.

In either case, you can use the show external-filer command to map the Windows 2003 cluster's VIP to an "external filer" name on the ARX. Then use external-filer filer-name to enter the CLI mode for that filer, and then the spn or no spn command as needed.

For example, the following command sequence finds the external-filer name for a Windows 2003 cluster and sets its SPN:

gffstnA# show external-filer 

Name IP Address Description

------------------------ ------------- ----------------------------

ch-wd-win1 Windows Server 1, back room

ch-wd-win2 Windows Server 2, cluster next to Win1

ch-wd-nas NAS filer in computer lab

gffstnA# global

gffstnA(gbl)# external-filer ch-wd-win2

gffstnA(gbl-filer[ch-wd-win2])# spn fs2k8c95@GGH.MEDARCH.ORG

gffstnA(gbl-filer[ch-wd-win2])# ...


For Upgrades from Before 5.0.1

This section only applies to installations that upgrade from Release 5.0.0 or earlier.

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

Unicode Upgrade

This section is for administrators who need to upgrade from releases prior to 5.0.0. The 5.0.0 Release includes a new Unicode library that may have an effect on client files and/or directories. The new version of Unicode adds 168 lower-case versions of characters that were uppercase-only in the previous version. The characters derive from the following languages:

  • Native-American languages from modern-day Canada, including SEN¦EN.
  • Greek symbols for editorial markings.
  • Cyrillic letters that may not be current.
  • Georgian letters from an ancient ecclesiastical alphabet.
  • Glagolitic letters; Glagolitic is a historical Slavic alphabet.
  • Coptic letters, used by the original Christians in Egypt.

After the upgrade to Release 5.0.0, clients cannot open any files or directories with any of these rare characters in their names. This problem should be very rare. The symptoms are different for files than they are for directories, as explained below. If you see these symptoms on any of your files or directories, escalate the problem to F5 Support.


If a Windows client attempts to open a file with one of these characters in its name, an error similar to this appears in Windows Explorer:

Cannot find the \\VIP\unicode/dir1/file%c8%ba.txt



Windows Explorer returns the following error if it attempts to open a directory with one of these characters in its name:

Refers to location that is unavailable


For Upgrades from Before 5.0.0

This section only applies to installations that upgrade from Release 4.1.1 or earlier.

Release 5.0.0 introduced two new maintenance features for shadow-copy rules. If your site uses shadow-copy rules, F5 recommends that you use these features after the upgrade to 5.0.0.

  • Moving the Shadow-Copy Database to the Metadata Share
    You can now place a rule's shadow-copy database on the target volume's metadata share. In previous releases, the shadow-copy database resided on the same back-end filers that held the target volume's copied files. As the set of copied files expanded, it became possible to run out of space on the target filer(s), thereby possibly corrupting the database. The shadow volume's metadata does not grow as fast as its user data, and there are SNMP traps to alert you of free-space issues on that share, so the metadata share is typically a better candidate for this database. From the CLI, you can go to gbl-ns-vol-shdwcp mode and use the database-location metadata-share command to move the shadow-volume database the next time the rule runs.
    This is only necessary for a shadow-copy rule from before the 5.0.0 upgrade. The next time the rule runs, it migrates the database to the metadata share.
  • Shadow Copying Names that Match the CIFS "8.3" Pattern
    This option only applies to an ARX volume that supports CIFS. CIFS-supporting filers typically create an alternate name for any file or directory whose name is longer than eight characters, or whose extension is longer than three characters. The alternate name matches the old-style "8.3" pattern, with up to eight characters that are optionally followed by a "." and up to three more characters. Typically, filers include a tilde (~) in this alternate name. If a real name on the source volume matches one of these alternate names in the shadow volume, the shadow-copy rule refuses to copy the file by default. This is a rare circumstance, but it is possible in any CIFS volume.
    You can change this with a new feature in 5.0.0. From the CLI, you can go to gbl-ns-vol-shdwcp mode and use the cifs-8dot3-resolution command to make the copy possible without overwriting the file with the alternate name.

Refer to the CLI Reference Guide for details on both of these commands.

NOTE: These are not strictly-required configuration changes, but F5 strongly recommends them for customers that use shadow-copy rules on the ARX.

[ Top ]

Known Issues

The following items are known issues in the current release.


Getting rampart errors in api_error.log. (339710)
A large number of API calls in a short period of time may cause rampart errors to be written to the log.

This issue was identified during pre-release stress testing.

The ARX API does not accept digest authentication in its SOAP requests. (340615)
The ARX API only accepts basic authentication in its SOAP requests.

Workaround: To ensure that passwords are sent in encrypted form, use HTTPS (instead of HTTP) to connect to the ARX API.

Authentication statistics are not updated when the API caller is authenticated by Active Directory. (341266)

Authentication and Security

The uninstall of the ARX Secure Agent may fail to reboot the DC. (35754)
The uninstall of the Secure Agent must reboot the host machine (typically a DC) to finish. The uninstall process has failed to reboot the host DC on some occasions, but the failure is rare.

Recovery: Manually reboot the DC if the uninstall process fails to reboot it automatically.

Lower the requirement for mgmt of AD. (36177)
The use of "active directory" CLI commands requires crypto-officer privilege in the current release, rather than "storage-engineer" privilege.

No errors when clients try to access a CIFS service by an unknown name (352673)
When clients access an ARX global server by its DNS-based name, where the DNS-based name is different from its FQDN, they cannot authenticate. There are no ARX error messages to indicate that the DNS-based name is unknown to the ARX.

Workaround: Use the active-directory alias CLI command (or its GUI equivalent) to create an alias for the global server. The alias should match the DNS-based name that CIFS clients are using to connect to the server.

As an alternative, you can use the Windows setspn utility to create two SPNs for the CIFS service's machine account. If the CIFS-service FQDN is "" and the DNS domain is dns-domain, you require the following two SPNs:

  1. HOST/hostname.dns-domain
  2. CIFS/hostname.dns-domain

system hang after reboot. (354670)
After Issue 354164 caused a reboot, the ARX never fully booted until it was manually power cycled. Issue 354164 is resolved, but the failure to boot is still under investigation.

Boot Software

ARX-4000 NSMs failing after firmware upgrade. (351863)
NSM processors on the ARX-4000 may fail to boot after an upgrade to 5.2.0 (or later) firmware. This is only an issue on an ARX-4000 in a redundant pair.

CIFS Proxy/Virtualization

Virtual service stuck in "Starting". (342499)
Virtual services may get stuck at "Starting" at the time that they are created.

Cryptic error when creating EFS encrypted file. (343027)
An ARX-CIFS service issues a STATUS_INVALID_PARAMETER response whenever a client tries to copy an EFS encrypted file to the service. This results in an unclear error at the Windows client application.

Control Plane multiplexing controls. (343244)
The ARX does not have a mechanism to limit the number of CIFS tree connections within its file-server-TCP connections. Some file servers cannot tolerate more than 2,048 simultaneous tree connections in a single TCP connection.

Active Directory accounts can not be added when changing folder or file level security permissions through the ARX VIP. (338795)


CLI failed with a core-memory file when issuing "ssh-host-key rsa encrypted-host ?". (352127)
A problem causes the CLI to generate a core file when an administrator invokes ssh-host-key rsa encrypted-hostkey ?.

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.

Config replay fails due to DB schema changes. (27866)
Some upgrades result in database-schema changes. If this upgrade includes a database change, do not use previously-saved configuration scripts because these scripts will not implement the changes properly. Use the 'copy global-config' command to copy (and save) the switch's new global configuration.

See the section, Installing the Software, to determine whether or not this release contains a database change.

Workaround: After upgrading to the new release, use the 'copy global- config' command to copy (and save) the switch's global configuration to a local file, a remote server, or an E-mail recipient.

The CLI displays unintended errors if you interrupt the copy CLI command (with ) during the file transfer. (32531)
The CLI copy command prints the following messages while it transfers a large file to or from the ARX:

% INFO: Transferred nnn of total megabytes; still copying . . .

If you press while the CLI is printing these messages, some internal processes continue after the overall copy process halts. After 20-30 seconds, the CLI displays the following errors from those sub-processes:

gunzip: stdin: unexpected end of file acrypt: Error, uncompress failed(256).

Disaster Recovery

Load Cfg - conflict resolution doesn't allow remote cluster specific entries. (340060)
Once a configuration is up and running on a switch, loading a config file that has cluster-specific commands for the remote cluster will be ignored due to the conflict resolution rules.

This has a significant effect on failover/failback behavior between ARX clusters.

File Tracking

A slow back-end file server can adversely affect ARX snapshot operations and ARX file-tracking operations. (348788)
When a slow Windows file server is hosting a large number of snapshots and a user requests creation of a new snapshot, that new snapshot can take some time to become available.

With archiving for file tracking, the ARX requests creation of a new snapshot of the volume hosting the metadata for a managed volume. Immediately following the successful completion of the request, the archiving process attempts to access the new snapshot in order to copy the metadata database file to the archive. The copy fails because the snapshot is not available yet.

To lower the recurrence of this issue, ensure that the Windows file server is adequately provisioned.


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 GUI process uses 100% of CPU 1.1 on an ARX with thousands of reports. (31068)

SSH Applet for CLI freezes when pressing key. (340230)
This phenomenon occurs as a result of the interaction between a third-party applet and the web browser in use.

The GUI ignores the selection of an additional fileset in the Tiered Storage wizard. (352000)
When using the Tiered Storage wizard under the Policy > Place Rules menu, the third page of the wizard allows you to select another fileset that can be used to further restrict the age filesets that the wizard generates automatically. This additional selection corresponds to a CLI command that has been deprecated, and this GUI control is no longer recognized by the ARX software.

Workaround: Create an intersection fileset using an age fileset and any other fileset you want to use to restrict the results.


Customer outages caused by adding new IP interfaces to NetApp. (341951)
The NetApp filer responds to portmap requests from the ARX with an IP address that is different than that sent by the ARX. The ARX declines the portmap response and the corresponding NFS service goes offline.

Workaround: Add secondary IP addresses to the external filer definition.


Remote syslog log hostname as "localhost". (353418)
When a remote syslog is configured for an ARX, the syslog file uses "localhost" as the ARX hostname.


A shadow-copy rule runs indefinitely (instead of terminating immediately) when the RON connection to the target share fails. (32110)
A shadow-copy rule should fail as soon as the RON connection to the target filer fails. Instead, it continues indefinitely, waiting for the RON connection to return.

The policyRuleRunSuspend trap does not indicate the cause of the policy suspension. (32756)
An ARX rule may be suspended manually, through a CLI or GUI instruction, or because its schedule has a limited duration that has expired. The trap does not currently indicate whether the suspension is manual or scheduled.

A maximum of 30 snapshot rules can be associated with a single schedule. (339306)
Configuring an excessive number of snapshots to use a single schedule causes delays that prevent the snapshots from being created.

Notify messages display "INVALID ERROR NUMBER". (342666)
In some circumstances, an error message written to the log file when attempting to add a new file to a directory is ambiguous and does not indicate the source of the problem clearly.

T2 files unexpectedly moved to T1 (age-based). (343985)
A file-placement rule with an age-based fileset can function incorrectly when it uses a schedule with the following settings:

- a start time in the 11 O'Clock hour, and

- set to run every Saturday.

The time calculation can fail on the night before the fall DST change. This causes the file-placement rule to run with an invalid time stamp and migrate the wrong files.

Excessive target-full syslog errors should be suppressed. (351459)
The policy engine logs a syslog message whenever it refuses to migrate a file to a share that is too full. (A share is considered too full when it has dropped to its minimum free space, set with the policy freespace command or its GUI equivalent.) These messages are correct, but they can be excessive.

show policy returned POLICY_INTERNAL_ERROR. (351707)
Occasionally, the "show policy" CLI command returns a spurious POLICY_INTERNAL_ERROR message.

NSM Software

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.

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.

An ARX-4000 does not support jumbo frames with 4.1.0 software and older firmware. (32103)
On an ARX-4000 that is running 4.1.0 or later software with an earlier version of firmware, NSM cores fail if they are configured for jumbo frames. (You can enable or disable jumbo frames with the [no] jumbo mtu CLI command.)

The NSM may crash when a backup ARX takes over for an ARX that has rebooted following an excessive number of connections. (348789)

Malformed QPI packet from ARX data plane. (352410)
The ARX is occasionally generating invalid Query Path Info (QPI) packets. The packets contain inconsistent parameter lengths, resulting in malformation.

Workaround: Use the no cifs path-cache CLI command (or its GUI equivalent) in the affected managed volumes. Disabling this option causes the volume software to follow different code paths and avoid this issue. The caveat with this work around is a possible performance penalty; this change causes all QPI requests to go through the control plane before going to the filer.

Mac running 10.5.8 and DAVE 7.1.2 is unable to access a direct share through the ARX. (353445)


Provide warning when entering global mode in down-rev switch. (354004)
It is possible, but generally inadvisable, to make changes in the ARX global configuration under these circumstances:

  • there are two ARX devices, joined in a redundant pair,
  • one has upgraded to a new software release, but the other has not, yet, and
  • the peer with the lower release is active.

There should be a warning in the CLI or the ARX manager (GUI) when you enter the gbl CLI mode or otherwise start to edit the global configuration.

Namespace Software

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.

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

Directory delete-on-close rework. (345018)
When deleting a folder using a Windows 7 client, a display issue may cause the folder to seem to disappear and re-appear, even though the folder has been deleted.

Linux "df" shows 100% disk usage on an ARX export. (353055)
If a Linux client mounts one of the NFS exports on the ARX and runs the df command, the df command may erroneously show the export at 100% capacity.

File Servers

An ARX running 5.2.0+ cannot import a CIFS share from an Isilon storage server. (341470)
Isilon storage servers were not previously qualified for use behind an ARX volume. However, it was possible to import CIFS shares from Isilon servers before Release 5.2.0. If an Isilon share is already imported before the installation of 5.2.0, it continues to function behind the ARX volume until there is a re-import. On import or re-import of an Isilon share, the import may fail with a CIFS_PRIVCHK_FAIL error. Contact F5 Support to work around this issue.

This failure only occurs in a managed volume with persistent-acls enabled.

This may also be an issue with other unqualified servers whose CIFS services are based on Samba.


Spurious syslog errors after snapshot commands. (32230)
After a snapshot command like show snapshot or its GUI equivalent, the following spurious error may appear in the syslog file (available through the GUI or the show logs syslog CLI command):

OM_RECORD_READ_FAILED:: A record read from the configuration database failed. Record 

result code [noMoreRecords [4]] Record name

[StorageContainer] Debug string [containerName="", filerId=0].

The "noMoreRecords" error (shown above) and the "keyNotFound" error (not shown) are sometimes spurious.

Snapshot "out-of-space" error logged as "internal system" error. (340762)
When an ARX snapshot fails due to a file-server running out of space, this syslog message indicates an internal error in the ARX software:

SNAPD-0-NOTE-SNAP_CLEANOUT_INFO:: This snapshot operation for snapshot 'snapshot 

rule rule-name' in volume '/vol-name' failed due to an internal

system error. In order to continue operation, the failed snapshot operation has

been cleaned out. The operation should be retried. There may be orphaned

snapshots on the backing filers due to this failure. These snapshots must be

removed manually.

The 'internal system error' part of this message is erroneous. The rest of the message is correct.


Under very rare circumstances, the ARX may block administrative logins after a reboot. (32537)
An ARX in the F5-Development laboratory did not allow administrative logins after a reboot. Logins to the serial-Console port always timed out after entering the administrative password, and logins to the Out-of-Band Management port (typically labelled "MGMT") were rejected with this error message:

ssh_exchange_identification: Connection closed by remote host

F5 Development has been unable to reproduce this problem, despite hundreds of reboots. We note it here until the problem is proven to be unreproducible at any customer site.

Recovery: Power cycle the ARX.

The 'copy namespace' command does not work on direct (presentation) mapped volumes. (34692)
The copy namespace operation cannot copy a file to a CIFS file server behind a direct (presentation) volume.

On the ARX-4000, CoreCollector code has been changed and may display old cores that were never collected and reported. (34722)
The new CoreCollector code now correctly reports all cores from the current release and previous releases. It may find cores that were never collected and reported.

In initial interview, r is for redo, not restart. (37533)
During the interview, "r" stands for redo the interview, not for restart.

The initial boot script is not clear about this, currently, instructing you to press "r" to restart.

If you replay a 5.2.0+ global-config on a system with an earlier release, domain-join fails for CIFS services. (39767)
The run configs global-config-file CLI command "plays" the global-config-file on the ARX, so that the ARX takes the full storage and policy configuration in that file. Every global-config file contains a special CLI command, kerberos-creds, to keep its CIFS services joined to their Windows Domains during this operation. The 5.2.0 version of this hidden command has changed, so the command fails if played on an ARX running an older release. Therefore, the CIFS services are unjoined to their domains after you use run configs global-config-file.

Workaround: Manually edit the 5.2.0+ global config file so that the kerberos-creds command conforms to earlier releases. Specifically, remove the last three entries from the command. For example, if you find an entry like this in the 5.2.0+ global-config file:

ac1.MEDARCH.ORG MEDARCH.ORG 1Fkua3z04b6mvQrB4K4/+Q== ac1$ HOST/ac1.MEDARCH.ORG 2

You remove the last three entries:

ac1.MEDARCH.ORG MEDARCH.ORG 1Fkua3z04b6mvQrB4K4/+Q==

The above command can play back on an ARX running a pre-5.2.0 release.

The 'show redundancy' command sends DNS PTR query to name server. (344788)
The "show redundancy" CLI command sends DNS PTR queries to name servers.

[ Top ]

Third Party Source Acknowledgements

Release 5.2.0 added the Apache Authentication Module to its platform software. The following sections acknowledge this third-party contribution to the ARX Release:

Apache License

Version 2.0, January 2004 TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Specific Acknowledgements

This package was debianized for Ubuntu by Chuck Short on Tue, 08 Jan 2008 10:20:36 -0500. This package was debianized for Debian by Hai Zaar on Tue, 31 Mar 2009 18:32:20 +0300 based on the work mentioned above. It was downloaded from Upstream Authors:
Nathan Neulinger
Tyler Allison
Dave Woolaway
Sven Koch
Jan Wolter Copyright: Copyright (c) 1995 The Apache Group. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the Apache Group for use in the Apache HTTP server project (" 4. The names "Apache Server" and "Apache Group" must not be used to endorse or promote products derived from this software without prior written permission. 5. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the Apache Group for use in the Apache HTTP server project (" THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE GROUP OR IT'S CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Contacting F5 Networks

  F5 Online Knowledge Base: An online repository of answers to frequently-asked questions.
F5 Services Support Online: F5's online customer support request system.
Telephone: 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)