On Tue, Feb 8, 2011 at 9:37 AM, Tom Miller <[email protected]> wrote:
>> 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
>
> Thanks, Ben. What's the difference between P2 and P3?
Um... one clears the ACL, the other adds things to it.
Do you mean P3 and P4? Possibly nothing, if the only people who
should have read access to the folder are "staff". But your original
message didn't specify who should be able to read, so I wanted to
mention that.
> 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
That all looks good to me.
(I did forget to mention that somebody should have Full Control.)
> 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.
Are you a member of admins or any other group which was granted
Delete permission (or something that includes Delete, such as Full
Control)?
You shouldn't be able to delete files unless you have one of the
Delete permissions, either on the file, or the containing folder
("Delete Subfolders and Files").
What does CACLS (or XCACLS or ICACLS or FILEACL or ...) say if you
run it against one of the files you can delete? It should look
something like this:
>cacls ding
C:\permtest\foo\bar\ding BUILTIN\Administrators:F
DOMAIN\BSCOTT:R
DOMAIN\BSCOTT:(special access:)
SYNCHRONIZE
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_WRITE_EA
FILE_WRITE_ATTRIBUTES
Note how my user account doesn't have any delete permission.
Same for the folder itself:
>cacls bar
C:\permtest\foo\bar BUILTIN\Administrators:(OI)(CI)F
DOMAIN\BSCOTT:(special access:)
SYNCHRONIZE
FILE_WRITE_DATA
DOMAIN\BSCOTT:(OI)(CI)R
DOMAIN\BSCOTT:(OI)(CI)(IO)(special access:)
SYNCHRONIZE
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_WRITE_EA
FILE_WRITE_ATTRIBUTES
If I have FILE_DELETE_CHILD permission on the parent folder, or if I
have DELETE on the child object, I can delete the child object.
> 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?
What are the permissions on the parent folder? It's the containing
folder that controls rename and (sometimes) delete.
-- 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
