Test TrueNAS NFS access separately from an SMB share ACL

Bottom line: Do not close a multiprotocol access review with an SMB-only test. Write the intended NFS identity and authorization decision separately, even when both shares point to the same dataset.

Source fact: what the authority says

The TrueNAS multiprotocol guide describes sharing the same data through NFS and SMB. It explicitly warns that NFS shares do not respect SMB share ACLs and directs administrators to protect NFS exports through authentication and authorization. For its NFS and directory-service design, the guide recommends NFSv4 with Active Directory and Kerberos authentication. It also warns that NFS clients must preserve extended attributes when copying data, or SMB metadata can be discarded.

What the source does not establish

This article addresses the separate authorization decision for the versioned multiprotocol design. It does not resolve every filesystem identity mapping, qualify a client implementation or approve a Time Machine coexistence configuration from this guide’s version-specific notices.

Applicability questions

• Which dataset and export paths are shared through each protocol?
• What identities and authentication methods do the NFS clients actually use?
• Which users must be allowed or refused on each path?
• Do proposed client copy operations preserve the metadata required by the data owner?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a two-protocol access matrix with the same harmless files and separately identified client sessions. Put the SMB share ACL in its own column and the NFS authentication and authorization requirements in another. Do not use the successful SMB restriction as the evidence for the NFS row.

For a proposed shared engineering dataset, identify an allowed reader, an allowed writer and a user who must be refused. Ask both storage and directory-service owners to review the actual NFS identity path. Keep the directory membership and effective dataset permissions visible without assuming that matching account names establish matching identities.

Review the versioned NFSv4 and Kerberos design against the installed service configuration before a pilot. Treat any different authentication arrangement as a separate design decision requiring its own support. Avoid changing broad parent permissions merely to make one protocol’s test succeed.

Include a harmless metadata-bearing file in the proposed client-copy exercise if the workflow needs SMB metadata preservation. Define which properties matter and how the owner will inspect them. Preserve the initial share and dataset configuration before making an authorized change.

Verification and evidence

Proposed verification: open the approved dataset from separate SMB and NFS sessions using the named identities. Attempt the agreed read and change operations and the explicitly refused case. Record the protocol, effective identity, requested path and actual result for each row.

For the separately approved copy workflow, inspect the required file properties before and after the test. Retain unexpected permission or metadata results as findings instead of widening access to obtain a clean result. Accept the tested protocol and identity relationship only; leave other clients outside the conclusion.

Official references

• TrueNAS — Multiprotocol Shares — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.