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:
| Field | Value |
| 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 |
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:
- 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:
- 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:
- 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:
- 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
- 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.
| Upgrade State | Description |
| Before upgrading to OneFS 9.13 | Shared-access-check support for SMB, without protocol field information. |
| Upon upgrade to OneFS 9.13 | Shared-access-check support for both SMB & NFS, with protocol field information. |
| Upon downgrade from OneFS 9.13 | Events logged post upgrade persist and are viewable using earlier version’s isi-audit-viewer. |
Enabling auditing introduces general system overhead. However, the NFS mount‑denial auditing feature introduces no additional cost because it logs only unsuccessful mount attempts.