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.

Paired infrastructure paths converging on a stable recovered service.
DSE visual intelligenceContinuity & recoveryGuide · 3 min read
Executive summary

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.

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 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

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

Primary reference

Review the official source

TrueNAS — Using SMB Shadow Copy · Verified October 28, 2026

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE