How to prevent users from deleting files from shares

[UtwigMU]

I was asked to prevent certain users from being able to delete files from network shares.

The reason for this is that user might have reason to maliciously delete files from corporate shares.

I found this:

answering this from the top of my head, but the basic rule of permissions is AVOID the DENY button. here is the permission you need to set for the User you want to allow create and read but not delete
Enable the Allow for the Following
Read & Execute
Read
Write
and Make sure MODIFY is unchecked for Allow and Deny leave it blank and you should be good.
good luck
Source(s):
http://www.windowsecurity.com/articl...rmissions.html

I tried this and user still has right to modify documents, so she could open them and mangle them and save them. Also she still can delete stuff created by her but not by others. Besides Office keeps temporary files which it wouldn't be able to delete, users would complain about temp files on shares.

I think this might potentially create more problems than it would solve.

I have a daily Windows Server backup that cannot be mangled by users, so I could just rely on that.


I also found another idea where you can create a script that seals or copies documents which haven't been modified for certain time.

How would you do it?

This is a small company with SBS 2011 and ~10 workstations, so no storage vaults, Cisco stuff...

[Jammrock]

Put all those users into a group. Add that group to the share permissions and give them Read access only.

NTFS gives users the least restrictive permissions. Shares gives users the most restrictive permissions. Thus adding the users/groups to NTFS won't change anything. Doing it at the share level will.

[UtwigMU]

Problem is the user needs to work on files also.

The case I think it is: If she's let go or in an argument she could delete files on purpose.

[Jammrock]

In this case you'll have to use special NTFS permissions. You'll have to play with it a bit, but same general idea.

Add the "CannotDelete" group with Modify permissions in NTFS.

Security tab, Advanced button. If you're Vista+/2008+ click "Change Permissions..."

Edit the "CannotDelete" group permissions.

Check Deny for "Delete subfolders and files". I don't think you need to Deny "Delete", but you'll have to play with it to be sure.

Deny permissions overrule everything. They could have Full Control in a dozen groups, but if Deny is set it overrides it all. Just be sure the test it thoroughly before applying to users.

[MultimediaMan]

"Shares" are an ugly word in a Windows Environment. Also an outmoded one. However, do you run Sharepoint? That would solve a LOT of your problems.

[UtwigMU]

Yeah I could sell them on sharepoint. They have it anyway since it comes with SBS.

[VJ]

The whole problem is that she must have permission to modify the files. So even if she has no rights to delete the file, she can still open it, remove the contents and save it again.
I don't know how to achieve it, but ideally you would want to create a duplicate of the file when she opens it.

At my previous work, we had all the files on a versioning system, as a result we had a full history of all the files (users could only upload as a new version, so all the old ones were still there).

[cjolley]

UtwigMU, I'm working on a similar problem at work.
In this case the auditors want me audited
We are too small a shop to have best practices separation of responsibilities.
Eventually this will be put on the share that holds our source code to provide an audit log.
(We do not have administrator on the share server itself)

We don't have anything to do this and the general MIS programmers say it is impossible.
Naturally, that is a challenge.

So I am learning C# (which I now LOVE because it fixes everything I hate about C++ ) and writing a solution myself.

So far it's going pretty well.
These are the parameters right now:
1, Must be run as Administrator on the machine that hosts the shares.
2, Writes the log to console so the output needs to be ">"ed to a log file
2b, Putting the log file in the path that is being monitored would be a really bad idea
3, Will refuse to monitor more than 4096 files (not enough stress testing to risk that)
4, It's only been tested on windows7 so far. (XPs Security Log might not function the same way, I don't know yet)
5, Only tracks successful creates, changes, deletes, and renames. Not unsuccessful attempts.

Not bad for three days in a new language, if I do say so myself.
Next stop: multithread the log writer.

If I get something pretty stable I'll let you know.

[UtwigMU]

You can always use a versioning system like VSS SVN, where all previous versions of file are kept and only administrative users have the right to delete it, though having users learn it is a bit steep.

Anyway her contract has not been prolonged and she has been put in interns group who only can access interns share where files can be put by other's. She also no longer has access to office. I saw it coming and it was her fault but still loosing a job in these times is very unfortunate.