NTFS rights: UNC vs mapped, Explorer vs command prompt RRS feed

  • Question

  • The short story: when a user has traverse-only rights to the root of a shared folder but full rights to a subfolder, the user cannot browse to the subfolder (correct) but can open the folder using the explicit path & change files in that subfolder (also both correct), whether via mapped drive or UNC path. However, the user cannot add/delete/copy files to or from that folder when mapped (incorrect), only via UNC path. On the other hand, the user can create/delete files in that same folder, accessed via mapped drive, using command prompt (inconsistent with above behavior).

    I already know I can add List folder contents at the root of the share to overcome this, but that is a right I am trying to avoid, and I am trying to understand the nuance of file security here.

    The long story:

    In order to keep curious users from simply browsing to certain key shared application folders on my Windows 2012 R2 server (same thing happens on 2008 R2, though), I do several things:

    1. Give Authenticated Users only these rights at the root of the drive hosting the share: Traverse folder / execute file, Read attributes, Read extended attributes, and Read permissions.
    2. Create the share as a hidden share. That is, share D:\Apps as Apps$. It is accessible as \\MyServer\Apps$.
    3. Give Everyone Change & Read shared (not NTFS) permissions. There is no need for Full Control, since I do not want users to be able to change the share permissions.
    4. Add group-based enhanced rights to specific application subfolders to which each group needs access. The additive rights are these: Modify, Read & execute, List folder contents, Read, and Write; in short, the basic rights required to create, modify, and delete folder contents.
    5. Map a drive to the Apps$ share for those user groups that require access to it. For example, my login script maps J: to \\MyServer\Apps$ by non-persistent "net use..." statement.
    6. Create a shortcut to the particular application and distribute that to user groups that require it.

    The reason for all of this is simple security: these application folders do not house files that users should ever interact with directly; the files are back-end data for which all interaction should be through a front-end application, for example, QuickBooks company files and MS Access front/back ends.

    All of this ensures that:
    1. No curious user or malware can even find the shared folder. The hidden share ($) takes care of that.
    2. No over-curious user with just enough knowledge to be aware of the default root administrative hidden shares (C$, D$, etc) but with too much time on his hands can browse the drive from the root up by navigating to \\MyServer\D$. Traverse-only at the root ensures this.
    3. No curious user can browse for the application folders downline from the share. This is important because the drive mapping exposes the share name to the user, and a user could just double-click the drive letter, then browse and copy/delete a back-end data file, accidentally or otherwise.

    This all works perfectly:

    1. Front end applications can appropriately add/remove data from the files based on the logged-on user's enhanced rights to the particular application folder.
    2. The application shortcuts I distribute point directly to the files in the downline folders, for example to J:\App1\MyApp.accdb (MS Access application), where J: is mapped by domain login script to \\MyServer\Apps$. The user can open the application and
    3. Access to the downline folders is arcane enough that anyone except a very knowlegeable user would ever know that browsing must begin, not at the root of the mapped drive or share, but with the specific folder. That is, an end user cannot browse to \\MyServer\Apps$ or the J: drive mapped there because the user has traverse-only rights there, but the user can get to \\MyServer\Apps$\App1 or J:\App1, where the user has read/write access, so long as the user enters the full path, bypassing the root of the share. I am pretty sure nobody has ever figured that out.
    4. In all of this, I have no problem browsing to and manageing all of this when logged on using a domain admin account.

    But there is one thing I do not understand: there is a difference in users' file-management rights, not affecting the ability to modify files, depending on whether they access the folder via UNC path or mapped drive. I have one user now that is a developer, and I created this shortcut for him: J:\HisAppsFolder so he can push applications into that folder. While he can open files there (e.g. open the Access file there and use it, including changes that modify the file), he cannot copy anything to or from the folder or make changes. On every attempt, he gets a "J: is not accessible" message accompanied by "Access is denied." However, if he instead goes to the same folder using path \\MyServer\Apps$\HisAppsFolder, he has (correctly) full access.

    In fact, he can open a text file already in that folder, make changes, and save the changes. This, and the fact that this all works when using UNC-based access to the same folder make it obvious that he has full rights to the folder. However, he cannot copy anything to or from the folder, even using XCopy. On the other hand, in a command prompt, he can go to J:, then cd to the folder and delete files there via command or create a file by doing something like this: dir > dir.txt.

    I have found that only after I add "List folder contents" access to the folder to which I map the drive (or above) can the user fully interact with the downline folder to which he has full rights. But I really do not want to expose the folder list to users at this level, and the user can already, without this right, list and modify files in the downline folder; he just cannot add, copy, or delete from the downline folder when connected via mapped drive. How is it that List folder contents must exist at the root of the share in order for a user to have the full benefit of full rights already set on downline folders? And how is it that the command prompt can completely bypass this restriction?

    After spending so much time working out all these details, it would be a shame to go away without understanding why this particular limitation exists, why it does not exist within command prompt, and how this all may affect me in the future. I have tested this on multiple domains and with server 2008R2 & 2012R2.

    Thursday, October 12, 2017 7:10 PM

All replies

  • Hi Brian D.Hart,

    Maybe you could still check the permission first. Since security in a Microsoft environment has two parts, the share (UNC) security and the NTFS security (from the folder Security tab).  The most restrictive rights will apply to all users when they access that folder. So when it comes to the problem about not add/delete/copy, we may still check permission first. You could still check in the effectiveness permission of the folder, so that we could know the real permission of the folder.

    In your scenario, you mentioned, the most strange problem is UNC path permission and Mapped driver permission.

    Find a familiar scenario, according the final state, map drive with IP address or UNC path(Server name) are different. Maybe you could also take a look.

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Friday, October 13, 2017 6:28 AM
  • I tested by mapping the same drive via IP address instead of UNC path, and the result is the same. Note that NTFS rights are correct whether connecting UNC path, mapped via DNS name, or mapped via IP address. This is proven by the fact that when I open command prompt and navigate there to the folder, I can create a file by doing something like this: dir > dir.txt. Then I can delete the file using del dir.txt.

    Also, I can open & modify existing files in the folder, even while connected via mapped drive. The only problem is that I cannot create/delete file or copy file into or from the folder while connected via mapped drive unless I grant List folder contents at the root of the share--not just to the folder in question or an intermediate folder with inheritance enabled.

    And the error is always, even when attempting to copy to/from the subfolder, that the drive letter is unavailable. But, again, this error does not occur when I actually navigate to the folder by its UNC path instead of using the mapped drive.

    I just proved this by doing this, using drive J: mapped to \\MyServer\Apps$ where user has full share rights, traverse-only on MyServer to D: & D:\Apps (the folder shared as Apps$), but full rights to MyServer D:\Apps\App1.

    1. Open J:\App1 in Windows Explorer. Attempt to drag and drop file from desktop to J:\App1 by drag-and-drop or by Ctrl-C on original, Ctrl-V inside the folder. Message says J: drive is invalid.
    2. Right-click inside folder, click New → Text File. Same failure message.
    3. Open command prompt (Window-R, then cmd)
    4. Enter J:, then cd app1
    5. Dir > dir.txt creates file dir.txt inside J:\App1 (Attempt to do this at root of J: correctly results in Access denied)
    6. Dir again shows dir.txt.
    7. xcopy dir.txt C:\Users\[UserName]\Desktop fails: File not found, 0 files copied
    8. del dir.txt deletes the file.

    That is, I can navigate to the subfolder of the mapped drive and create and delete files via command prompt, but not via Windows Explorer.  It is as though Windows Explorer cannot get past the rights at the root folder of the mapped drive when trying to copy to/from the subfolder--but can when opening/modifying a file in that folder, and command prompt, while it (correctly) will disallow file-creation at root of mapped drive, does (also correctly) allow file-creation/deletion in the subfolder. And the issue does affect xcopy to the folder, even when run from command prompt.

    Friday, October 13, 2017 6:55 AM
  • Hi Brian,

    Thanks for your feedback.

    May I ask does the problem only happen to this share "App"? If possible, could please create a new test folder to do a check?

    And when copying files, try robocopy to do a test?

    It is also appreciated that the other members in our forum can share their experience with us about this scenario.

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Monday, October 16, 2017 1:55 AM
  • Sorry. I already did already test exactly the same thing creating a completely new share, and the behavior is exactly the same. In fact, as in my original post, I already tried this on a 2012 R2 server and a 2008 R2 server, all the same behavior.

    I have not tried robocopy, since I already have a workaround for the end user--and my goal here is not to find which collection of applications will work and which will not, only to figure out the difference. That is, I do not want to have to write a program for the user to use for copying his files to the folder, so I gave him a shortcut that uses the UNC path for copying files, even though the actual files will be accessed via mapped drive by other users.

    But the underlying anomaly remains: things function differently, despite identical NTFS and share permissions, depending on whether the user access the files downline from a share via UNC or via mapped drive.

    As noted, this is something to do with the file copy/delete functionality only, and only when using the drive mapped to the root of the share, or at least to a level in the shared to which the user has traverse-only rights. The user has full NTFS rights to the subfolder, and this is proven by the fact that the user can copy files to the folder when opening it as a UNC path but not as mapped drive.

     Here is how you should be able to duplicate:

    1. Create folder "Test" on any domain-member server.
    2. Ensure "Everyone" group has either no rights, or at least only these rights, to "Test" folder: Traverse folder / execute file, Read attributes, Read extended attributes, and Read permissions
    3. Assign Authenticated Users these rights to the "Test" folder: Traverse folder / execute file, Read attributes, Read extended attributes, and Read permissions
    4. Create a subfolder like this: "Test\SubTest"
    5. Assign Authenticated Users full rights to the "SubTest" folder only (not the "Test" parent)
    6. Share "Test" folder as "TestShare" (the name is not important; I use TestShare here only to differentiate it from the actual folder name "Test")
    7. Give Everyone share permissions Change and Read.
    8. From a workstation, log on as a member of Domain Users that is NOT in Domain Admins or any other group having elevated rights to the Test folder (or donwline) on the server housing the TestShare.
    9. Open Windows Explorer and paste this into address bar, using your own server name: \\[ServerName]\TestShare\SubTest. (Can also just do Window-R and paste that UNC path into run window, then press Enter).
    10. This should open [ServerName]\TestShare\SubTest.
    11. Copy a text file from the workstation (Copy/Paste or drag-and drop) to that folder. This should succeed.
    12. Now map any drive letter to \\[ServerName]\TestShare, either by net use or right-click Computer/Network & Map Network Drive.
    13. After the map completes, it will (correctly) generate an error indicating the driver letter is invalid. This is only because, once the drive is mapped, Windows Explorer then attempts to display the root, but the user has only the traverse-related rights above to the root. So ignore this error.
    14. Instead, open Windows Explorer and paste this into address bar, using the driver letter just assigned: \\[DriveLetter]\SubTest.
    15. This should open \\[DriveLetter]\SubTest, where you should see the first file you copied there previously.
      Now try copying another file from the local computer to that subfolder. It should fail saying that [DriverLetter is invalid].
    16. However, open the text file previously copied, make a change and save it, then re-open. You can see that you can change the file.

    But now do this: map any drive letter to \\[ServerName]\TestShare\SubTest, either by net use or right-click Computer/Network & Map Network Drive. This should succeed. You can now copy files to/from the same folder via mapped drive--as long as the root of the mapped drive is a folder having at least List Folder Contents.

    That is:

    1. You can copy to (or create in or delete from) the subfolder when accessing it via its UNC path, even when the user is invoking traverse-only rights at some higher level to get to the folder
    2. This also works if you map the drive directly to the subfolder having full rights, even though this also invokes traverse-only rights to get to the folder.
    3. This does not work if the mapped drive letter points to the traverse-only folder itself, even though all the same NTFS rights exist identically throughout all three scenarios and even though the user can open and edit files inside the subfolder when mapped this way.

    Monday, October 16, 2017 3:19 AM
  • Hi Brian D.Hart,

    For now, I still couldn't find more statement to describe this setting, maybe you could also report your finding in the server feedback.

    And also appreciated that the other members  to share more ideas.

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Monday, October 16, 2017 7:26 AM

  • 2. No over-curious user with just enough knowledge to be aware of the default root administrative hidden shares (C$, D$, etc) but with too much time on his hands can browse the drive from the root up by navigating to \\MyServer\D$. Traverse-only at the root ensures this.

    No, traverse-only has nothing to do with this.  The fact that your over-curious user is not an administrator on your server ensures that.  Admin shares are not available to users.
    Tuesday, March 20, 2018 3:54 PM
  • If you find the reason for this i hope it is posted here.  I am dealing with another UNC vs Mapped drive letter issue that i cannot find a solution for.  Even though, at this point, the only need for it is to keep all things equal as the UNC path works when linked to the database just as well as the mapped drive letter version, there is always a chance that it MIGHT create a problem one day if the link it creates exceed the 260 character Max_Path length which is actually possible.  If the linked path were to use the expected mapped drive letter, it shortens the path by about 15 characters. 

    This has something to do with the way internal windows components always show the UNC path and never display the mapped drive letter path.  Example  Searching for a file on a mapped drive ends up showing the UNC path to all files found.  But simply going to the location and checking properties for the same file it is displayed as the mapped drive letter.  

    The problems are occurring when a User decides to locate a file by suing Search rather than by scrolling to it.  The resulting LINK posted to the company database record is done with the full UNC path instead of the much shorter version using the mapped drive letter.

    Monday, August 20, 2018 7:39 PM