Ensure that NTFS rights function identically whether using UNC path or mapped drive to same location
I have been redirected here by recommendation of MSFT CSG in response to post on the Windows Server forum here: https://social.technet.microsoft.com/Forums/windowsserver/en-US/4d27b27b-5354-413f-8eeb-48ae9fb1e795/ntfs-rights-unc-vs-mapped-explorer-vs-command-prompt?forum=winserverfiles. Apparently, my question has exceeded the limits of "how do I do this?" and entered the realm of "why does Windows behave inconsistently?", which I call a bug.
The behavior below is the same for at least Server 2008 R2 & 2012 R2, both with Windows 7 workstation. I have not tested elsewhere.
User has only traverse & permissions NTFS rights at root of share but full share-level permissions. User has full access to a subfolder of that folder. I set traverse-only at the parent level because:
1. I do not want users to be able to browse to the parent folder, even if they know the share name. Instead, I provide explicit shortcuts to applications in downline folders where users have read/write access.
2. There there is no need to disable inheritance for downline folders. I can make all rights additive at those lower levels. Since the only NTFS rights to the parent folder (which will be the root of a share) are traverse/permissions rights, and these will be required by anyone also need read/write to downline folders. I can just add read or read/write NTFS rights to downline folders by group.
The user can edit/copy/create/delete files from that full-rights subfolder when accessing it via its UNC path; however, when mapping a drive to the parent folder where the user's rights are traverse/permissions only, the user can still edit files in that subfolder but not create, copy from/to or delete from the subfolder via Windows Explorer; the user gets a "[DriveLetter] invalid/inaccessible" message. However, the user can create and delete files from the subfolder via command prompt, so we know the issue is not NTFS rights, but apparently the fact that Windows denies rights to create/delete/move files to/from the subfolder based on the rights at the parent level.
Here is how 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 downline) on the server housing the TestShare.
1. 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).
2. This should open [ServerName]\TestShare\SubTest.
3. Copy a text file from the workstation (Copy/Paste or drag-and drop) to that folder. This should succeed.
4. Now map any drive letter to \\[ServerName]\TestShare, either by net use or right-click Computer/Network & Map Network Drive.
5. 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.
6. Instead, open Windows Explorer and paste this into address bar, using the driver letter just assigned: \\[DriveLetter]\SubTest.
7. This should open \\[DriveLetter]\SubTest, where you should see the first file you copied there previously.
8. Now try copying another file from the local computer to that subfolder. It should fail saying that [DriverLetter is invalid].
9. 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.
10.Open command prompt. Change to [DriveLetter], then dir to \SubTest. Enter dir > dri.txt. The text file is correctly created. Then del dir.txt. The text file is deleted. So the user retains full NTFS rights to the subfolder; it is only in the Windows Explorer environment that the user cannot copy to the subfolder when the parent is a drive letter instead of UNC path.
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 an upline folder having at least List Folder Contents.
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.
Do not limit create/delete/move access within Windows Explorer by parent folder rights when user has additive rights to the subfolder.