Couldn’t the same be said in reverse? That also means they no longer match and
there’s a new scenario.
--
There are 10 kinds of people in the world...
those who understand binary and those who don't.
From: [email protected] [mailto:[email protected]] On
Behalf Of James Rankin
Sent: Thursday, July 2, 2015 7:27 AM
To: [email protected]
Subject: RE: [NTSysADM] permission/ share life lesson
Easy example would be if you change the NTFS permissions in future, you don’t
need to update the Share permissions.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Melvin Backus
Sent: 02 July 2015 12:08
To: [email protected]<mailto:[email protected]>
Subject: RE: [NTSysADM] permission/ share life lesson
Perhaps I’m missing something but I’m curious as to the benefit of changing the
NTFS permissions if they match the share permissions. It seems like more work
for no gain. Obviously you have greater granularity with file permissions, but
when they match I’m not seeing the point.
--
There are 10 kinds of people in the world...
those who understand binary and those who don't.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Michael B. Smith
Sent: Wednesday, July 1, 2015 11:14 PM
To: [email protected]<mailto:[email protected]>
Subject: RE: [NTSysADM] permission/ share life lesson
That’s completely a workable solution as well. I have simply a “habit” to match
share and NTFS permissions.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Kurt Buff
Sent: Wednesday, July 1, 2015 9:59 PM
To: ntsysadm
Subject: Re: [NTSysADM] permission/ share life lesson
While MBS says give them modify permissions on the share, it's been my
long-standing practice to give Full permissions to Everybody on the share, and
then use NTFS permissions underneath. MBS' approach surely works, but I just
find it easier to remember/manage if all shares are set the same way.
I also only use grant permissions - never deny.
For instance, assume DirectoryA1 should not be writeable for users, and not
should DirectoryB1, but DirectoryB1 should be read-write for users. In the
security dialog for each directory's properties, select Advanced to set the
type of inheritance (This folder only, vs. This folder, subfolders and files.)
Volume <<<< Grant Administrators Full (This folder, subfolders and files),
Users Read (This folder only)
|
DirectoryA1 <<<< Grant Users Read (This folder only) (Administrators
inherit Full from volume root)
|
DirectoryB1 <<<< Grant users Read (This folder, subfolders and files)
(Administrators inherit Full from volume root)
|
DirectoryB2 <<<< Grant Users Read-write (This folder, subfolders and
files) (Administrators inherit full from volume root)
This can be scripted with any number of tools, probably including PowerShell,
though I haven't done that yet, icacls and my old favorite fileacl.
Here's a writeup I did for our file server, for the Groups share (which is
basically the departmental share, where each department gets their own
subdirectory). It includes the fileacl syntax for the initial configuration of
a new departmental directory, along with guidelines on how IT will manage the
directory:
FILEACL "k:\groups\Example" /INHERIT /REPLACE /SUB
FILEACL "k:\groups\Example" /S "CORP\Domain Users":RX/U/U /S
"CORP\ExampleManagers":RAWaWeXDc/U /S "CORP\ExampleUsers":RX/U/U /REPLACE
FILEACL "k:\groups\Example\Private" /S "CORP\ExampleManagers":RWXD /S
"CORP\ExampleUsers":RWXD
FILEACL "k:\groups\Example\Public" /S "CORP\Domain Users":RX /S
"CORP\ExampleManagers":RWXD /S "CORP\ExampleUsers":RWXD
Directions for using this directory:
1) Only new directories can be created at the top level of this directory
(k:\groups\Example) - not new files - and those can only be created by
usGroupsExampleManagers or by IT.
2) If a new top-level directory is created, initial permissions on it will only
be for usHomeGroupsExampleManagers - any further permissions will need to be
added by IT.
3) The Private directory is restricted to members of the department. The Public
directory is read-write for members of the department, and read-only for the
rest of the org.
4) Permissions will only be placed on top-level directories within the
departmental directory. If permissions need to be modified further down the
directory tree, the subdirectory in question should be moved to another
top-level folder.
HTH,
Kurt
On Wed, Jul 1, 2015 at 5:56 PM, David McSpadden
<[email protected]<mailto:[email protected]>> wrote:
Having trouble figuring this.
I need to be able to write files to a
\\server\share\folder\folder\blah<file:///\\server\share\folder\folder\blah>.
That relates to volume:folder\share\folder\folder\blah
I have permission of volume:folder\share\folder\folder\ domain admin:full
everyone:read and share permission \\server\share<file:///\\server\share>
domain admin:full everyone:read.
Well come to find out everyone needs to be able to write to blah.
How do I give them that ability with giving them write on folder\folder as well?
And yes, please smack me around I should know this easily but it is escaping me
for some reason.
David McSpadden
Systems Administrator
Indiana Members Credit Union
P: 317.554.8190<tel:317.554.8190> | F: 317.554.8106<tel:317.554.8106>
[Description: imcu email icon]<http://imcu.com/> [Description: facebook email
icon] <https://www.facebook.com/IndianaMembersCU> [Description: twitter email
icon] <https://twitter.com/IndMembersCU>
[Description: email logo]
[mcp2]
This e-mail and any files transmitted with it are property of Indiana Members
Credit Union, are confidential, and are intended solely for the use of the
individual or entity to whom this e-mail is addressed. If you are not one of
the named recipient(s) or otherwise have reason to believe that you have
received this message in error, please notify the sender and delete this
message immediately from your computer. Any other use, retention,
dissemination, forwarding, printing, or copying of this email is strictly
prohibited.
Please consider the environment before printing this email.
