Why does sharing a folder in Explorer grant full permission on the share to everyone?


A customer noticed that when you use Explorer to share a folder with a specific user, Explorer creates a file share with full permissions to everyone. "Why is this needed? Shouldn't it be created with permission only to the user that the folder is being shared to?"

Okay, first of all, we should note that there is not a security issue here, because even though the share grants everyone full permissions, the individual permissions on the files and folders are still respected. In order to get access to a file, you need to have access both to the share and to the file. Since you already set up the desired permissions on the file, the share permissions are redundant.

But doing it this way does make things easier for the user.

It reduces the number of elevation prompts, because elevation is required only the first time you share a folder. If you share a folder with multiple people, the second and subsequent sharing operations do not need to elevate because the share already exists with full permissions to everyone.

It reduces the complexity of the sharing operation. Adding or removing a shared file or folder does not require recalculating the ACLs on the share. It also means that the UI for showing what is shared doesn't need to perform an effective access calculation in order to determine what access level to show. It can operate purely on the file system permissions.

It also makes things easier to understand for the user. Users need to manage only file permissions and don't have to remember that they also have to combine that with the share permission. Otherwise you get into cases where you shared a file with Bob, and Bob can access it sometimes (when Bob is signed in locally) but not other times (when Bob is accessing the file remotely).

If you really want to deal with share-level permissions, you can use the advanced sharing UI. It's the simple sharing UI that uses the simple security model.

Comments (17)
  1. Karellen says:

    “Since you already set up the desired permissions on the file,”

    Did you? Or did think that you sharing a file with Bob would automatically give Bob read-access to the file, because you have read-access, and you’re the one sharing it with them? Is the user model “I am sharing this file.” or “I am telling a completely separate part of the system to share this file – and not even on my behalf, but on behalf of the system.”?

    Because if it’s the first, there will be a completely different set of assumptions about what the user is asking the computer to do. Ironically, while those assumptions that the user makes may be wrong, they’re probably not that different to what the advanced sharing UI does.

    “doing it this way does make things easier for the user.”

    Really? Setting up the correct file permissions ACLs is easier than saying “share this with Bob”?

    “It reduces the complexity of the sharing operation. Adding or removing a shared file or folder does not require recalculating the ACLs…”

    No user, not in a million years, will take this into consideration when trying to form a mental model of how sharing is likely to work.

    1. Damien says:

      It’s been a long time since I’ve seen the simple sharing UI. I suspect that it’s “you, by the actions you’ve taken in the simple sharing UI, have already indicated what file permissions should be applied, and these have been applied.”

      I.e. if you use the Simple sharing UI, you set things up as “Bob should have Read, Carol should have Read/Write, now go and apply these settings”

      1. Karellen says:

        “by the actions you’ve taken in the simple sharing UI, have already indicated what file permissions should be applied”

        Ah, that’s what I was missing. Sorry!

        From the original post, it sounded like you were expected to set up the file permissions yourself outside of the sharing UI, and having “already” done that, the simple sharing UI just created the share. i.e. simple sharing UI didn’t set up any fine-grained permissions at all, rather than setting them – but on the file instead of on the share.

        I’ll go put a bag on my head and sit in the corner now…

    2. Erik F says:

      Share-level permissions made sense when the underlying file system often didn’t have native permissions (i.e. FAT or HPFS), but when you have finer-grained permissions on the FS level it doesn’t make a whole lot of sense to monkey around with two sets of permissions IMO. Using both systems at the same time tends to induce headaches for me as I often forget about share permissions when diagnosing access issues (group memberships and deny permissions on files are the first things I look for.)

      1. AndyCadley says:

        One other case is to make a read-only share to a folder so you can be sure a remote copy/sync operation doesn’t actually get configured the wrong way around.

        1. Erik F says:

          Sure, that’s OK too: NFS has had that feature since forever for much the same reason. What drives me nuts is when admins start throwing read-only and read-write permissions on the same share along with file permissions (never mind deny rights!) If you’re going to make a share read-only, make it read-only for everyone: I once thought that overly-complicated permissions were a sign of being an expert until I had to try deciphering what I did six months after implementation.

      2. Joshua says:

        I use it for virus resistance.

  2. The MAZZTer says:

    Yup. I didn’t realize shares had separate permissions at first and got very confused as my folder permissions looked fine and could be accessed locally, but not remotely. ShareEnum is a useful tool for the Windows editions that don’t expose the share permission UI (I think I had to use it back in XP, probably not needed any more). It’s probably for the best simple sharing removes this complexity as most users will not need it, but I’m sure there are cases where more experienced users will want to lock down shares more remotely than local access normally allows.

    Another thing that is easy to confuse that got me: When you access a share on a Vista (and up) host, Administrators group permissions are NEVER applied (since with the introduction of UAC, that should require elevation, which can’t be granted remotely!). There is a registry key you can use to disable that and apply it again, which is useful in some cases, though it’s important to understand the security implications.

    1. Chris says:

      Forgive me for being technical, and correct me if I’m wrong, but I don’t think that it’s that the Administrator permissions are never applied; it’s that they’re never applied to local accounts. Domain accounts, I believe, will still have the Administrators alias/local group applied to their tokens. (The registry key in question that you mentioned hints at this; it’s called LocalAccountTokenFilterPolicy)

      1. Neil says:

        I’ve run into the opposite problem – you need to run ROBOCOPY as an Administrator to enable certain options even when you’re not accessing files on your machine.

        1. Chris says:

          Is that actually a permissions issue, or is that a limitation of robocopy? I wonder if Robocopy itself is detecting the presence of the Administrator token, and changing its behavior.

  3. Andrea D'Alessandro says:

    It should be interesting, Raymond, to know the history behind the decision of the Windows Developing Team in creating the share permissions mechanism, that everybody has always considered redundant.

  4. Neshram says:

    My grief has always come from clients, and co-workers, using the simple sharing UI in a corporate environment and (more importantly) thinking that they’re only changing the share permissions. They invariably end up changing the NTFS permissions and breaking some automated process because: “But, only Joe needs to access it through the share.”

  5. Note that if you allow Full Control on a share, you allow the remote user to be the owner of any file they create on the share. That means they can change the ACL on that file, even if they do not have Full Control at the file system level. As a result, users can circumvent the ACLs you have setup.

  6. cheong00 says:

    The nice thing regarding setting fine-tuned sharing permission on the shares is that, on fileserver that have large number of shares that normal users do not have access to, enabling ABE does reduce the number of support calls.

    https://blogs.technet.microsoft.com/hugofe/2010/06/21/windows-2008-access-based-enumeration-abe/

  7. xp.client says:

    I miss how TweakUI let you customize the default permissions for many things via its Access Control section. One of the tweaks I always did was Default Share Permissions. It worked up to Windows 7 x64 (the 64 bit version of TweakUI made by Neosmart). Had to do those tweaks on Windows 7, use SysInternals Procmon to observe the reg values and export them for use on MS Bob 10.

  8. MarcK4096 says:

    I’ve never met an end user that knew how to correctly set NTFS or file share permissions. And I’ve met some IT professionals that also didn’t understand them well.

Comments are closed.

Skip to main content