Month: March 2026

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.