Bound TrueNAS recursive ACL changes to the intended dataset tree

Bottom line: Name the complete affected path before applying a permission change recursively. Treat ACL stripping as a separate operation and preserve a recovery route for both the administrator and data owner.

Source fact: what the authority says

The TrueNAS 25.10 Permissions reference says recursive POSIX permission application includes directories, files and child datasets beneath the current dataset. In the ACL editor, Apply permissions recursively applies the screen’s settings or changes to child datasets under the displayed Dataset path. Strip ACL is available only for NFSv4 and removes ACLs from the dataset and its contained directories and files, potentially making data inaccessible until new permissions are created. For POSIX permissions, removing Execute from a parent dataset can cause loss of access to its path.

What the source does not establish

This article controls the scope of a permission operation, not a universal access policy. It does not prescribe stripping ACLs to fix a share problem or establish that a saved edit grants the intended application access.

Applicability questions

• Which exact dataset and descendant population should the change affect?
• What ACL type and existing permissions are present?
• Is the proposed action an edit, a recursive application or Strip ACL?
• Which parent-path access and recovery evidence must remain available?

DSE recommendation: controlled next steps

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

DSE recommends drawing the selected path and its child datasets before opening a broad permission change. Label descendants that should retain different permissions and have their owners review the intended scope. Reject a plan that treats the entire hierarchy as interchangeable merely because one directory needs repair.

Separate the requested permission edit from any proposal to strip the ACL. Preserve the existing configuration and arrange a recovery procedure appropriate to the data before approving a destructive operation. Keep the maintenance identity and its intended parent-path access visible throughout the change request.

Prepare a disposable hierarchy with a parent, ordinary file, subdirectory and child dataset. Give it deliberately different starting permissions so the test can reveal unintended scope. Write the intended final state for each object before applying any recursive option; do not use production access failures as the rehearsal.

Ask a second operator to inspect the selected dataset, ACL type and recursive option immediately before the approved action. Keep Strip ACL outside an ordinary edit unless its separate consequence is accepted. Avoid broad owner or group changes as an unexplained workaround for a missing path permission.

Verification and evidence

Proposed verification: compare every object in the disposable hierarchy with its written before-and-after permission plan. Record the recursive selection and actual descendant results, including any object that unexpectedly retained or lost access. Check the maintenance identity’s traversal of the parent path separately from access to the final test file.

Where a separate Strip ACL exercise is expressly approved, retain the initial ACL, selected scope and actual accessibility result before applying the approved replacement permissions. Have the owner review any mismatch before production work. Keep the evidence focused on change scope and recovery; effective private-share privacy remains a separate permission-layer assessment.

Official references

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

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