Do not touch the .zfs directory.
The .zfs directory can be used by the previous versions (shadow copies) functionality:
http://doc.freenas.org/11/sharing.html#configuring-shadow-copies
I am appreciative of the attempt to help, but I can't agree with you either as to safety, or alternatives:
- This just cannot be technically correct as it's not required for data integrity/safety.
.zfs is a container for mountpoints, the mounted objects are immutably read-only, ZFS doesn't need or have write permissions on the folder, at the absolute worst, care might be needed so that permissions don't restrict system processes reading/traversing the dir, but ACLs that only allow/deny ordinary user login accounts just aren't at all likely to be an issue, much less a severe issue.
- Previous Versions/shadow_copy2 is not a good substitute for the functionality. It simply cannot find a file across uncertain locations or by searching on properties or regex name, rather than an exact single specific path. Wrong tool for all but simplest use-case. File search = right tool. Works in CLI, so harmless. Try over Samba = some unexplained error.
- There are valid cases where it's useful to allow some users to browse/search broadly across snapshots, but prohibit others. The first of these follows from #2, the second follows from the fact that whenever some users might find a given access useful, it's quite possible there are other users who shouldn't have it.
First, there's absolutely no technical reason why these files cannot also be accessed by ordinary browsing in Samba,
given that I can do it via the CLI (requires read/traverse only). It would be very helpful to be able to do it via Samba and not have to SSH in and drop into CLI for the task. So asking why a directory with world-permissions "r-x" is traversable in CLI but not in Samba (even with "wide links=yes" and veto files empty) seems completely reasonable.
There is really no obvious technical reason why one "shouldn't touch" .zfs to the extent of placing user/group ACLs on it, other than "most users shouldn't do things at this level".
/.zfs/ doesn't have
any write access in classic permissions. So the absolute worst that could happen is that some part of the system couldn't read/traverse them, which seems unlikely at best and is clearly trivially fixed/reversed at worst (if an ACL is capable of blocking something then clearly removing the ACL or granting an ACL permission is capable of restoring it to normality), but the basic concern seems unlikely. The snaps themselves are immutable-read-only so nothing done to a snapshot's mountpoint's grandparent folder will affect them. If there is some specific core functionality which would break if ACLs affecting a GUI-defined user - but not blocking system accounts - were set on .zfs, I'd be curious what it is.
Your last comment is more about tool suitability. "Previous Versions" is an extremely poor substitute. It works well,
if you want a specific version of the file/folder with a specific path. It simply cannot do the job at all,
if you need to do a search - especially a complex search. (For example, when one doesn't know where the desired previous version is, and perhaps there are multiple possible copies in different locations to be collated, or one wishes to pull a selection of files that meet certain criteria). Some examples: suppose you're trying to find any historic version of IMG_12345.jpg/jpeg (can't be sure which!) which was >= 1280x1024 pixels, and with luck was left in some folder or in .recycle when the original was lost. Or suppose you want to know what versions of a file you've ever had (CLI equivalent:
find -x share -iregex 'pattern' -ls -exec sha1 {} \; > output.txt and then remove any duplicate hash entries). Suppose you even have an exact path (helpful!) but you want to find any old version of the file that had specific text such as a given sentence, expression or content-regex. Using a file search works for
all of those, using previous versions is a dead loss. On CLI I can search through all versions current and snapshot, in any location, if needed - then come back in the morning, and it's found. With >2m files on the NAS from over 30 years and >1k snapshots, I've had to do that for important old files more than once, since files and folders moved around a lot over the decades. I'd like this to be possible via Windows based file search software, which it could trivially do... if .zfs were not having traversal issues.
