Symptoms
File level restore (FLR) fails when Avamar server and the Proxy are running different versions. If this behavior occurs where both Avamar server and Avamar proxy are running the same major version, see; Avamar - Avamar 19.7/19.8 File Level Restores fail after Avamar server is upgraded from 19.4 or earlier.The FLR job fails.In the Avamar Java MCGUI, we see: The VMDK filename is not valid or present. Verify that the proxy was correctly registered using the supported method in the documentation In the AUI interface, we see this:
The proxy axionfs logs (/usr/local/avamar/var/axionfs.log) shows:
[axionfs] snapupdirobj::getlabelnumsnapup rslt=MSG_ERR_PSWD_INVALID, list.cnt()=0
Cause
Due to a Security change the Avamar 19.7, FLR operations are not backwards compatible with older versions of Avamar Proxies. .Avamar 19.7: Due to STIG password requirements, the internal restoreonly account password was changed in 19.7 Avamar server and the Avamar 19.7 proxy client.This password change causes backwards compatibility problems when using mixed Avamar Server and proxy versions (a mixed version configuration is NOT recommended). It also occurs where the Avamar 19.7 server still uses the old restoreonly password. This issue is under investigation. Background: Avamar FLR uses a process called axionfs. The process logs in to the Avamar server using the restoreonly user account plus a secure ticket client ID that is generated dynamically by the Avamar server for that particular browse session.The target client and the labelnum are validated against this secure ticket. Limitation:The Avamar FLR browse workflow has a limitation where the internal restoreonly credentials are not sent by the Avamar server.Instead it relies on a fixed, encoded configuration file that exists on every Avamar Proxy.The file is located at /usr/local/avamar/var/axionfs.cmd.
Resolution
Ensure both the Avamar proxy and Avamar server are running the same version.
