Thanks, Ben. What's the difference between P2 and P3? I kept the following to match my other shares: System, full control, this folder, subfolders and files Administrators (server local), same as above CO, full control, subfolders and files only Then added the group and Ben's recommended perms and folder options. So I can add files, and modify them. I can also delete them. I probably won't be able to get around that, but shadow copy can restore for me if needed (used it several times on this same folder). But I can still, with my test user, rename the folder and delete the folder. I don't want that. I guess I gave too many perms somewhere? Tom
>>> Ben Scott <[email protected]> 2/7/2011 5:47 PM >>> On Mon, Feb 7, 2011 at 4:42 PM, Tom Miller <[email protected]> wrote: > I need to modify the perms on a folder under a share. Staff need to have > the ability to create files only, modify them, but not delete them once they > are created, and not delete the subfolder itself. On the containing folder: P1. Block inheritance (uncheck "Inherit from parent") P2. Remove all directly applied permissions (start with an empty ACL) P3. Grant "Read & Execute" on "This folder, subfolders, and files" to staff P4. Grant "Read & Execute" on "This folder, subfolders, and files" to whoever else needs it P5. Grant "Create Files / Write Data" on "This folder only" to staff P6. Grant "Write" on "Subfolders and files" to staff Read & Execute = Traverse / Execute; List / Read Data; Read Attribs; Read Ext Attribs; Read Perms Write = Create Files / Write Data; Create Folders / Append Data; Write Attribs; Write Ext Attribs Notes: N1. "Delete" access is needed to rename files. No delete means no rename. N2. Some programs (such as MS Word and MS Access) expect to be able to delete files in the directory containing a file they can write to, and may malfunction in this scenario. N3. The ability to change existing contents of files means the user can still erase all data from the file and save that in place, which may be the same as "Delete" for practical purposes. > Good enough, but I can't get the deny correct. Avoid explict "Deny" permissions if at all possible. You're much better off blocking inheritance and then building up a set of granted permissions. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin Confidentiality Notice: This e-mail message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
