



For the sake of simplicity, let’s also assume that NTFS permissions on all files are open to everyone (by the way, these are examples of “open shares,” and they are definitely not something that you, your security team, or your auditors want on your network-we’ll discuss open shares in a future post). Let’s say that the share permissions on shareA are set to everyone read, and the share permissions on shareC are set to everyone read + write. Let’s call our server, “foo,” and the share names for A and C, “shareA” and “shareC.” The arrows indicate that both A and C are set up as shares. It has three folders, A, B, and C, where B contains C and A contains B and C. Related to number 2, you can have multiple shares in the same hierarchy, or “nested shares.” Each share may have different permissions, so determining someone’s effective permissions can be confusing.Īs an example to illustrate the third issue, let’s say you have a simple folder tree, like the one shown below:.Unlike NTFS permissions, share permissions only apply when you are accessing files and folders via that share-local access and access via another share, for example, are not subject to the permissions set on the (first) share.Share permissions levels are full, write (change), and read-NTFS permissions offer many more options.So what’s the downside? Three problems associated with using only share permissions are: This approach goes against Microsoft’s recommendations, but it has one advantage: sharing permissions are applied more or less instantaneously, where NTFS permissions can take a long time to apply to all the files and folders in a big hierarchy. In one of our recent posts, What About Individual Users on ACL’s? I mentioned that some organizations have opted for using Windows share permissions instead of NTFS permissions for file shares.
