Hitachi NAS Platform 14.3.7221.03 Release Notes
About this document
This document (RN-92HNAS054-00, June 2022) provides late-breaking information about NAS Platform 14.3. It includes information that was not available at the time the technical documentation for this product was published, as well as a list of known problems and solutions.
Intended audience
This document is intended for customers and Hitachi Vantara partners who license and use NAS Platform.
Accessing product documentation
Product user documentation is available on the Hitachi Vantara Support Website: https://knowledge.hitachivantara.com/Documents. Check this site for the most current documentation, including important updates that may have been made after the release of the product.
Accessing product downloads
Product software, drivers, and firmware downloads are available on the Hitachi Vantara Support Website: https://support.hitachivantara.com/.
Log in and select Product Downloads to access the most current downloads, including important updates that may have been made after the release of the product.
About this release
This release is a major release that adds features and resolves multiple known problems.
The specific build is server update (SU) 14.3.7221.03, and system management unit (SMU) 14.3.7221.03.
NAS operating system, which includes server update 14.3.7221.03 and SMU 14.3.7221.03, supports the following models:
· Hitachi NAS Platform 5200, 5300
· Hitachi NAS Platform 4040, 4060, 4080, 4100
This release introduces support for VSP E1090 and VSP E1090H as attached storage on the 5200/5300 platforms.
The topics in this document could also be relevant to VSP F/G Series (running SVOS 7.4.0), and VSP N Series (running SVOS 7.4.1), by taking note of the NAS module version.
| Note: When upgrading to 14.3, it is advisable to refer to the corresponding release notes of each intervening version to be aware of any new features, special notes and considerations. |
Document history
| Revision | Description |
| 92HNAS054-00 | Initial release of SU version 14.3.7221.03 |
New features
This section describes the key features in version 14.3, and other recently released features. Please refer to the NAS user guides for details on using these features.
For features introduced after the initial 14.3 release, which may not be covered in the published guides, documentation amendments can be found on the Additional Notes page. This page is linked to from the main NAS Platform documentation page (https://knowledge.hitachivantara.com/Documents/Storage/NAS_Platform).
Support for 8 node clustering for HNAS 5300
First available in 14.3.7221.03
Support has now been added for 8 node clusters on HNAS 5300.
NDMP direct-attach tape support for HNAS 5200 / 5300
First available in 14.2.7117.05
HNAS 5200/5300 now has the provision to attach tape drives, for NDMP backup.
Support of HCP CloudScale
First available in 13.9.7021.04
HNAS has been compatibility tested with HCP-CS as a DM2C target; performance results will vary similarly as it does with HCP.
SMU support for CentOS Stream 8
First available in 13.9.6918.05
A virtual SMU can be deployed on a later version of the operating system, CentOS Stream 8. Use version 3.0 of the Hyper-V or VMware template in order to create a virtual SMU based on CentOS Stream 8.
A standard upgrade of an earlier virtual SMU to version 13.9.6918.05 or later will not upgrade the operating system version. If you want to upgrade an existing CentOS 6 SMU to run on CentOS Stream 8, while preserving the existing network address, it is necessary to deploy a new virtual SMU and migrate the settings from the existing SMU to the new one by performing a backup and restore.
More details can be found in the Virtual SMU Administration Guide MK-92HNAS074.
| Note: Both CentOS 6.2 and CentOS Stream 8 are supported in this version. |
| Note: CentOS Stream 8 is not currently supported when using HDRS. |
Automatic barring of SMB clients repeatedly using incorrect passwords
First available in 13.9.6918.02
Provides a facility that maintains a list (per security context) of client IP addresses that are barred from SMB/SMB2.x/SMB3 access to the server. Clients that cause SMB NTLM authentication failures by providing an incorrect password are automatically added to the list if the rate of failure is sufficient. Automatic barring of clients is enabled by default, and a (paced) event is generated when a client is barred.
No initial configuration of the feature is required, however the barred clients list can be managed if necessary using the following Bali commands:
smb-barred-client-add
smb-barred-client-remove
smb-barred-clients-list
smb-barred-clients-clear
Clients are barred based on their IP address so each IPv4 and IPv6 (if configured) address will need to be considered a separate entry. Once a client is barred, it is not possible for that client to connect over SMB regardless of the credentials being used – manual removal from the ‘barred’ list would be required. Up to 512 client IP addresses per security context can be barred.
Native REST API
First available in 13.9.6815.02
A new native REST API mode has been introduced, and will be used for future API improvements and features, replacing the previous legacy REST API versions.
The maximum supported API version remains at version 7, and the new native API implements all the existing version 7 API calls. The native API introduces read-only access via API key and USER level management users, and some small detail changes, including bug fixes. The new rest-server-mode command allows switching between the legacy API and new native API.
More details can be found in the API document MK-92HNAS088-04.
Micro-pruning
First available in 13.9.6815.02
Micro-pruning is supported over SMB.
No additional configuration is required to use this feature. The feature allows existing files to be made sparse, i.e. to delete data and free space within them.
Operations to mark a file as sparse (FSCTL_SET_SPARSE), to prune a file (FSCTL_SET_ZERO_DATA) and to query allocated ranges of a file (FSCTL_QUERY_ALLOCATED_RANGES) are supported over SMB version 2 and above.
Hitachi NAS add-ons
There are several add-ins available for use with Hitachi NAS, as noted here.
The downloads can all be found by following section "Accessing product downloads" and navigating to "Hardware Download", "NAS Platform", and then selecting "Add-ons".
The documentation can be found on the "Solutions and Best Practices" page, which is linked from the main NAS Platform documentation page (https://knowledge.hitachivantara.com/Documents/Storage/NAS_Platform).
HNAS CSI Driver for Kubernetes
Version 1.1.1 (September 2021) - works with NAS 13.3 or later
The Hitachi NAS Container Storage Interface (CSI) Driver is a software component that contains libraries, settings, and commands that you can use to create persistent storage for your containers. It enables the stateful applications to persist and maintain data after the life cycle of the container has ended. The Hitachi NAS CSI Driver provides persistent volumes on Hitachi NAS server platforms (Hitachi NAS platform and NAS module) and is able to clone those volumes and take snapshots of them.
As the driver relies on the ability for containers/pods to access HNAS NFS exports, it can only be used on Linux based systems. This driver requires Kubernetes 1.20 or higher.
Version 1.00 (August 2020) still works, and can work with older Kubernetes versions, but contains less functionality.
Hitachi NAS Modules for Red Hat® Ansible®
Version 1.1.0 (September 2021) - works with NAS 13.5 or later
Hitachi NAS Modules for Red Hat® Ansible® allow IT and data center administrators to automate and manage some of the configuration of Hitachi NAS systems. An administrator can create playbooks together with logic and other Ansible modules to automate complex tasks. Administrators can filter, sort and group the information by piping the output from one module to another. Tasks are executed by running simple playbooks written in yaml syntax.
These modules require Ansible 2.9 or higher.
HNAS docker volume plugin
Version 1.00 (December 2019) - works with NAS 13.2 or later
The NAS server platform (Hitachi NAS platform and NAS module) can be used to provide remote storage for container images running within Docker.
As the plugin relies on the ability for containers to mount HNAS NFS exports, it can only be used on Linux based systems.
The plugin is supported on Docker version 18 and newer, and currently only on stand-alone systems, rather than clusters/docker swarm.
ELK integration for HNAS
Version 1.00 (September 2019)
The NAS server platform (Hitachi NAS platform and NAS module) can be integrated with Elasticsearch. Alert and audit logs can be collected, and then analyzed using Kibana, which helps to visualize data.
Elasticsearch is commonly referred to as the ELK stack or Elastic stack, which refers to Elasticsearch and associated components, which lets you reliably and securely take data from any source, in any format, and search, analyze, and visualize it in real time.
Splunk add-on for HNAS
Version 1.00 (November 2018)
The NAS server platform (Hitachi NAS platform and NAS module) can be integrated with Splunk®. Splunk can be configured to collect alert log and audit log events, in addition to the ability to gather statistics about the NAS server system performance.
Special notes on current NAS releases
Configuring external migration targets
Not specific to this release, but reiterating the need for adequate backup planning.
| Caution: Care should be taken when configuring systems with a single migration destination for both replication source and target (known as a triangular arrangement). Such arrangements should not be considered a valid solution in any disaster recovery (DR) or backup scenario, as there is only a single copy of the user data pointed to by XVLs at each end of the replication policy. |
Deduplication support for Object Replication Targets
Deduplication is supported on Object Replication target file systems, from release 13.6.
| Note: If, before 13.6.6016.05, a filesystem was created to support dedupe and it was later used as a replication target, there will be implications when upgrading to 13.6.6016.05 or later. In this case, deduplication of the replication target will start automatically without any additional action on the user's part. |
In order to avoid this happening, deduplication should be disabled, per filesystem, before upgrading and remain off after the upgrade.
NFS over UDP
If NFS over UDP is enabled, frequent warning messages are displayed on the console and in the dblog. As a workaround, disable UDP. Note that the messages will persist until the clients are remounted.
| Note: Using NFS over UDP has inherent risks and is, therefore, not recommended. |
Group Augmentation changes
A change in 13.5.5527.02 changed the format of the output that create-group-table-from-active-directory.rb presented to any customized massage-commands-for-managed-servers script.
If a customized massage-commands-for-managed-servers script is used to check the output against a whitelist, then it's likely that groups will be incorrectly excluded, and their old definitions will continue to be used by HNAS indefinitely. In this instance it is best to transform the whitelist to suit the output after the upgrade.
HDRS versions
Version 4.x - VSP F/G/Nx00 platforms only.
Version 5.x / 6.x - HNAS 5000 series platforms only.
A change in 13.8 necessitates that any instances of HDRS in use should be upgraded to at least v4.1.
Please do not upgrade the SMU software to 13.9.6628 or later on the VSP F/G/Nx00 platforms, or install a net new GEfN solution on this platform, until HDRS v4.2 or later is installed.
HDRS v5.1 supports a 4 node GEfN cluster on HNAS 5200/5300 in version 13.9.6918.09 or later, although it is preferred that 13.9.7021.01 or later is used. Do not attempt to install HDRS v5.1 on VSP-F/G/Nx00 GEfN deployments.
HNAS 5000 series GEfN
GEfN can only be implemented on systems without any configuration.
GEfN upgrades from a 2-node to a 4-node installation is not supported.
HNAS 5200/5300 clustering
There was a restriction for HNAS 5200/5300 in version 13.9.6420, to limit the cluster size to 2 nodes.
Version 13.9.6628.07 introduces support for 4 node clusters on HNAS 5200/5300.
Version 14.3.7221.03 introduces support for 8 node clusters on HNAS 5300.
| Note: Please note that the use of clustering in a production environment is required for data availability. |
Script output on HNAS 5200/5300
Due to a change in operating system behaviour, on Debian 10 (Buster) based systems such as HNAS 5200/5300, some scripts' output on invocation might not be displayed on the current console. The output can still be found by reviewing the syslog or using the journalctl command.
DSA host keys for SSH access
Since 13.9.6918.02 the HNAS 3000 and 4000 series and the VSP-F/G platforms no longer allow the ssh-dss host key algorithm (i.e., use of the DSA host key).
Notes on installing, upgrading, and downgrading
Notes on this release include:
· NAS platform models 4040 / 4060 have cluster support for up to two nodes.
· NAS platform models 4080 / 5200 have cluster support for up to four nodes.
· NAS platform models 4100 / 5300 have cluster support for up to eight nodes.
· The NAS Manager for the SMU uses cookies and sessions to remember user selections on various pages. Therefore, you should open only one web browser window, or tab, to the SMU from any given workstation.
| Note: When upgrading, remember to remove any avoidances already implemented for any of the defects that have been fixed in intermediate releases (i.e. check for the presence of, and the contents of,startup.scr file for old defects that have since been fixed.) |
Performing a rolling upgrade from older versions of HNAS
If you are upgrading from earlier versions of HNAS, note that there are critical steps which must be followed in a precise sequence to correctly upgrade to version 14.3. Refer to the corresponding release notes of each earlier version for details on rolling upgrades. Additionally, consult with your Hitachi Vantara representative for assistance in upgrading from earlier versions of HNAS.
| Note: For Rolling Upgrades, the latest version of any major code release will be able to roll to any version in the following major code release. As an example, a Rolling Upgrade can be performed from the latest 13.x code release to any version in the 14.x major code release without any intermediate code steps. |
| Caution: If upgrading from versions earlier than version 13.3, an additional step to version 13.6.6016.05 must be performed first, before upgrading to version 13.7.6233.01 or later. This is no longer necessary when upgrading to version 13.9.6815.02 or later. |
| Note: NVRAM mirroring will be suspended during the time that the cluster is on different models of servers. |
Please refer to FE-92HNAS050 if you are planning a hardware rolling upgrade from HNAS 30x0 / 4xx0 to HNAS 5200 / 5300.
| Note: When upgrading from a 4100 to a 5000 the NVRAM is not automatically disabled, so the ICC ports must be disabled prior to the Hardware Rolling Upgrade. |
| Note: If you are using Hitachi Operations Center, the HNAS 5000 series cannot be on-boarded into Analyzer. This is not an HNAS product issue - HOC Analyzer will fully support the HNAS 5000 series in a future release. In the interim, please contact product support for any potential work around until HNAS 5000 series is fully supported in HOC Analyzer. |
File-based replication between different HNAS software levels
The ability to replicate between systems is determined by the version of the software that is running on those systems. The model number of the server is not a factor for interoperability for replication purposes. If both the destination and target servers are running the same major software version (for example, 13.x), replication as ‘managed servers’ is fully supported, but not recommended as this has repercussions when implementing HRO reporting. If the destination and target servers are running different major software versions (for example, 13.x to 14.x), one of the servers is configured as an ‘unmanaged’ server. Replication continues to be fully supported within the constraints of replication between managed and unmanaged servers.
Object-based replication between different HNAS software levels
Object replication was first introduced in HNAS software v8.0 and has been enhanced with each release. For example, version 10.1 was enhanced so that objects maintained their sparseness during incremental replication. Version 11.1 has the ability to preserve file clone states during replication. To ensure interoperability, feature flags are negotiated when object replication occurs between servers running at different version levels.
Object replication between servers is supported up to one major version away. For example, object replication between version 13.x and 14.x is supported.
| Note: Object replication between servers that are more than one major release apart may work (for example, between version 12.x and v14.x) – but this is not supported. |
| Note: When set to transfer XVLs as links, both source and target systems involved in the replication relationship must be running HNAS release v13.4 or later. |
Important considerations to read before installation
Please read the following sections before installing and using 14.3.
Special consideration should be taken when upgrading to the stated versions (or later) from an earlier version, or when planning a downgrade from the stated versions (or later) to an earlier version.
Changes in 13.0
· Support for WFS-1 is now completely removed. Before upgrading the customer MUST migrate any WFS-1 filesystems to new WFS-2 filesystems, as WFS-1 filesystems cannot be mounted.
· NAS Storage Pools (spans) are now limited to 32 filesystems.
· 12.7.4221.07 is the lowest version of code that the system can safely downgrade to.
Changes in 13.2
· Support added for increasing the number of filesystems in a cluster. This must be considered when planning a downgrade to an earlier version, if more than the previous default of 128 filesystems exist.
· Support for REST API v4 added, while still supporting v3.
· 13.2.4527.04 introduced a new command, krb5-nfs-principal-format. If the setting is changed to (the non-default value of) "only-primary", for any EVS, this must be considered when planning a downgrade to an earlier version.
Changes in 13.5
· Support for REST API v7 added, while still supporting v4, and deprecating v3.
The number of filesystems per span limit
By default, the number of filesystems that can be created in any span is limited to 32.
If an existing span has more than 32 filesystems, the span and filesystems are fully supported after upgrading to 13.0 or later. However, it is not possible to create any additional filesystems on the span, until enough filesystems have been deleted to bring the total number below 32.
It is possible to increase this default value using the filesystem-create CLI command with the --exceed-safe-count option. This option must not be used when creating up to 32 filesystems. It must only be used when creating filesystems beyond the 32nd one.
| Note: This option is only available on the CLI. The NAS Manager does not permit you to create more than 32 filesystems. |
For further information, see the File Services Administration Guide.
NFSv3 access during upgrade to 13.2 or later
When a cluster namespace (CNS) is in use on an NFSv3 filesystem, a rolling upgrade to version 13.2 can cause longer transient delays for NFSv3 accesses than normal. Customers using ordinary filesystem exports or other protocols (including NFSv4) do not experience these additional delays.
| Note: This issue only affects the upgrade from a pre-13.2 release to a 13.2-or-later release. Future upgrades will not experience any additional transient delays from this issue. |
The technical issue
Normally, during a rolling upgrade, access to filesystems through NFSv3 and CNS is available while EVSs are migrated between cluster nodes so that each node can be upgraded in turn. Clients can connect to an EVS on a node running older software and access filesystems belonging to an EVS on a node running newer software (or the other way around) because the NAS server uses a stable message format when forwarding the requests.
Software version 13.2 supports an increased number of filesystems and in order to provide this feature, modifies the message formats used to support CNS in a way that is incompatible with earlier releases.
During this rolling upgrade, clients cannot access filesystems that are hosted on a node running a different version of software to the currently connected node. As soon as the EVSs are migrated onto nodes running the same version of software, the clients can regain access to those filesystems.
Workaround
For 2-node clusters (including NAS Modules), follow the usual upgrade procedure. After the first node has been upgraded, and while EVSs are being migrated between the nodes, there is a longer interruption to client access than usual. The interruption ends as soon as all EVSs are migrated to the upgraded node. When the second node has been upgraded, the only disruption is from normal EVS migrations.
For clusters with three or more nodes, there could be a longer period when EVSs are hosted on nodes running different software versions. For these cases, use manual migrations to move all EVSs to nodes running the same software version. This minimizes the period during which the clients cannot access all filesystems.
For details of the manual migration process, or for upgrade procedures, please contact Customer Support.
SMU, server, and cluster compatibility
These release notes highlight SMU release version 14.3.7221.03.
The version of SMU should always be equal to, or newer than, the version of the server / cluster being managed. In the rare situation where such an SMU build is not released, the closest available one should be used.
Since SMU 13.9.6918.05, the following hypervisor images are supported for a virtual SMU
· Hyper-V : Virtual SMU OS 2.2 or 3.0
· VMware : Virtual SMU OS OVA 2.1, 2.2 or 3.0
· Use the 3.0 version to deploy a virtual SMU on CentOS Stream 8 instead of on CentOS 6.
| Note: In addition to VMware player, the virtual SMU (vSMU) is also compatible with the free version of ESXi. |
From SMU 12.7, a virtual SMU can support up to 10 servers / clusters. To manage more than 2 entities from a virtual SMU, the VM’s resources must be increased. One (1) GB memory and one virtual CPU is required per entity. An entity is defined as a single node or a cluster of nodes.
Licensing
New license keys are typically firmware-version specific. Upon upgrading firmware to this release, all previous licenses present on the system will remain in force.
Licensing as it pertains to node replacements
Clustered Node Replacement: Once the NAS cluster has been built, the Cluster MAC-ID will not change regardless which node in the cluster needs to be replaced, so there will not be any reason to request new license keys when replacing a node in a cluster.
Single Node Replacement: In a situation where a single node must be replaced, the original license keys will not be valid on the new node. Please contact TBkeys to transfer the license keys to the replacement node and issue a new permanent license. You will need to supply TBKeys with the MAC-ID of the Original Node and the MAC-ID of the Replacement node.
To request upgrade keys
When ordering license keys for new, licensed features, note that:
· New features with a sale price will be purchased by the customer per normal Hitachi Vantara channel policies and procedures.
· Non-sale feature requests will be routed based on server branding until such time as the relicensing process has been fully integrated.
· Hitachi Vantara Server Request Routing
o The emailed request shall include the following information:
- Customer Name
- MAC-ID of the HNAS Unit (the MAC-ID format is XX-XX-XX-XX-XX-XX), the serial # is not needed or acceptable to issue new keys.
- If you have not followed normal upgrade procedures, please indicate details of your current situation and indicate if a new full set of keys are required. Also, if your server is part of a cluster, please indicate if the MAC-ID is a "Primary" server of the cluster and how many units are in the cluster.
o All permanent upgrade key requests will be handled by way of email sent to TBKeys@hitachivantara.com. Turnaround time on all requests is targeted within 24 hours. Standard working hours for this distribution list (dlist) are 8am to 5pm Pacific Standard Time. See below for emergency situations.
o Should your need for upgrade keys be an emergency, please contact the Hitachi Vantara Support Centers, where Temporary Keys for these features can be provided.
o An email to TBKeys@hitachivantara.com should also be sent to receive your permanent keys.
Fixes and enhancements in version 14.3
| Note: When upgrading, remember to remove any avoidances already implemented for any of the defects that have been fixed in intermediate releases (i.e. check for the presence of, and the contents of,startup.scr file for old defects that have since been fixed.) |
Version 14.3.7221.03
| Issue ID | Severity | Description |
| D151168 | B | Fixed handling of HNAS Fibre Channel address changes on HNAS 5000 series. |
| D147247 | C | Fixed a stability issue in the handling of some Fibre Channel errors on the HNAS 5000 series. |
| D148243 | C | Fixed a stability issue with showall. |
| D149840 | C | Fixed a potential stability issue if the WLOG free page manager were ever to get too busy. |
| D150003 | C | A stability issue caused by more than one reverse migration processing the same path has been fixed. |
| D150326 | C | The augmented group membership is no longer truncated when the LDAP server hits an administrative limit but a "Size Limit Exceeded" error is logged. |
| D150386 | C | Fixed a stability issue linked to asserts "RX/T2_NIB_RX_PUSH/in_buffer_offset_lt_nim_to_fsm_header_byte_length" and "RX/T2_NIB_RX_PUSH/in_buffer_offset_gte_buffer_size" |
| D150416 | C | A CentOS Stream 8-based SMU will now allow NTP peering from its eth0 subnet, like its CentOS 6 predecessor. |
| D150499 | C | Fixed an issue that meant fixfs would often fail to rebuild the indirection object from the free space bitmap, though that's something that it doesn't normally need to attempt. |
| D150502 | C | A privilege escalation in the SMU, both external and embedded, from the manager user to root, through the execution of unsanitized input by the smu-getlogs script, has been prevented. Hitachi Vantara thanks <redacted> for responsible disclosure of this vulnerability. |
| D150535 | C | Fixed an extremely rare race condition discovered in the DI direct memory access block, which has only been seen in VLSI simulation. |
| D150568 | C | When hostname is altered (either by smu-config or the GUI page) fix the Linux configuration to reflect those changes in a way that works on CentOS Stream 8 as well as CentOS 6. |
| D150569 | C | CLI access to Bali from the SMU was broken after running smu-unconfig and then smu-config. |
| D150871 | C | Fix a bug in fixfs code that only occurred when the indirection object was reconstructed from the FSA bitmap. |
| D151078 | C | Fix as issue that causes earlyfail events to be handled incorrectly on Mercury platforms. |
| D136605 | D | Occasional transient problems communicating between Bali and Linux, presenting with "The PAPI client encountered an unexpected error", are now systematically retried. |
| D149104 | D | Re-enabled SSH connection with the ssh-dss host key algorithm on the HNAS 3xxx, HNAS4xxx, VSP-G, VSP-F platforms. That was regressed in the 13.9.69xx release. |
| D149129 | D | Data Migrator to cloud: S3 provider properties have been changed so that the variable request.timeout.seconds is now using the S3-protocol suggested default value of 0. |
| D149159 | D | Updated Azure java sdk to the latest version of 8.6.6 |
| D149674 | D | FTP socket now only created when the FTP service starts. When the FTP service is stopped, the socket is closed. |
| D149796 | D | HDRS versioning information is now available via SMU diagnostics to help with HiRO integration |
| D149996 | D | Added a means to query the power and energy consumed by HNAS5000 series servers using REST API |
| D150228 | D | Data Migrator to Cloud log4j version 1 was upgraded to log4j2 to get back on supported code and address vulnerabilities: CVE-2021-4104, CVE-2019-17571, CVE-2020-9488, CVE-2022-23302 |
| D150328 | D | Miscellaneous enhancements to logging and diagnostics in the areas of management network and packaging. |
| D150387 | D | The SMU now exclusively uses log4j2 in place of log4j, to remove any danger from being on unsupported code, even though we claim the SMU wasn't vulnerable to the known issues in log4j. |
| D150437 | D | Fixes for the following vulnerabilities have been applied to the CentOS Stream8 SMU: aide (CESA-2022:0441) - CVE-2021-45417 openssl (CESA-2021:5226) - CVE-2021-3712 vim (CESA-2022:0366) - CVE-2021-3872, CVE-2021-3984, CVE-2021-4019, CVE-2021-4192, CVE-2021-4193 |
| D150459 | D | Security patches have been applied for the HNAS 5000 series to cover: expat (CVE-2021-45960, CVE-2021-46143, CVE-2022-22822, CVE-2022-22823, CVE-2022-22824, CVE-2022-22825, CVE-2022-22826, CVE-2022-22827, CVE-2022-23852, CVE-2022-23990, CVE-2022-25235, CVE-2022-25236, CVE-2022-25313, CVE-2022-25314, CVE-2022-25315) nss (CVE-2022-22747) ruby2.5 (CVE-2021-28965, CVE-2021-31799, CVE-2021-31810, CVE-2021-41817, CVE-2021-41819, CVE-2021-32066) |
| D150468 | D | FTP service enable/disable failures: Error messages and event logs have been updated to inform the user what's happened and how to fix it |
| D150481 | D | Under certain circumstances, a severe warning event ("WFILE/T2_WFILE_RIP/severe_event_posted_enode_readahead_failed") could be raised, which alerted customers, but was in fact not that severe an issue. This has been downgraded to a "no event" warning, which goes to the dblog, but does not alert customers with such a severe event |
| D150517 | D | Tomcat version for the SMU has been upgraded to 8.5.75 to avoid multiple vulnerabilities |
| D150518 | D | The long term fix, previously mitigated in D150430, for CVE-2021-4034 aka pwnkit is applied here for CentOS Stream 8 external SMUs. |
| D150566 | D | Even the first access of a user that's previously unknown to HNAS is now audited. |
| D150713 | D | Security patches have been applied for the HNAS 5000 series to cover: cyrus-sasl2 (CVE-2022-24407) bind9 (CVE-2021-25220, CVE-2022-0396) nbd-client (CVE-2022-26495, CVE-2022-26496) libtiff5 (CVE-2022-0561, CVE-2022-0562, CVE-2022-0865, CVE-2022-0891, CVE-2022-0907, CVE-2022-0908, CVE-2022-0909, CVE-2022-0924, CVE-2022-22844) |
| D150763 | D | Fixes for the following vulnerabilities have been applied to the CentOS Stream8 SMU: cyrus-sasl (CESA-2022:0658) - CVE-2022-24407 |
| D150838 | D | Simple wildcard searching has been added to the native REST API filtering of results, effectively allowing for a result to contain specific text: *admin* - will match "admin" anywhere in the string *admin - will match any string that ends in "admin" admin* - will match any string that starts with "admin" |
| D150867 | D | Vulnerabilities CVE-2021-29425 and CVE-2020-15250 have been addressed for Data Migrator to Cloud feature |
| D150986 | D | Local administrator rights will again be conferred upon domain administrators without a reboot. |
| D150999 | D | Model HNAS-5300 may now form a cluster of up to 8 nodes (if licensed). |
| D151054 | D | Some REST API calls accept string parameters that can potentially include characters that need to be escaped to ensure valid JSON - handling of the escape characters should now be consistent across all API calls that accept these sort of strings. |
| D150024 | E | Jars upgraded to avoid the following vulnerabilities CVE-2020-15522 CVE-2021-29425 CVE-2020-13956 CVE-2018-10237 CVE-2019-14900 CVE-2020-15250 |
| D150290 | E | File count totals provided by the Bali commands checkfs, fs-stat and dsb have been clarified. |
| D150389 | E | Enhanced logging of errors from the PAPI component and fixed delayed logging of some messages. |
| D150519 | E | Some accidentally enabled debugging code is hidden again. |
| D150520 | E | The Linux tzdata package on the CentOS Stream 8 external SMU has been updated to 2021e. |
| D150570 | E | Fixed to remove an error message which appears when you do smu-unconfig on the SMU. |
| D150624 | E | Bali's grep has been made a little more like the familiar Linux utility. |
| D150684 | E | Fixed an issue that could cause shutdown delays on systems with NIS configured. |
| D150808 | E | The object-number-to-path command is now better behaved in scripts. |
| D151023 | E | Upgraded ant to version 1.10.12 and zip4j to version 2.9.1 in the SMU to avoid vulnerabilities discovered via OWASP. |
New, modified, and deleted CLI commands
See the NAS man pages for details on the new commands.
New commands
None
Modified commands
None
Deleted commands
None
Copyrights and licenses
© 2022 Hitachi Vantara LLC. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including copying and recording, or stored in a database or retrieval system for commercial purposes without the express written permission of Hitachi, Ltd., or Hitachi Vantara LLC (collectively "Hitachi"). Licensee may make copies of the Materials provided that any such copy is: (i) created as an essential step in utilization of the Software as licensed and is used in no other manner; or (ii) used for archival purposes. Licensee may not make any other copies of the Materials. "Materials" mean text, data, photographs, graphics, audio, video and documents.
Hitachi reserves the right to make changes to this Material at any time without notice and assumes no responsibility for its use. The Materials contain the most current information available at the time of publication.
Some of the features described in the Materials might not be currently available. Refer to the most recent product announcement for information about feature and product availability, or contact Hitachi Vantara LLC at https://support.hitachivantara.com/e...ontact-us.html.
Notice: Hitachi products and services can be ordered only under the terms and conditions of the applicable Hitachi agreements. The use of Hitachi products is governed by the terms of your agreements with Hitachi Vantara LLC.
By using this software, you agree that you are responsible for:
1) Acquiring the relevant consents as may be required under local privacy laws or otherwise from authorized employees and other individuals; and
2) Verifying that your data continues to be held, retrieved, deleted, or otherwise processed in accordance with relevant laws.
Notice on Export Controls. The technical data and technology inherent in this Document may be subject to U.S. export control laws, including the U.S. Export Administration Act and its associated regulations, and may be subject to export or import regulations in other countries. Reader agrees to comply strictly with all such regulations and acknowledges that Reader has the responsibility to obtain licenses to export, re-export, or import the Document and any Compliant Products.
Hitachi and Lumada are trademarks or registered trademarks of Hitachi, Ltd., in the United States and other countries.
AIX, AS/400e, DB2, Domino, DS6000, DS8000, Enterprise Storage Server, eServer, FICON, FlashCopy, GDPS, HyperSwap, IBM, Lotus, MVS, OS/390, PowerHA, PowerPC, RS/6000, S/390, System z9, System z10, Tivoli, z/OS, z9, z10, z13, z14, z/VM, and z/VSE are registered trademarks or trademarks of International Business Machines Corporation.
Active Directory, ActiveX, Bing, Edge, Excel, Hyper-V, Internet Explorer, the Internet Explorer logo, Microsoft, the Microsoft corporate logo, the Microsoft Edge logo, MS-DOS, Outlook, PowerPoint, SharePoint, Silverlight, SmartScreen, SQL Server, Visual Basic, Visual C++, Visual Studio, Windows, the Windows logo, Windows Azure, Windows PowerShell, Windows Server, the Windows start button, and Windows Vista are registered trademarks or trademarks of Microsoft Corporation. Microsoft product screen shots are reprinted with permission from Microsoft Corporation.
All other trademarks, service marks, and company names in this document or website are properties of their respective owners.
Copyright and license information for third-party and open source software used in Hitachi Vantara products can be found in the product documentation, at https://www.hitachivantara.com/en-us...any/legal.html or https://knowledge.hitachivantara.com...ource_Software.