# Review TrueNAS SMB snapshot access at the dataset boundary > TrueNAS 25.10 nonlegacy SMB shares do not offer per-share shadow-copy disabling; review the shared dataset’s snapshot-directory setting and intended client access. - Canonical URL: https://update.dsesecurity.com/updates/review-truenas-smb-snapshot-access-at-the-dataset-boundary/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:10:03+00:00 - Modified: 2026-10-29T00:10:35+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know TrueNAS 25.10 nonlegacy SMB shares do not offer per-share shadow-copy disabling; review the shared dataset’s snapshot-directory setting and intended client access. ## Potentially affected TrueNAS 25.10 documented SMB shadow-copy behavior, with nonlegacy and legacy shares distinguished before changing dataset settings. ## DSE recommendation DSE recommends an explicit client snapshot-visibility decision for each shared dataset before changing its snapshot-directory setting. ## Article Bottom line: Choose whether SMB clients should see the dataset’s snapshots before looking for a share-level switch. Record whether the share is legacy and keep client visibility separate from the administrator’s snapshot-retention decision. ## Source fact: what the authority says The [TrueNAS SMB shadow-copy guide](https://www.truenas.com/docs/scale/25.10/scaletutorials/shares/smb/addsmbshadowcopies/) says ZFS snapshots underlying an SMB share are presented to clients through shadow copies or the hidden snapshot directory when it lies within the share path. TrueNAS 25.10 and later does not support per-share disabling of shadow copies on nonlegacy shares. For complete disabling of shadow-copy and direct snapshot access, the guide directs disabling the shared dataset’s snapshot directory; Samba then turns off shadow copies. It says SMB clients cannot delete shadow copies; administrators remove the snapshots through TrueNAS. ## What the source does not establish This article addresses the versioned client-visibility setting, not an organization’s retention rule or proof of authorized access to every snapshot. The guide has a separate legacy-share branch. DSE does not apply the nonlegacy decision until the actual share type and dataset have been identified. ## Applicability questions - Which dataset underlies the share path, and which snapshots are relevant to the requirement? - Is the share nonlegacy or in the documented legacy branch? - Should the intended client population be able to retrieve earlier file versions? - Who owns the visibility decision and the separate snapshot-retention policy? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends a dataset-to-share worksheet before any visibility change. Record the actual path, share type and intended client use. Have the data owner decide whether previous-version access is required, restricted or outside the approved workflow. Avoid inferring that decision solely from the presence or absence of a checkbox in a remembered interface. Use a proposed test dataset with a harmless file and two clearly identified versions. Write the desired client observations before configuring the test. Keep the administrator’s snapshot inventory beside the client-access requirement, but do not delete recovery points merely to hide them from a client. Resolve an unclear dataset mapping before changing a production setting. Review the documented branch for the installed release and intended share type. If a visibility change is warranted, limit the pilot to the agreed test dataset and preserve the prior configuration. Coordinate with users who rely on previous versions, then assess the actual client paths rather than accepting only a saved server-side setting as the result. Include a client-facing previous-version path and any approved direct snapshot path in the proposed checklist. State which identity performs each request. Keep an inaccessible or unexpected path as a result to investigate rather than silently changing the test user. ## Verification and evidence Proposed verification: from an approved representative SMB client, inspect the earlier-version view and any in-scope direct snapshot path before and after the pilot. Record the user context, requested version and observed access. Compare the result with the owner’s written visibility requirement without exposing sensitive historical file contents in a shared report. Verify the administrator’s intended snapshot inventory separately and restore the agreed test state. Retain the share type, dataset path, version, setting and dated client observations. Reopen the assessment after a share migration or release change that alters the applicable branch. Keep retention acceptance and client-visibility acceptance as separate entries. ## Official references - [TrueNAS — Using SMB Shadow Copy](https://www.truenas.com/docs/scale/25.10/scaletutorials/shares/smb/addsmbshadowcopies/) — official product documentation; confirm the installed release and configuration. Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: TrueNAS — Using SMB Shadow Copy - Authority: www.truenas.com - URL: https://www.truenas.com/docs/scale/25.10/scaletutorials/shares/smb/addsmbshadowcopies/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Review TrueNAS SMB snapshot access at the dataset boundary,” DSE Security, https://update.dsesecurity.com/updates/review-truenas-smb-snapshot-access-at-the-dataset-boundary/ 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.