Tag: Cluster

The OneFS cluster inventory request API  enables automated workflows to query detailed hardware and infrastructure inventory information from a PowerScale cluster. This capability, which was introduced in OneFS 9.12, is particularly useful for orchestration and discovery use cases, functioning in a manner similar to how LLDP is used within networking environments to collect device and topology data.

The new REST API provides comprehensive inventory details at both the node and backend fabric levels. Node‑level inventory includes general system information, baseboard management controller (BMC) data, network interface details, and attached storage drives. In addition, the response includes backend switch inventory information for supported Ethernet switches running firmware versions later than 10.5.2. InfiniBand switches are not currently supported by this feature. The API also returns the last known inventory state for any component that is offline at the time of the request, such as during upgrades or maintenance, allowing visibility into previously collected data even when a component is temporarily unavailable.

The inventory collection mechanism uses a producer‑consumer design model. On the producer side, cron jobs periodically query cached node and switch information and store the results as inventory cache files within the /ifs filesystem. For node‑level inventory, OneFS collects system and hardware details and saves them to the node information cache. For backend switches, inventory data is retrieved from the switch information cache. The cluster inventory request API also leverages the existing OneFS FlexNet service and its data store to collect network interface details such as IP addressing and interface configuration.

On the consumer side, a new platform API handler reads these cached inventory files from /ifs and assembles them into a consolidated inventory report, which is then returned to the requesting client. This design avoids real‑time polling of hardware during API requests, improving both performance and reliability.

Here are some details regarding the new cron jobs and event triggers:

Several periodic and event‑driven mechanisms are used to keep the inventory data current. A scheduled cron job updates the node‑level inventory cache every twelve hours, while a separate cron job refreshes the backend switch inventory cache every fifteen minutes. For example:

# cat /etc/crontab | grep inventory

# run the gather inventory switches info every 15 minutes

*/15    *       *       *       *       root    isi_ropc /usr/bin/isi_gather_inventory -t switches

# run the gather inventory node cache info every 12 hours

0       */12    *       *       *       root    /usr/bin/isi_gather_inventory -t node

In addition to these scheduled updates, OneFS uses event‑driven triggers to refresh inventory data when relevant system changes occur. For example, when the /ifs filesystem is mounted, OneFS automatically triggers a node‑level inventory update to ensure the latest data is captured. Network‑related inventory data is updated in response to IP configuration changes via the FlexNet database.

The inventory cache data is stored in three locations within /ifs, consisting of the node inventory cache, the switch inventory cache, and the FlexNet database for network interface information. Customers access the inventory data through a single REST API endpoint provided by the OneFS platform API at /platform/<version>/cluster/inventory:

http://<x.x.x.x>:8080/platform/26/cluster/inventory

Or with python:

# python -c 'import isi.papi.basepapi as papi; resp = papi.get("/cluster/inventory");print(resp.body)'

Note that access to this inventory endpoint requires the requesting user to possess both the ‘ISI_PRIV_DEVICES’ and ‘ISI_PRIV_NETWORK’ RBAC privileges.

Here’s an example of this substantial inventory report from an F210 cluster:

When queried, the API returns a structured inventory report comprising two primary sections: a

• Nodes array
• Switches array

For example:

Specifically, each ‘nodes’ object represents an individual node in the cluster and includes nested objects for its drives, BMC details, and network interfaces. The ‘switches’ array represents the entire backend fabric, and may include multiple backend switches, with each switch object containing its corresponding port‑level information.

If a backend switch query fails, the behavior depends on whether valid inventory data was previously collected. If historical data exists, the API returns the last known switch inventory state. If the backend switch has never been successfully queried, the switches section of the response will be empty. This behavior ensures that the inventory report remains consistent and informative even when transient connectivity issues occur.

The PowerScale OneFS cluster inventory request API (`isi.papi.basepapi`) allows native Python integration for cluster inventory operations, offering more robust error handling and authentication management compared to direct HTTP requests. This native API approach is particularly well-suited for DevOps automation workflows, enabling seamless integration with configuration management tools, CI/CD pipelines, and infrastructure-as-code frameworks.

The fundamental approach to accessing cluster inventory through the OneFS cluster inventory request API involves importing the `isi.papi.basepapi` module and using the `get()` method to retrieve inventory data. This method provides automatic session management, authentication handling, and response parsing, simplifying the development of automation scripts. For example, here’s a basic python script to perform a node and drive inventory on a cluster:

#!/usr/bin/env python3

import isi.papi.basepapi as papi

try:

    resp = papi.get("/cluster/inventory")

    if resp.status == 200:

        inventory = resp.body

        nodes = inventory.get("nodes", [])

        drive_count = sum(len(node.get("drives", [])) for node in nodes)

        print(f"Cluster contains {len(nodes)} nodes")

        print(f"Total drives: {drive_count}")

    else:

        print(f"Error: {resp.status} - {resp.body}")

except Exception as e:

    print(f"API Error: {e}")

The script’s output is along the following lines:

# python3 inventory.py

Cluster contains 228 nodes

Total drives: 4342

From a troubleshooting perspective, OneFS also includes an internal ‘isi_gather_inventory’ command line (CLI) utility that can be used to manually initiate inventory collection.

Note that the ‘isi_gather_inventory’ CLI tool can only be run by root.

Separate commands are available to gather node inventory data or backend switch information, and related messages are written to the system log. The utility does not generate standalone log files, but inventory cache contents can be collected using standard OneFS support log packages, which include archived copies of the node and switch inventory cache data.

PowerScale inventory monitoring can be readily integrated into modern DevOps and infrastructure automation workflows. Within CI/CD pipelines—such as those implemented in Jenkins—the OneFS cluster inventory API enables automated pre-deployment validation, ensuring cluster health and configuration integrity before changes are applied. This approach supports continuous change detection and compliance verification as part of the delivery lifecycle.

Configuration management tools such as Ansible can leverage the cluster inventory API for dynamic inventory generation and real-time state validation. By querying current cluster conditions during playbook execution, automation workflows can enforce guardrails that ensure configuration changes occur only when predefined operational criteria are met. Similarly, Terraform can consume inventory data via external data sources, enabling adaptive infrastructure-as-code patterns that align deployments with the actual cluster state and reduce configuration drift.

GitOps workflows further benefit from PowerScale inventory integration by embedding automated validation checks into controllers and operators. Infrastructure changes are applied only when cluster conditions are healthy and compliant, providing a reliable mechanism for policy-driven storage management at scale.

Beyond deployment orchestration, the cluster inventory API supports a wide range of operational use cases. Capacity planning automation can be achieved through periodic collection of node and drive inventory data, combined with trend analysis to forecast growth and trigger proactive alerts as utilization thresholds are approached. Performance monitoring systems, such as Prometheus, can ingest inventory and performance metrics to provide end-to-end observability, enabling threshold-based alerting and long-term performance optimization.

Maintenance workflows can also be automated using the API’s health and hardware inventory data to detect failing components and initiate remediation processes. Integration with IT service management and procurement systems enables automated ticket creation and replacement part ordering, while detailed hardware metadata ensures compatibility and accuracy. Finally, regular synchronization with configuration management databases (CMDBs) ensures inventory accuracy, supporting change management, auditability, and compliance reporting across the storage environment.

In this second article in the series we turn our focus to the configuration and management of the user account lockout functionality.

As discussed in the previous article, OneFS 9.13 adds three new account lockout configuration settings for the file provider. The ‘lockout-threshold’ parameter defines the maximum number of failed authentication attempts allowed before an account is locked. The ‘lockout-window’ specifies the time period over which those failed attempts are counted; if the threshold is not reached within this window, the failure counter automatically resets. Lastly, ‘lockout-duration’ determines how long the account remains locked after the threshold has been exceeded.

In operation, when repeated incorrect password attempts, whether from a legitimate user or a malicious actor, reach the configured threshold within the specified window, the account is locked for the defined duration. During this lockout period, authentication is prohibited even if the correct credentials are provided. Cluster admins can review the account’s lockout status and manually unlock it if desired. Setting the threshold to zero disables the lockout mechanism altogether. Additionally, if failed attempts are spaced beyond the lockout window or a successful authentication occurs before the threshold is reached, the failure counter resets and no lockout is enforced.

So how does user account lockout work in practice?

1. Starting with a PowerScale cluster running a fresh OneFS 9.13 install, a new user (‘testlock1’), is added to the system zone’s file provider.

# pw user add -n testlock1

2. Next, the user ‘testlock1 is added to the ‘AuditAdmin’ role and the password is reset:

# isi auth roles modify AuditAdmin –add-user testlock1

# isi auth users reset-password testlock1

Z,71GGsuw,36l.XK

3. The user’s lockout status can be verified as follows:

# isi auth users view testlock1 | grep -i lock

                  Locked: No

As expected, our new ‘testlock1 file provider user’s lockout status as not locked.

Since this is a fresh 9.13 install, the user lockout parameters are still their default configuration.

# isi auth file view System | grep -i lockout

       Lockout Duration: Now

      Lockout Threshold: 0

         Lockout Window: Now

As such, the lockout threshold value of ‘0’ above indicates that user account lockout is currently disabled.

4. Next, the lockout-threshold is set to ‘3’, the lockout-duration to 60 seconds, and the lockout window 60 seconds too.

# isi auth file modify System --lockout-threshold=3 --lockout-duration=60 --lockout-window=60

Enabling the user lockout function may make the administrator account vulnerable to Denial of Service (DoS) attacks, potentially rendering the entire system unmanageable. Therefore, please choose the configuration values for lockout-duration and lockout-window carefully.

Be cautious when setting these values:

- Avoid setting lockout-duration to 0 (which means indefinitely) or a very long time, as this may result in being locked out for an extended period or even indefinitely.

- Avoid setting lockout-window to 0 (which means the failed attempt count will never be reset) or a very long time, as this may require waiting too long before the failed attempt is reset or may never be reset.

Additionally, to minimize the risk of Denial of Service (DoS) attacks, please configure the accounts that are excluded from the user lockout feature.

Are you sure you want to proceed with this action? (yes/[no]): yes

Before OneFS enables this configuration, it displays the above warning. This message warning that enabling lockout comes with the risk of DoS attacks by rendering the system unmanageable, and suggests excluding admin account(s).

5. The success of the above ‘isi auth file modify’ command can be verified as follows:

# isi auth file view System | grep -i lockout

       Lockout Duration: 60

      Lockout Threshold: 3

         Lockout Window: 60

6. After three attempts to log in as user ‘testlock1 with the wrong password within the lockout window of 60 seconds, this user ‘testlock1 is locked out:

login as: testlock1

Keyboard-interactive authentication prompts from server:

| Password:

End of keyboard-interactive prompts from server

Access denied

Keyboard-interactive authentication prompts from server:

| Password:

End of keyboard-interactive prompts from server

Access denied

Keyboard-interactive authentication prompts from server:

| Password:

End of keyboard-interactive prompts from server

Access denied

Keyboard-interactive authentication prompts from server:

| Password:

This can be verified from a cluster admin account, such as ‘root’, as follows:

# isi auth users view testlock1 | grep -i lock

                  Locked: Yes

7. Since the lockout duration is also set to 60 seconds, after one minute this account will be unlocked.

Alternatively, this account can be unlocked manually by an administrator. For example:

# isi auth users view testlock1 | grep -i lock

                  Locked: Yes

# isi auth users modify testlock1 -–unlock

# isi auth users view testlock1 | grep -i lock

                  Locked: No

If a user is added to the exclusion list, the account, in this case ‘testlock1’ is automatically exempted from this lockout function. For example:

# isi_gconfig registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers=’[“testlock1”]’

Note that OneFS does not check whether a user account name is valid when it is added to the exclusion list.

The lockout duration value can be specified in several ways. For example, a simple numeric value equates to seconds. For example:

# isi auth file modify System --lockout-duration=60

The above configuration will lockout for sixty seconds (one minute).

Other more convenient time period notation can also be used, such as M=minute, H=hour, D=day, W=week, etc.

For example, a two day lockout duration can be expressed as follows:

# isi auth file modify System --lockout-duration=1D

Or:

# isi auth file modify System --lockout-duration=48H

The user account lockout feature provides a configurable exclusion list, which allows certain users (eg. ‘root’ and/or ‘administrator’) to be exempted from lockout. This exclusion list is housed in gconfig, and is configured using the following ‘isi_gconfig’ CLI command permutations:

So, for example, the syntax for adding ‘testlock1’ and ‘testlock2’ system zone user accounts to the lockout exclusion list is as follows:

# isi_gconfig registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers=’[“testlock1”, ”testlock2”]’

# isi_gconfig registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers

registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers (char**) = [ "testlock1", "testlock2" ]

Note that the system file provider exclusion list is already present by default, so there is no need for a create option. However, for a non-system zone file provider, the exclusion list needs to be created first, before it can be modified and/or viewed.

To guard against cluster admin accounts becoming inadvertently locked out, a recommended practice is generally to add ‘root’ and/or ‘administrator’ to the exclusion list. For example:

# isi_gconfig registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers='["root","administrator"]'

# isi_gconfig registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers

registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers (char**) = [ "root", "administrator" ]

Also, be aware that configuring the ‘lockout duration’ parameter to ‘0’ means the account will never get unlocked automatically, so exercise caution when configuring lockout duration.

As we gear up for next month’s Dell Technologies World, PowerScale is welcoming spring with the debut of the innovative OneFS 9.14 release, which officially shipped today (April 8, 2026).

OneFS 9.14 brings a wave of enhancements across spectrum of the PowerScale platform. As the product continues to evolve, this release focuses on strengthening core functionality, expanding hardware and object support, delivering stronger security capabilities, improving serviceability, and elevating overall usability and customer experience.

Below is an early look at what’s coming, with deeper technical dives on individual features to follow in future posts.

Streamlined Deployment and Automation Enhancements

OneFS 9.14 introduces zero‑touch provisioning DHCP support, enabling nodes to automatically receive their IP addresses during deployment. This capability is designed to simplify large‑scale automated rollouts and reduce the operational overhead associated with manual node configuration.

The release also adds a new REST API for syslog management, giving customers the ability to automate creation and updates of syslog configurations. Instead of navigating the GUI and making manual adjustments, storage admins can now easily script and manage logging settings programmatically, making it ideal for environments with tightly automated and/or DevOps-driven workflows.

Customers who rely heavily on SmartQuotas quota description metadata gain more flexibility as well. The maximum description field size in configuration objects increases from 1 KB to 4 KB and 4095 ASCII characters, allowing for richer metadata that is easier to search, categorize, and align with operational requirements.

SMB and Object Storage Improvements

SMB environments will benefit from SMB2 durable handle support for static network pools, which keeps file handles active on the server briefly after a client disconnects. This means that if a connection drops, users can reconnect without re‑authenticating—improving application resilience while maintaining security boundaries.

On the object storage side, OneFS 9.14 introduces support for S3 CORS buckets, enabling modern web applications to retrieve and display resources without running into browser security restrictions. New S3 lifecycle‑management capabilities also arrive in this release, including automated cleanup of incomplete multipart uploads and rule‑based object deletion. These features help keep buckets clean, reduce storage waste, and simplify long-term data management.

Security Advancements

Security continues to be a critical pillar of the platform. OneFS 9.14 expands authentication capabilities by adding CAC/PIV support for LDAP server hosts, extending the existing HTTPS‑only support. This enhancement allows customers operating in high‑security environments, especially governmental or other regulated sectors, to integrate more seamlessly with their identity infrastructure.

Additionally, CAVA antivirus scanning now supports HTTPS, replacing the older HTTP requirement. As more customers move to encrypted communications by default, this enhancement ensures that antivirus scanning can remain active without compromising network security posture.

Platform & Hardware Enablement Updates

The release introduces backend support for the Dell Z9432 top‑of‑rack switch, enabling higher connectivity density. A second supplier option for Ethernet HB NICs (Broadcom) also enters the portfolio, expanding hardware flexibility and supply-chain resilience.

Serviceability receives a boost as well. A diagnostics tool previously reserved for internal service teams is being productized, providing the ability to capture deeper performance and slow‑processing data on demand. This tool can be activated and disabled by the customer and provides valuable insight during troubleshooting, helping reduce time to resolution.

Finally, there’s also new in‑band automation for upgrading or downgrading backend switch firmware, making infrastructure maintenance significantly easier. Customers gain additional control over their system health workflows with the ability to enable or disable automatic downloads of healthcare definitions—an important feature for environments with strict update governance.

In summary, OneFS 9.14 brings the following new features and functionality to the Dell PowerScale ecosystem:

OneFS 9.14 is shaping up to be a significant release that strengthens the PowerScale ecosystem across automation, object storage, security, serviceability, and hardware support. With a blend of immediate production-ready enhancements and forward‑looking technical previews, this release continues the platform’s momentum toward greater scalability, operational simplicity, and enterprise-grade resilience. Stay tuned for deep-dive articles where we explore each feature in detail and discuss how customers can leverage them in real-world deployments.

We’ll be taking a deeper look at the new OneFS 9.14 features and functionality in blog articles over the course of the next few weeks.

Meanwhile, the new OneFS 9.14 code is available on the Dell Support site, as both an upgrade and reimage file, allowing both installation and upgrade of this new release.

For existing clusters running a prior OneFS release, the recommendation is to open a Service Request with to schedule an upgrade. To provide a consistent and positive upgrade experience, Dell Technologies is offering assisted upgrades to OneFS 9.14 at no cost to customers with a valid support contract. Please refer to this Knowledge Base article for additional information on how to initiate the upgrade process.

OneFS 9.13 introduces a new user‑lockout security mechanism for file‑provider accounts to protect against brute‑force and password‑guessing attacks. While PowerScale has long supported lockout controls for local authentication providers, this release extends equivalent protection to file‑provider accounts.

The OneFS user account security architecture can be summarized as follows:

Within the OneFS security subsystem, authentication is handled in OneFS by LSASSD, the daemon used to service authentication requests for lwiod.

In OneFS Authentication, Identity Management, and Authorization (AIMA) there are several different kinds of backend providers: Local provider, file provider, AD provider, NIS provider, etc. Each provider is responsible for the management of users and groups inside the provider.

OneFS 9.13 introduces three new account lockout configuration parameters  for the file provider. First, the ‘lockout‑threshold’ parameter specifies the number of failed authentication attempts required before the account is locked. ‘Lockout‑window’ defines the time interval during which failed attempts are counted. If the user does not exceed the threshold within this window, the counter resets after the window expires. Finally, the ‘lockout‑duration’ parameter determines how long the account remains locked once the threshold has been exceeded.

In practice, when a legitimate user or malicious attacker enters an incorrect password repeatedly and the number of failures reaches the configured threshold within the defined window, the account is locked for the duration specified. During the lockout period, the account cannot authenticate even with a correct password. Administrators can view the account’s status and manually unlock it as needed. If the threshold is set to zero, the lockout feature is disabled. Additionally, if failed attempts occur but the user either waits longer than the lockout window or successfully authenticates before reaching the threshold, the failure counter resets and no lockout occurs.

Because some file‑provider accounts, such as root and administrator, are essential for cluster maintenance, misconfiguration or malicious use of this feature could create operational or denial‑of‑service risks. To mitigate this, OneFS 9.13 introduces an exclusion list that prevents designated accounts from being subject to lockout. Administrators can configure and modify this gconfig-based exclusion list  via the OneFS CLI. Modifying the exclusion list requires elevated operating‑system privileges, as it is intended to act as a safeguard rather than a routine configuration tool.

The lockout feature becomes available only after a OneFS 9.13 upgrade has been fully committed. Removing the upgrade also removes the associated configuration. No licensing is required to enable the feature. Three corresponding options are now available through the OneFS 9.13 CLI—lockout‑threshold, lockout‑window, and lockout‑duration—and can be set during provider creation or modified afterward.

Configuration is accessible through the WebUI under the Access, Membership, and Roles section, where password policies for local or file providers can be adjusted. Administrators can specify the threshold, window, and duration values, and may manually unlock accounts if needed. Setting the lockout duration to zero results in a permanent lockout until an administrator intervenes. The exclusion list for the system file provider is managed using the isi_gconfig interface, while non‑system file‑provider exclusion lists must first be created and then modified individually.

For troubleshooting, a new SQL‑backed IDDB file has been introduced to store user‑lockout data. This DB file is located at /ifs/.ifsvar/modules/auth/file/filelockout.db. While typically not required for routine administration, it can assist in diagnosing unexpected lockout behaviors.

OneFS also support an exclusion list for user lock-out functionality. In OneFS, certain local system accounts, such as root and administrator, are critical to cluster management and system access. If the account lockout mechanism is unintentionally enabled for these accounts, or if repeated failed login attempts occur (whether accidental or malicious), the resulting lockout could render the system unmanageable. This also presents a potential denial‑of‑service (DoS) vector, since an attacker could intentionally trigger lockouts on privileged accounts.

To mitigate this risk, OneFS introduces a configurable exclusion list. Any account added to this list is exempt from the lockout mechanism and will not be disabled, regardless of failed authentication attempts. The exclusion list can be configured and modified through the CLI, WebUI, or Platform API. Because this mechanism functions as a safety measure and last line of defense, it is exposed only through privileged configuration interfaces (for example, via gconfig), requiring elevated OS‑level permissions.

The lockout feature is controlled by the lockout threshold. When this threshold parameter is set to a non‑zero numerical value, the feature is activated. Conversely, when the threshold is set to 0 (the default), the lockout function is disabled.

A user will be locked out if they repeatedly enter incorrect credentials within the configured lockout window and reach the specified threshold. Immediately after lockout, the user cannot authenticate, even with a correct password, until an administrator reviews the account status and manually unlocks it.

Alternatively, if the user waits longer than the defined lockout window between failed attempts, the failure counter is reset to zero. At this point, an access attempt with the correct password entered will be successful.

In a scenario where a user does become locked out, there are two recovery methods:

Additionally, accounts may be added to the exclusion list, preventing them from being locked out in the future. OneFS distinguishes between the system file provider and non‑system file providers, and the procedure for adding accounts to the exclusion list differs slightly between the two.

Three new options have been added to the ‘isi auth file create/modify’ CLI command in OneFS 9.13 in support of this functionality:

The currently configured lockout parameters can be viewed as follows:

# isi auth file view System | grep -i lockout

Lockout Duration: 10m

Lockout Threshold: 0

Lockout Window: 5m

Alternatively, the user lockout configuration can also be accessed from the OneFS WebUI by navigating to Access > Membership and roles > Password policy, and selecting the desired provider:

After selecting ‘FILE:System’ from the ‘Providers’ drop-down menu, the threshold lockout parameters are displayed and can be configured to specify how many unsuccessful login attempts within what length window (in minutes), and lock out for what duration. Alternatively, an option to ‘Unlock manually’ is also provided, if preferred. Note that the manual unlocking of a user account must be performed from the CLI or platform API since there is no WebUI support for this currently.

In the next article in this series, we will turn our focus to the configuration and management of the user account lockout functionality.

Auditing plays a critical role in identifying potential sources of data loss, fraud, inappropriate permissions, unauthorized access attempts, and other anomalous behaviors that indicate operational or security risk. Its value increases significantly when access events can be correlated with specific user identities.

To support strong data‑security practices, OneFS implements comprehensive ‘chain‑of‑custody’ auditing by recording defined activity across the cluster. This includes OneFS configuration changes as well as client operations over NFS, SMB, S3, and HDFS.

OneFS 9.13 introduces the auditing of NFS mount‑denial events, enabling organizations to easily detect unauthorized access attempts and meet corporate and Federal auditing and intrusion‑detection requirements. This new NFS functionality complements the SMB access‑denial auditing introduced in OneFS 9.5, allowing administrators to enable protocol auditing, configure audit zones, and integrate intrusion‑detection systems that analyze audit logs for suspicious behavior. Although the lack of logging  does not permit unauthorized access, it does allow such attempts to go unnoticed, which violates auditing guarantees required for certain compliance standards. All resulting events can be reviewed using the isi_audit_viewer tool.

When an NFS client issues a mount request, the request is processed by the NFS protocol head on the PowerScale cluster.

Successful mount operations return a success response to the client. When a mount request is denied, the protocol head explicitly invokes the Audit Filter APIs, which generate a share-access-check audit event. SMB and NFS share this same event type, although each protocol populates different subsets of fields. NFSv3 audit entries include the full path requested by the client, whereas NFSv4 may contain only a partial path due to the protocol’s directory traversal design. These events are visible only through isi_audit_viewer and are not exported via syslog or CEE.

A new ‘protocol’ field has been added to the ‘share-access-check’ event so that administrators can differentiate between NFS (including NFSv3 and NFSv4.x) and SMB access‑denial events. For example:

[3: Wed Feb  4 06:53:12 2026] {"id":"f1c21718-2b0f-11f0-8905-005056a0607c","timestamp":1746600792901821,"payloadType":"c411a642-c139-4c7a-be58-93680bc20b41","payload":{"protocol":"NFS","zoneID":1,"zoneName":"System","eventType":"create","detailType":"share-access-check","isDirectory":true,"desiredAccess":0,"clientIPAddr":"10.20.30.51","createDispo":0,"userSID":"S-1-22-1-0","userID":0,"userName":"","Domain":"","shareName":"\/ifs\/nfs_1","partialPath":"","ntStatus":3221225506}}

In the above example, the following fields and corresponding values are logged:

Per the above, the above failed mount request for export ‘/ifs/nfs_1’ came from the ‘root’ user:

# isi auth mapping view UID:0 –zone system

Name: root

On-disk: UID:0

Unix uid: 0

Unix gid: -

SMB: S-1-22-1-0

The following procedure can be used to configure and manage NFS mount‑failure auditing in OneFS 9.13 and later:

1. First, the NFS services must be enabled:

# isi services nfs enable

# isi nfs settings global modify --nfsv3-enabled TRUE

# isi nfs settings global modify --nfsv4-enabled TRUE

Or from the WebUI:

2. Protocol auditing must then be activated and associated with the appropriate access zones:

# isi audit setting global modify --protocol-auditing-enabled TRUE

# isi audit setting global modify --audited-zones <zone name>

# isi audit settings modify --zone <zone name> --add-audit-failure share_access_check

Or from the WebUI:

3. An NFS export can then be created. For example:

# mkdir /ifs/nfs_1

# isi nfs exports create /ifs/nfs_1 --clients 10.20.30.51

Or from the WebUI:

4. In this example, only the client at 10.20.30.51 is allowed to mount the export. If a client outside the allowed list attempts to mount the directory, the request fails on the client side. For instance:

# mkdir -p /mnt/tst/nfs_1

# mount.nfs 10.20.30.252:/ifs/nfs_1 /mnt/tst/nfs_1 -n -o nfsvers=3

# mount.nfs: access denied by server while mounting 10.20.30.252:/ifs/nfs_1

Or for NFSv4:

# mount.nfs 10.20.30.252:/ifs/nfs_1 /mnt/tst/nfs_1 -n -o nfsvers=4

# mount.nfs: mounting 10.20.30.252:/ifs/nfs_1 failed, reason given by server: No such file or directory

5. The corresponding audit entries can be viewed with:

# isi_audit_viewer -t protocol -v

Example output includes records such as:

[4: Wed Feb  4 06:53:29 2026] {"id":"fba69477-2b0f-11f0-8905-005056a0607c","timestamp":1746600809498757,"payloadType":"c411a642-c139-4c7a-be58-93680bc20b41","payload":{"protocol":"NFS4","zoneID":1,"zoneName":"System","eventType":"create","detailType":"share-access-check","isDirectory":true,"desiredAccess":0,"clientIPAddr":"10.20.30.51","createDispo":0,"userSID":"S-1-22-1-65534","userID":65534,"userName":"","Domain":"","shareName":"ifs","partialPath":"","ntStatus":3221225506}}

Note that there is no WebUI equivalent of the CLI-based ‘isi_audit_viewer’ utility.

Because of protocol differences, NFSv3 records contain the full mount path, while NFSv4 records may display only the first directory component where permission checking fails. In some cases, mount attempts do not generate server‑side audit entries at all. This occurs when the client IP is permitted but the user account is not: Linux NFS clients use an ‘ACCESS’ RPC to determine permissible operations on each path component. If ‘ACCESS’ returns insufficient permission, the client fails the mount without sending a ‘LOOKUP’ request. The server therefore sees only a successful ‘ACCESS’ operation and logs no audit event.

This release adds protocol identification to the share-access-check event. Prior to OneFS 9.13, only SMB access denials were audit logged, and without the ‘protocol’ information field. After upgrading, both SMB and NFS access‑denial events now include the new ‘protocol’ field.

Enabling auditing introduces general system overhead. However, the NFS mount‑denial auditing feature introduces no additional cost because it logs only unsuccessful mount attempts.

High-performance PowerScale workloads just gained a substantial new advantage. The all-flash F910 platform, in combination with the new OneFS 9.13 release, now supports next generation 400GbE networking, enabling faster data movement and smoother scalability. Whether powering AI pipelines or high-throughput analytics, 400GbE provides the headroom a high performance cluster needs to grow.

Native support for 400GbE front-end and/or backend networking on the F910, helps deliver next-generation bandwidth for performance-intensive workloads such as AI/ML pipelines, HPC, and high-throughput analytics.

This capability enables data movement and cluster expansion without architectural redesign, leveraging an existing NVIDIA SN5600 switch fabric if needed. The 400GbE implementation supports jumbo frames with RDMA over Converged Ethernet (RoCEv2) for low-latency data transfers, MTU sizes up to 9,000 bytes, and full compatibility with OneFS 9.13 or later releases using Dell-approved QSFP-DD optical modules. Clusters can scale up to 128 nodes while maintaining deterministic performance across Ethernet subnets.

With OneFS 9.13 400Gb Ethernet is supported for the F910 platform using the NVIDIA CX-8 PCIe gen6 network interface controller (NIC).

Under the hood, the 400GbE LNI type and the aggregate type have been added to OneFS, where it is registered as an ‘MCE 0123’ NIC, and works just as any other front-end or back-end NIC does. Additionally, the same driver is used for the CX-8 as the earlier generation of the NVIDIA CX cards, albeit with the higher bandwidth, and reported as ‘400gige’. For example:

# isi network interface list

LNN  Name      Status     VLAN ID  Owners                      Owner Type  IP Addresses

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

1    400gige-1 Up         -        groupnet0.subnet1.pool0     Static      10.20.30.51

1    400gige-2 Up         -        -                           -           -

1    mgmt-1    Up         -        groupnet0.subnet0.pool0     -           172.1.1.51

1    mgmt-2    No Carrier -        -                           -           -

2    400gige-1 Up         -        groupnet0.subnet1.pool0     Static      10.20.30.52

2    40gige-2  Up         -        -                           -           -

2    mgmt-1    Up         -        groupnet0.subnet0.pool0     -           172.1.1.52

2    mgmt-2    No Carrier -        -                           -           -

3    400gige-1 Up         -        groupnet0.subnet1.pool0     Static      10.20.30.53

3    400gige-2 Up         -        -                           -           -

3    mgmt-1    Up         -        groupnet0.subnet0.pool0     -           172.1.1.53

3    mgmt-2    No Carrier -        -                           -           -

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

Total: 12

Note that, unlike the 200GbE ConnectX‑6 adapter—which supports dual‑personality operation for either Ethernet or InfiniBand on the F-series nodes—the new 400Gbps ConnectX‑8 NIC is currently Ethernet‑only for PowerScale.

While 400GbE support in OneFS 9.13 is limited to the PowerScale F910 platform at launch, support for the F710 nodes and the PA110 accelerator is planned for an upcoming release.

This new NIC family is functionally similar to previous generations, with the primary difference being the increased line rate. It is designed for high‑performance workloads. The NVIDIA Spectrum‑4 SN5600 switch is required for the back‑end fabric, which currently limits cluster scalability to 128 nodes due to the absence of leaf‑spine support.

Support for Dell Ethernet switches will be introduced in a future release, but is not part of the current offering. Additionally, these new 400 GbE NICs cannot interoperate with 100GbE switches such as the Dell S5232, Z9100, or Z9264 series, as the technological differences between 100Gb and 400Gb Ethernet generations are too great to maintain compatibility. In OneFS, the adapters appear like any other NIC, identified simply as 400GbE interfaces.

Deploying 400GbE networking requires an F910 node pool running OneFS 9.13, along with compatible transceivers, cabling, and an NVIDIA Spectrum‑4 SN5600 switch.

Installation of 400GbE networking requires an F910 node pool running OneFS 9.13, plus transceivers, cables, and an NVIDIA Spectrum-4 5600 switch:

Additionally, the F910 nodes need to be running the latest node firmware package (NFP), as the iDRAC needs to support the card properly.

The current PowerScale 400GbE solution continues to use standard multimode optical modules, including the larger twin‑port module for the switch and the smaller QSFP‑112 SR4 module for the network adapter.

The Dell transceiver components are equivalent to the NVIDIA parts, as they are manufactured to the same specifications and differ only in part number.

With the 400 GbE generation, active optical cables (AOCs) are no longer supported. The increasing size and mechanical mass of the optical modules make AOCs unreliable and prone to damage at these speeds, so the architecture shifts fully to discrete optical transceivers and fiber cabling.

A significant consideration for new 400GbE PowerScale deployments is the transition to MPO‑12 APC (Angled Polish Connector) cabling. These connectors are identifiable by a green release sleeve, in contrast to the blue sleeve used on traditional UPC variants. For example:

APC cabling provides improved signal integrity; however, APC and UPC connectors are mechanically compatible.

Note that using a UPC cable in a 400GbE port will result in degraded signal quality or link instability. When installing 400GbE networking, verify that APC‑type MPO‑12 cables are used throughout a PowerScale F910 cluster’s 400Gb Ethernet network.

As mentioned previously, the NIC used in the F910 nodes for 400GbE connectivity is NVIDIA’s ConnectX‑8 PCIe Gen6 adapter with dual QSFP‑112 ports in a standard half‑height, half‑length form factor.

Note that this NIC’s power consumption exceeds 50 Watts, which leads the PowerScale F910 nodes to operate their cooling fans at high speed to manage thermal output. So additional fan noise from these 400GbE F910 nodes, as compared to their 100GbE and 200GbE variants, is not indicative of an issue.

Also note that the onboard hardware cryptographic engine in the CX-8 NIC is enabled by default, although it is not currently utilized by OneFS. However, this may be a relevant consideration for certain regulatory compliance or export‑control scenarios.

Network switching for 400GbE uses the NVIDIA Spectrum-4 SN5600 switch. As mentioned previously, active optical cables (AOCs) are not available at this speed class. However, a 3‑meter direct-attach copper cable (DAC) is qualified for in‑rack connections. For front‑end connectivity, multimode optical transceivers remain the recommended option, consistent with prior generations.

Due to the thermal characteristics of 400GbE optics and NICs, systems should be expected to operate fans at maximum speed under typical workloads.

Regarding compatibility with lower speed Ethernet connectivity, the F910’s 400GbE NIC does support 200GbE optics and cabling, and will happily down‑negotiate to 200GbE. However, it is unable to down‑negotiate to 100GbE.