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. 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. So what’s the downside? Three problems associated with using only share permissions are:
- Share permissions levels are full, write (change), and read—NTFS permissions offer many more options.
- 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.
- 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.
As an example to illustrate the third issue, let’s say you have a simple folder tree, like the one shown below:
Hate computers professionally? Try Cards Against IT.
It has three folders, A, B, and C, where B contains C and A contains B and C. The arrows indicate that both A and C are set up as shares. Let’s call our server, “foo,” and the share names for A and C, “shareA” and “shareC.”
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. 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).
When you access a share over the network, you typically either “map a drive,” or type an address into windows explorer. Either way, you’re accessing a share via what’s known as a UNC path, which looks like this:
\\[ServerName]\[Sharename]\[folders]\[files]
So, if you want to create or look at some files in folder C, you can access them in two ways:
- \\foo\shareC\
- \\foo\shareA\B\C\
Since the share permissions set on shareC are read + write, you’ll be able to read and write files in C if you access the files using the first path, but you’ll only be able to read files if you access them via the second path. These kinds of situations can result in lots of helpdesk calls, since users will get different access rights depending on how they got to a file or folder.
It gets more confusing when you start restricting the share permissions to groups, and even more confusing when you start using (as you should) NTFS permissions. One common security issue arises when an organization is unaware of these nested shares—it thinks its files are secure because the known shares are locked down, but someone has created a more permissive share somewhere deep in the hierarchy that has gone unnoticed.
Using an automated data governance solution like Varonis DatAdvantage can help organizations identify nested shares, open shares, and view effective permissions (share + NTFS permissions).
What you should do now
Below are three ways we can help you begin your journey to reducing data risk at your company:
- Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
- Download our free report and learn the risks associated with SaaS data exposure.
- Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.

David Gibson
David Gibson has more than 20 years of technology and marketing experience. He frequently speaks about cybersecurity and technology best practices at industry conferences, and has been quoted in The New York Times, USA Today, The Washington Post and numerous security news sources.