Protecting folders (and files) from being deleted...

[Koldov]

I have just been asked to create a folder for a staff member (Performance Management) on the server.

 

The thing is I had already created it a while ago...

 

On to the server I go and sure enough it is missing!

 

Anyway searching through the back-ups and it was there Friday 29th Oct and not there Monday 01st November.

 

I have set the permissions so only the user, the SLT and the line manager can access the folder - so I can only surmise one of those deleted it.

 

I don't have the kind of logging enabled on the server to tell me who did it, but short of doing this (which won't help me stop it being deleted in the first place) I wondered if there was any way (without resorting to deny permissions and I can't deny them rights to delete something if they need to) of stopping this happening?

 

I seem to remember we had a spate of this with the younger pupils deleting other users folders (shared log-in) and I put a file in each folder with permissions set to allow only the admin to do anything with it (set as the first file alphabetically it errors on that and appeared to leave the other files and the folder itself intact), but I can't remember exactly how I did it to multiple folders (and there are a lot)...

[djm968]

It's not really possible, if they have modify/write access which they need to work, then they will be able to delete or overwrite the files/folders. You could set read only permissions on the top level folder to protect that but you would have to set permissions on all sub-folders. The only option is to make sure shadow copies are enabled at least 3 times a day so you can get the folders back quickly. Also enable auditing on the folder so you can name and shame.

[Koldov]

Yeah, I thought as much thanks!

 

I'm still going for a best effort though... Just for testing I have this simple (CMD?) code I found a while ago to copy a file into multiple folders and wondered if any PowerShell wizards could rewrite it and amend it to set the permissions on the file to limit it to just the admin as well (as otherwise the file will inherit and I'll have to go into all the folders to edit manually).

 

for /D %a in ("E:\Staff$\Performance Management Staff Folders\*.*") do xcopy /y /d "E:\Staff$\Performance Management Staff Folders\FILE NAME GOES HERE" "%a\"

[jthompson]

You can do this by adding a deny permission to just that folder. This is just an example from my documentation, hence the old UI. A folder named 'Administration' in which a group named 'All Staff' have modify privileges, but on the folder itself, they are denied the Delete permission. They can do what they like to the folder contents, but the folder itself they won't be able to move, rename or delete.

[Guest ZFarnworth]

You can do this by adding a deny permission to just that folder. This is just an example from my documentation, hence the old UI. A folder named 'Administration' in which a group named 'All Staff' have modify privileges, but on the folder itself, they are denied the Delete permission. They can do what they like to the folder contents, but the folder itself they won't be able to move, rename or delete.

[ATTACH=CONFIG]63587[/ATTACH]

 

If you don’t mind me asking, but are you using server 2008 r2 as your file server?

[thimon]

Windows Server 2022 with 2008 r2 skin [emoji846]

[jthompson]

If you don’t mind me asking, but are you using server 2008 r2 as your file server?

 

Big fat nope! That image is just an old screenshot in my documentation about file share permissions.

[psydii]

You could also have a script that runs and checks the files comparing them to a list of files from the previous day. If any are missing it raises an alert so you can restore them from the shadow volume before anybody notices. Then you can go spelunking in the audit trail to find out who deleted them.

 

In my experience actual deletion of documents is very rare. more often than not an errant drag/drop has occurred and the files and folders are safe and well, just somewhere else. (This used to happen to us probably six-ten times a year. Moving to SharePoint and files on demand makes it more obvious to the user they have made an error that they can cancel out of)