Known Issues

If a file is being copied to the StorNext file system using Windows Explorer and Windows Explorer crashes before it finishes copying all the data, the file might contain data blocks from old, deleted files. This problem occurs because Windows Explorer sets EOF to the size of the file before it writes the data to the file. This leaves a gap of uninitialized data in the file.

Note: This problem can also occur with other programs that set EOF beyond the end of data.

This problem does not occur if Windows Explorer encounters an error while writing the file; Windows Explorer will delete the partially written file.

Workaround:

To prevent this problem from occurring on StorNext, you can use the StorNext "client configuration" application's advanced mount option "Restrict Pre-allocation API" on Window systems and the "protect_alloc=yes" mount option on Linux systems. This option will set the unwritten parts of the file to zero. When this option is set, non-root users are unable to use the preallocation ioctl. This option also implies sparse=yes.

For more information on this option, see the man page mount_cvfs(8). The sparse option will introduce some overhead when using Windows Explorer. Before setting the protect_alloc option, see the sparse option in mount_cvfs(8) for a description of how it changes StorNext behavior.

StorNext 5.4.0.x incorrectly allowed the Unix ID Mapping type to be set to none when the Security Model is set to acl. As a result, file systems fail to start when the Unix ID Mapping type is set to none when the Security Model is set to acl.

Beginning with StorNext 6, the FSM does not start when this invalid combination of settings is used.

Workaround:

To prevent this issue, set the Unix ID Mapping to either winbind or algorithmic for any file system where the Security Model is set to acl. You can make the adjustment before or after upgrading.

A StorNext NAS client cannot rename a file if the file has the read-only attribute set. This problem only affects StorNext NAS clients.

Workaround

A StorNext NAS client must remove the read-only attribute before it can rename the file.

If you set the parameter audit=true in the file system configuration file, the result causes all I/O activity, including reads, to be recorded in the mdarchive. This can greatly increase the number of updates applied to the mdarchive which, in turn, increases the amount of mdarchive compaction activity by the FSM.

There is one instance where this increased compaction activity caused the mdarchive to grow beyond the capacity of the HA shared file system.

Workaround

To work around this issue, Quantum recommends you increase the parameter metadataArchiveCache from the default 2 GB to at least 4 GB, but preferably larger when setting audit to true in the configuration file.

If you access StorNext file systems from Apple Xsan clients, then you might encounter I/O error messages in the system log that do not contain details about real I/O errors detected on the Xsan client.

Workaround

If you encounter the errors on an Xsan client, contact Apple.

When running older versions of macOS, an Xsan client cannot mount a StorNext File System volume when a cluster name is included in the local fsnameservers file. An unexpected EOF reading reply error is displayed.

If you encounter the EOF error on your Xsan client, do the following workaround to prevent the issue.

Workaround # 1

Upgrade the Xsan client to the latest version of macOS supported by StorNext.

Workaround # 2

If upgrading macOS is not possible and your MDC fsnameservers file includes a cluster name, remove the cluster name (@_cluster_xx or similar) from the mysan.configprofile file before you copy the file to the Xsan client.

For example, change:

to

See Mount the StorNext File System on Xsan 5.0 (or later) for additional information.

File System Pooling includes an email notification feature, which is enabled by configuring SMTP settings using the sntier config command. These settings are saved in a configuration file within the StorNext configuration directory.

As part of recent changes to enhance security, the SMTP password in this file is now masked (replaced with ********) when File System Pooling is restarted. However, the email notification program currently interprets this masked value literally, causing authentication to the user's email account to fail.

Workaround

A script is available to address this issue. Contact Quantum Technical Support and reference Jira ticket SNXT-2022.

File retrieves from media to disk can be suboptimal for fast tape drives like the Oracle STK T10K drives. This scenario can occur when the retrieve event is initiated on a host that is different from the host running the mover process, which requires the use of synchronous direct I/O.

Workaround:

To work around this issue and achieve optimal performance for both file stores and retrieves with the T10K drives, increase the default I/O size used by the mover process and make the mover process use asynchronous buffered I/O when the use of synchronous direct I/O is not required, using the following steps:

Note: This workaround might also help improve the performance of the faster LTO drives by updating the FS_LTO_BLOCK_FACTOR system parameter.

Note: Changes to FS_xxx_BLOCK_FACTOR only affects tapes formatted after the change.

1. Change the FS_T10K_BLOCK_FACTOR system parameter from 8 to 32 by adding the following entry to
   /usr/adic/TSM/config/fs_sysparm_override:

   FS_T10K_BLOCK_FACTOR=32;

   Note: The T10K default I/O block size is 512 KB or 8 * 64 KB. With the block factor changed to 32, the new T10K I/O block size will be 2 MB or 32 * 64 KB. Presently, the FS_T10K_BLOCK_FACTOR system parameter must not be set to a value that exceeds 32.

2. Restart Storage Manager to ensure the change in Step 1 goes into effect:

   # tsmstop
   # tsmstart

3. Verify the FS_T10K_BLOCK_FACTOR system parameter contains the new value:

   # showsysparm FS_T10K_BLOCK_FACTOR
   FS_T10K_BLOCK_FACTOR=32
4. Save the current copies of your /etc/fstab on the MDCs and the DDM clients.

5. Modify /etc/fstab on the MDCs and the DDM clients to use the auto_dma_write_length and auto_dma_read_length mount options as follows:

   snfs1 /stornext/snfs1 cvfs
   rw,auto_dma_write_length=16m,auto_dma_read_length=16m 0 0
6. Unmount and re-mount your file systems.

7. Use new T10K media to store a copy of the file from the disk.

   Note: Step 7 is very important; when the new copy is made to the new tapes, the new tapes are labeled with a 2 MB block size, which is used for subsequent writes or reads to and from the media. Tapes on which fsformat was run before the change will use the block factor in use at that time. This change will not impact those tapes.

Executing the command snbackup -s while a full or partial backup is running might result in a message that
/usr/adic/TSM/internal/locks/backup.lf is in an invalid format.

This is due to the snbackup -s process reading the backup.lf status file while the backup process is updating it.

Workaround:

Ignore the message; to clear-up the process, re-execute the command snbackup -s (provided that the backup is not writing to the backup.lf status file while snbackup -s is trying to read it again).

When copying files between media using the CLI command fsmedcopy, the file is not re-segmented to match the segment size of the destination media. Rather, the original segments are copied to the target media type and the distribution of segments across destination media will, therefore, be the same as the distribution on the source media.

Note: This behavior might cause file data segment distribution to be sub-optimal on the destination media.

Workaround:

1. Execute fsmedinfo -l to get the key of the file(s) in question.

2. Execute fslocate -k to find the path to that(those) file(s) on disk.

3. Execute fsfilecopy -r to make replacement copy(copies) on a new tape.

Your DDMs might experience a timeout if you try to connect to the database. The issue is identified by an error log in /usr/adic/TSM/logs/tac which contains the text:

Workaround:

1. Increase the database connection timeout value by adding the following line to /usr/adic/mysql/my.cnf under the section labeled [mysqld] connect-timeout=240.
2. Cycle the Storage Manager in order to pick up the updated timeout value.

If you have the IBM APFO driver installed and configured, then when you perform an fsmedread operation of a partial tape block from a full tape block, the operation can fail with errno=12.

Note: This issue affects all IBM APFO versions 3.0.19 and earlier, and has an impact primarily on disaster recovery procedures.

Workaround:

To correct this, perform an fsmedread operation without the IBM APFO driver.

When DDM is enabled for non-primary systems, kernel error messages are logged for reservation conflict because the Primary MDC mounts the tape which sets the reservation to itself and the DDM sets the reservation to itself once the tape is ready.

This issue causes a benign message in the /var/log/messages file for reservation conflict. Since the unmounting of the tape also resets the reservation back to the primary MDC, this message is generated the next time a DDM (non-primary MDC) accesses a tape.

Note: This issue can result in a large amount of log messages on any machine running DDMs.

Workaround:

To workaround this issue, you can filter and drop the messages so they are no longer logged, as follows.

Note: Reservation conflicts that are a problem also produce RAS alerts, so you can also drop these errors.

Create the following rules on all DDM clients, based on the OS, to drop the messages from rsyslog:

For RedHat 6

# echo ':msg, contains, "reservation conflict" ~' > /etc/rsyslog.d/ignore-reservation-conflict.conf

# service rsyslog restart

For RedHat 7

# echo 'if $programname == "kernel" and $msg contains "reservation conflict" then stop' > /etc/rsyslog.d/ignore-reservation-conflict.conf

# systemctl restart rsyslog.service

If metadata restore is interrupted during file system migration or recovery, the FSM process may leave some inodes with the Restoring flag. On restart, the FSM will complete the overall restore operation but leave these inodes with the flag set and incomplete metadata. While no data is affected, this flag is not expected during normal file system operation and will result in an FSM panic when an attempt is made to access the affected files.

Workaround:

Quantum recommends you perform a cvfsck following metadata restore which will detect this condition. However, if the cvlogs are reviewed and there is no evidence of FSM restart during the restore, then cvfsck can be skipped.

If cvfsck reports the presence of the Restoring flag on files, file system restoration should be restarted from scratch by running cvmkfs -r using a fresh copy of metadata archive.

Using autofs to mount a StorNext file system on an MDC is not supported when the same file system also has a native mount point.

For example, if the StorNext file system snfs1 is mounted as /stornext/snfs1, then the MDC should not also have an autofs configuration that mounts it on the MDC in another location such as /space/snfs1. Doing so, causes the fsCheckAffinities and fsCheckTsmFilesystemConfig health checks to fail and generate RAS tickets.

Additionally, this might cause the StorNext GUI to fail unexpectedly for certain operations.

Workaround:

There is currently no workaround for this issue. If you experience this issue, contact Quantum Technical Support.

There is a known issue where stripe group expansion using the StorNext GUI can fail and requires manual intervention to restore file system operation.

Stripe group expansion allows an additional disk (LUN) to be added to an existing stripe group, growing the file system user data space.

The other way to add space to a file system is to create a new stripe group and add this to the file system.

When the GUI executes stripe group expansion, it stops the file system, modifies the configuration file and runs cvupdatefs. If cvupdatefs takes more than 5 minutes to complete, the GUI kills the cvupdatefs utility and reports an error. At this point the file system does not start because the configuration file does not match the current state of the metadata.

Workaround:

To address this issue, you can do one of two things:

• Optimally, you would not attempt the stripe group expansion at all. Instead add a new stripe group to the file system.
• If stripe group expansion is deemed necessary, use the cvupdatefs CLI directly instead of through the GUI. This method does not have any time limitations.

In the case that the StorNext GUI attempt was made and hit the 5 minute timeout, file system operations can be resumed by performing the following:

1. Restore the previous version of the configuration file. This can be found in the following directory:

   /usr/cvfs/data/<fs>/config_history
2. Run the cvfsck utility to verify and potentially correct the metadata.
3. Start the file system.

You cannot use the StorNext GUI to configure or modify a policy class with the GOOGLES3 media type. The process fails with an error similar to the following:

Workaround:

To workaround the issue, Quantum recommends you use the GOOGLE media type rather than the GOOGLES3 media type, not only because the GOOGLES3 media type provides very limited functionality compared to the GOOGLE media type, but also because you cannot use the StorNext GUI to configure or modify a policy class with the GOOGLES3 media type. However, if you have to use the GOOGLES3 media type, then use the CLI fsaddclass command to configure a policy class and the fsmodclass command to modify an existing policy class.

The status and capacity monitors for file systems, libraries, storage disks, and tape drives does not display data on the StorNext GUI home page. This issue is caused as a result of missing font RPM packages on your system.

Workaround:

To workaround the issue, Quantum recommends you do the following:

1. Install the java-1.8.0-openjdk package on your system:

   yum install java-1.8.0-openjdk

2. Restart the Apache Tomcat service:

   systemctl restart stornext_web

If you have an open StorNext user interface browser session, then the browser page might flash due to an ICEfaces error. This occurs when the browser page displays partial data rows, empty data, or all the data.

Workaround:

To workaround the issue, Quantum recommends you do the following:

1. Log out of your StorNext user interface browser session(s).

2. Close all browser tabs and windows.

3. Open a new browser window and access the StorNext user interface (see Access the StorNext User Interface (new UI introduced in StorNext 7.0.1) or Access the StorNext Software GUI).

The Safari browser becomes unresponsive when you attempt to configure an Email server using the StorNext GUI.

Workaround:

To workaround this issue, perform the following procedure:

1. Shut down the Safari browser window(s).
2. Restart the Safari browser, and then retry the operation.
3. Uncheck the Verify SMTP Server Connectivity box, and then retry the operation.
4. Set Authentication to NONE, and then retry the operation.
5. Disable the Safari User names and passwords AutoFill under Safari > Preferences > AutoFill, and then retry operation.

When you use the StorNext GUI to configure the Timeserver or Pool (located within the Network Time Protocol (NTP) section on the Configuration > System > Date & Time page), and enter multiple comma separated IP addresses in the Timeserver Pool field, and then click Test NTP, the NTP test hangs and prevents you from accessing the GUI.

Example of Timeserver Pool Entry

Workaround:

Do the following to workaround this issue:

1. Restart the StorNext GUI.

2. Do not enter multiple IP addresses in the Timeserver Pool field. You can only enter one IP address.

After an appliance firmware upgrade, you might be unable to use previously functioning tape devices because the lin_tape device driver was automatically unloaded during the upgrade.

Workaround:

To workaround this issue, rebuild the lin_tape device driver as shown in the following example:

Quantum installs a self signed certificate (valid for 365 days) in /usr/cvfs/config/certs/ only when installing a snfs-common RPM and if a preexisting certificate file does not exist.

If you use monitoring software (for example, Zabbix), an expired self signed certificate is flagged after it expires.

Workaround:

To workaround this issue, do the following to update an expired self signed certificate:

1. Stop CVFS on the affected client:

   # service cvfs stop

2. Update the certificate:

   # cd /usr/cvfs/config/certs

   # mv server.crt server.crt.orig

   # mv server.key server.key.orig

   # openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -days 365 -subj "/C=US/ST=California/L=SanJose/O=Quantum/OU=Demo/CN=`hostname`" -nodes

3. Start CVFS on the affected client.

   # service cvfs start

The rpm database might corrupt if an rpm operation or a query is unexpectedly interrupted by a signal, reboot, or a system crash on an Xcellis XWD environment in particular, but could also impact a StorNext MDC in a customer-supplied environment and anywhere that the Appliance Controller software or the Unified User Interface (UUI) software runs.

Querying the database might result in errors and report that an installed package is not installed. For example:

These query errors could result in the inability to start StorNext or other Quantum services.

On rare occasions, you might see corruption of the rpm database after a reboot of the system while an rpm activity occured. StorNext, Appliance Controller, and UUI invoke periodic rpm queries that could be running when a reboot occurs that could lead to corruption. The rpm database corruption is more likely to be seen in the event of an ungraceful reboot resulting from a kernel panic, power outage, or SMITH reset, or upon sending the kill signal to a running rpm command which can happen via systemd as part of a normal shutdown/reboot sequence.

Workaround:

Run the following command to repair the rpm database:

After you rebuild the database, run a query to verify the database is repaired:

You might see the following error messages when the Rocky 8 kernel first boots:

Workaround:

You can ignore the error messages.

Note: Your system might require an updated BIOS from the manufacturer to fix and eliminate the warnings.

If your system is running StorNext version 7.2.0 (or later) and Appliance Controller version 4.1.0, you might receive the following operation failure error when you run the qtmcontroller iscsiadm command, and your card link goes down:

Workaround:

To workaround this issue, run the following Appliance Controller command:

Caution: Before you upgrade to StorNext version 7.2.x, Quantum strongly recommends you review this known issue and applicable workaround.

Upgrades on systems originating from StorNext version 6.0.6 or earlier might fail in the pre-upgrade check when upgrading to StorNext version 7.2.0 due to the presence the obsolete rpms openssl098e and tg3 being installed. The following message might appear in the /var/log/DXi/upgrades/Node1.preupgradechk.out or /var/log/DXi/upgrades/Node2.preupgradechk.out log file if these rpms are present:

Note: This issue only affects upgrades to StorNext version 7.2.0 and is fixed in StorNext version 7.2.4. This issue does not impact StorNext version 7.2.2 as that release is only for fresh installations on Xcellis Workflow Director Gen 3 and Xcellis Workflow Extender Gen 3 systems.

Workaround:

To workaround this issue, run the following commands to manually remove the openssl098e and tg3 rpms, if they are installed prior to upgrading to StorNext version 7.2.0:

When performing an upgrade on multiple Xcellis Workflow Extender nodes within a NAS cluster at the same time, you may encounter the following error messages:

Workaround:

To workaround this issue, do the following to performing an upgrade on multiple Xcellis Workflow Extender nodes within a NAS cluster:

• Upgrade all non-master nodes first.

• Verify that each upgraded node has successfully rejoined the cluster before proceeding.

• After all non-master nodes are back online and healthy, upgrade the cluster master node last.

This sequence ensures cluster stability and prevents service disruption during the upgrade process.

Xcellis Workflow Director and Xcellis Workflow Extender fail to mount SMB/CIFS shares

Workaround:

Starting with StorNext version 7.2.0, mounting SMB/CIFS shares on Xcellis Workflow Director and Workflow Extender platforms is no longer supported.

This change occurs because Mellanox OFED drivers replace the default cifs.ko kernel module with a dummy module, preventing SMB/CIFS mounts.

This behavior is by design and will not be modified in future releases.

The snauditlogs utility does not properly handle file and path names that contain the comma (,) symbol. If a file or path contains the comma symbol, the resulting line in the csv log displays incorrect values in some fields.

Workaround:

A patch is available. Contact Quantum Support (see Contacting Quantum Support) and reference Jira ticket SNXT-2317.

Firmware utilities fail when multiple QLogic or Emulex cards are present; there is a problem with the python3-quantum-firmware-utils-1.0.1-17605.noarch.rpm package that can result in a python stack trace when multiple QLogic or Emulex fibre channel cards are installed in a host.

The stack trace occurs when trying to query the cards to report on firmware versions, and will cause the commands in /opt/DXi/firmware to fail. These commands are usually not called directly by users, but by other utilities or scripts, such as upgrade, startup, service.sh menu and collect logs.

The stack traces will cause utilities to fail, but will not block startup or upgrade, and can be ignored until the issue is fixed in a future release.

Below is an example of an Admin alert on upgrade that can be ignored:

The following is an example of the python stack trace found in the Node.upgradeoutput.log file:

Workaround:

There is no workaround for the issue; an updated python3-quantum-firmware-utils package is required to resolve the issue.

The CLIENTS page of the UUI displays duplicate clients.

Workaround:

To workaround this issue, do the following.

1. On the APIGW page of the UUI, click Deregister Endpoint for the endpoint of the duplicate client.

2. Restart the Unified Connector on the client that contains the duplicate entries.

If your system is running StorNext 7.1.1 or earlier, the label N/A is displayed in the Reserved column when you display stripe group information in the UUI.

Workaround:

Upgrade to StorNext 7.2.0 or later to display the Reserved value in the UUI.

When you upgrade the UUI software, the upgrade process might appear to be complete but the Quantum Unified UI Software Upgrade page does not update due to an update-service request that continuously fails with a 404 status code.

Workaround:

To workaround this issue, execute the following command as root on the node where the UUI is running:

When you navigate to the Metrics > Performance and Metrics > Utilization UUI page, you might experience a long delay for the page to display properly.

Workaround:

To workaround this issue, refresh your browser page.

If you navigate to the Metrics > Utilization page, and attempt to download a Historical Usage graph, the image file for the graph might not display properly.

Workaround:

Do the following to workaround this issue:

1. Click the Print chart icon in the UUI.

2. Save the document as a PDF.

When you navigate to the Metrics > Performance and Metrics > Utilization UUI page, you might receive an error when you view a widget in full screen mode and attempt to print or export a data chart.

Example

Workaround:

To workaround this issue, close your browser window and then reopen a new browser window.

If you navigate to the Metrics > Performance page, and attempt to save any data graph as a PNG file or a JPEG file, the image for the graph contains a black background with black text, which results in an illegible data graph.

Workaround:

To workaround this issue, download the data graph in a different format, such as a PDF document, or an SVG vector image.

When you upgrade the UUI software, the upgrade process might appear to be complete but the UUI login page displays an error, preventing you from accessing and logging in to the UUI.

Workaround:

To workaround this issue, execute the following command:

During a fresh installation of the StorNext 7.2 software on the secondary node of an Xcellis system, the UUI Unified Connector client registration is missing after StorNext is converted to an HA pair. On the top navigation menu of the UUI, click CLIENTS to verify the issue; you might notice a client registration for both the primary node and the secondary node.

Workaround:

If you are missing the client registration for the secondary node, Quantum recommends you perform either of the following options to workaround this issue.

Workaround Option 1

As the root user, SSH to the secondary node and execute the following command:

Workaround Option 2

Reboot the secondary node.

In the UUI (Metrics > Dashboards), the error below might appear in your widget when you perform the following steps:

1. On the top navigation menu, click Metrics, and then click Dashboards on the left navigation menu.

2. Create a new dashboard.

3. Add a widget for a file system to the dashboard you created in Step 2.

4. Stop and start the file system.

5. On the top navigation menu, click Metrics, and then click Dashboards on the left navigation menu.

Example of error

Workaround:

To workaround this issue, remove the existing widget from dashboard and add a new widget.

If you install the UUI software on a customer-supplied system, the following error message appears in the ./uui-install.sh script output when the installation completes.

Example of error

Workaround:

You can ignore the error message.

When performing a single to dual-server upgrade and restoring the UUI on the secondary node, all USBE requests may return a 404 error.

This affects service availability for components relying on USBE endpoints.

Workaround:

To workaround this issue, do the following to make the secondary node become the primary node UUI.

1. On the secondary node, enter the following CLI commands to stop any UUI services:

   /opt/quantum/uui-common/bin/uui autostart disable

   /opt/quantum/uui-common/bin/uui stop

2. On the primary node, enter the following CLI command to force the UUI to synchronize its configuration:

   /opt/quantum/uui-common/bin/uui_ha_mgr.sh --sync --force

3. On the secondary node, enter the following CLI command to make it the primary node UUI:

   /opt/quantum/uui-common/uui_ha_mgr.sh --primary

Note: If USBE requests return a 404 error, contact Quantum Support (see Contacting Quantum Support).

In the UUI under System Settings > System Settings, the description of the Stale Endpoint Expiration Days field is not correct. The description appears as:

Workaround:

The correct description of the Stale Endpoint Expiration Days field is:

In the UUI under System Settings > Security Settings, the default value of the Automatic User Logout Inactivity Time (minutes) field on a fresh installation is not correct. The value appears as:

Workaround:

The correct default value of the Automatic User Logout Inactivity Time (minutes) field on a fresh installation is:

After upgrading, some API Gateway (APIGW) endpoints may continue to display outdated version information for the Unified Connector (UC) and Storage Manager.

Workaround:

To workaround the issue, do the following:

For the Unified Connector

• Enter the following to restart the Unified Connector service:

  service unified-connector restart

For Storage Manager

1. Unregister Storage Manager from the API Gateway.

2. Allow approximately 10 minutes for Storage Manager to automatically re-register with the API Gateway.

The Last Errored Jobs functionality does not display an accurate representation of your File System Pooling jobs.

Workaround:

Use the Jobs or the Job History interface to view an accurate representation of your File System Pooling jobs.

There is an issue that prevents a LAN client from appearing on the Clients page for up to 20 minutes or more.

Workaround:

There is currently no workaround for this issue. A fix will be implemented in a future release of the Quantum UUI.

Users that are specifically assigned the quantum-flexsync-admin role are currently unable to view or browse the contents of the File Browser.

When attempting to access the File Browser, the following error is displayed:

This issue appears to be related to insufficient permissions associated with the role.

Workaround:

If possible, assign the user a broader composite role (for example, quantum-admin or quantum-superadmin) that is known to have full access to the File Browser.

When downloading and extracting the Unified Connector package for Windows Server OS from the Clients > Software Downloads page, you may encounter the following error:

This occurs because the .msi file within the archive has a file name or path that exceeds the Windows maximum path length limit, preventing successful extraction.

Workaround:

To avoid this issue, download the Unified Connector package for Windows OS instead. This version contains shorter file paths and extracts successfully on Windows systems.

When uninstalling the Unified Connector for Windows via the user interface, you may encounter the following warning:

Workaround:

You can safely click Ignore to proceed with the uninstallation. This warning does not impact the removal process.

When installing or uninstalling the Unified Connector for Windows via the command-line interface (CLI), the package downloaded from Clients > Software Downloads contains incorrect script files.

Expected files:

• uc-install.ps1

• uc-uninstall.ps1

Actual files included:

• uc-install.sh

• uc-uninstall.sh

Note: These are intended for Linux systems and are not compatible with Windows.

Workaround:

To avoid this issue, use the UI for installation and uninstallation on Windows (see Install or Upgrade the Unified Connector).

After upgrading, the UUI browser console may not display any devices upon login.

Workaround:

Execute the following command to restart the UUI service on the StorNext node where the UUI service is running:

Users that are specifically assigned the quantum-alert-admin role are currently unable to remove alerts.

This issue appears to be related to insufficient permissions associated with the role.

Workaround:

If possible, assign the user a broader composite role (for example, quantum-admin or quantum-superadmin) that is known to have full access to alerts.

In older QBSP software versions of the H-Series or F-Series systems (prior to QBSP version 2.0), the Health status may appear grayed out even when the system is online and healthy; when you navigate to the Nodes UUI page, the health indicator for your node may display an incorrect status.

This issue can occur if Controller B is registered with the API gateway.

Workaround:

To workaround this issue, ensure that Controller A is registered with the API gateway (see API Gateway Registration and Configuration).