2009-08-11 01:25 AM
a customers is asking to disable access to files or delete files in snapshots.
What I know, this is not possible at all.
Any expert expertise on this?
Disable snapdir is not an option.
Can we use fpolicy to change ACLs in snapshots?
2009-08-11 02:23 AM
are you looking for this:
options cifs.show_snapshot off
You cannot delete files from snapshots, snapshots are READ ONLY. You can only copy a file from a snapshot and then put it
where you want, provided you have got access to this.
I think setting the option above will sort you out.
Let us know how it goes.
2009-08-11 06:39 AM
That option will hide the ~snapshot directory, but it will still be available if people explicitly ask for it.
There is no way short of nosnapdir to eliminate access to snapshots..that's what nosnapdir is for. You can't change the permissions in a snapshot as that would defeat the purpose of the snapshot.
2009-08-12 12:53 AM
nosnapdir is a possible solution, but not for the customer.
He wants to be able to access snapshot directory for restores. Only a few files should be blocked/deleted.
I know this is a strange question.... but deep in my mind I hoped someone knows a better solution
2009-08-12 06:59 AM
Unfortunately, modifying or deleting files in a snapshot violate the whole point of the snapshot which is to have a unchangeable point-in-time copy of the volume.
But thinking a little outside the box, you could turn on nosnapdir, then instead of presenting snapshots for restores, you could spin off FlexClones which are read/write and therefore could be modified. It may be possible to write a script that spins off a clone, makes the modifications you want, then shares out the clone read-only. Restore would have to be done from the cloned volume instead of .snapshot, but the presented clone(s) could be based on the same snapshots (or a subset of them).
That may be reaching a bit and is, IMHO, a bit of an ugly kludge, but it might solve their specific problem.
2009-08-13 04:20 PM
Ditto basically....this is all I could come up with as well (you beat me to posting it ).
If you're going to that level though, disabling nosnapdir, grabbing the file, enabling nosnapdir may make as much (or more) sense.
2009-08-17 08:30 AM
This request came from their internal revision department.
They fixed it within the virus scanning engine.... If someone wants to access a "secret" file, which should not be there, they mark it as "dirty". So nobody can access it.
But thanks for the cool alternate answers here!