# Test TrueNAS NFS access separately from an SMB share ACL > The TrueNAS multiprotocol guide warns that NFS does not respect SMB share ACLs. Review NFS authentication and authorization independently when the same dataset is exposed through both protocols. - Canonical URL: https://update.dsesecurity.com/updates/test-truenas-nfs-access-separately-from-an-smb-share-acl/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T19:49:38+00:00 - Modified: 2026-10-29T19:50:08+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know The TrueNAS multiprotocol guide warns that NFS does not respect SMB share ACLs. Review NFS authentication and authorization independently when the same dataset is exposed through both protocols. ## Potentially affected TrueNAS 25.10 multiprotocol datasets exposed through both NFS and SMB, subject to the installed release. ## DSE recommendation Review each protocol’s authorization separately and test the intended identities against the same harmless dataset. ## Article 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](https://www.truenas.com/docs/scale/25.10/scaletutorials/shares/mixedmodeshares/) 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](https://www.truenas.com/docs/scale/25.10/scaletutorials/shares/mixedmodeshares/) — 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. ## Primary reference - Name: TrueNAS — Multiprotocol Shares - Authority: www.truenas.com - URL: https://www.truenas.com/docs/scale/25.10/scaletutorials/shares/mixedmodeshares/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Test TrueNAS NFS access separately from an SMB share ACL,” DSE Security, https://update.dsesecurity.com/updates/test-truenas-nfs-access-separately-from-an-smb-share-acl/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.