SMB Shares: Assign rights retrospectively (chronologically).

[saveZFS]

I've been running my VM storage on TrueNAS for a few months and have been busy creating snapshots.
I set up the SMB share much later. :(
If I now want to reset the data via Windows with 'Shadow Copy', then this is only possible from the creation of the SMB share.
Is there perhaps a way to add the rights for the SMB share in the older snapshots?

 

[anodos]

Snapshots are read-only.

 

[saveZFS]

Snapshots are read-only.

OK, so there is no way to use the Windows Shadow Copy with old snapshots, when the authorized user is later added to the SMB-Share?

Let's make a example:
2022-03-20: Set a new Dataset
2022-03-21: Set SMB permission for: User1 and User2
2022-03-22: Take Snapshot1
2022-03-23: Copy Snapshot1 to another folder using Windows Shadow Copy (using User1)
2022-03-24: Set SMB permission for: User3
2022-03-25: Copy Snapshot1 to another folder using Windows Shadow Copy (using User3)

So the last step (2022-03-25) won't work, but is there no way to fix it for windows shadow copy?

Sure, I can clone the dataset, share it in a new SMB-Share and then delete the clone.

 

[anodos]

You can make the user a member of a group that had access to the data at the time that the data was written.

The way shadow copies work is that the SMB client issues an FSCTL to get shadow copy data for a given path. The SMB server converts this FSCTL into a libzfs request to get a ZFS dataset handle for the dataset underlying the path and enumerate snapshots of that dataset. This info is used to generate the FSCTL response to the client (basically a list of timestamps for previous versions of the path). Then the client makes a request to open the path at a specific timestamp. This path with a timestamp is then converted into a path within a specific snapshot `.zfs/snapshot` directory and the operation performed against the aforementioned path. This data is read-only and cannot be altered (including the file's ACL).

 

[saveZFS]

You can make the user a member of a group that had access to the data at the time that the data was written.

Thank you for your great explanation!
So if I only used one user in the ACL like this, then now I can't enter a new user, because I have no group to add the user?

So it will be much better for the future to work with groups in ACL than with single or multiple users? ;)

 

[anodos]

Thank you for your great explanation!
So if I only used one user in the ACL like this, then now I can't enter a new user, because I have no group to add the user?

So it will be much better for the future to work with groups in ACL than with single or multiple users? ;)

Yes, in general it's best practice to manage access via groups (same applies in case of Windows).