Tag Archives: permissions

Powershell, ACLs, and DFS-N

I’m working on some storage issues with our file services, and DFS Namespace services may the the best solution. But I will need to be able to keep the permissions on the DFS folders with targets in sync with the permissions on the target folders. I’m hoping that the new DFS-N PowerShell commands will facilitate this process. However, on my Server 2012 test system, I can’t get the help content to download for the DFSN-related cmdlets.

I did find this gem in the PowerShell Tips of the Week archive:

Windows PowerShell Tip: Working With Security Descriptors

Good stuff.

List folder contents – XP vs. Vista

Yesterday, a client called me complaining that, after installing Vista SP2, she couldn’t access a folder on a file share. She could access that same folder from her XP workstation, logged in with the same account.

I paid a service call (across the parking lot; any excuse to get up and walk outside 🙂 ), and after some poking around confirmed her claim. We did determine that she might not have attempted to access that folder from her new Vista system before.

So I started digging deeper. The folder granted her (via a group)  the “List Folder/Read data” permission. So I created a test folder and granted an analogous group this specific permission to the folder. This is displayed in the output of icacls thas “(S,RD)”.

C:>icacls s:citZTest
s:citZTest CAMPUSETS-FileServices-Browse:(S,RD)

This permission alone allows Windows XP workstations to browse the folder, but Windows Vista or later give an “Access in denied” error.

When creating a “browse” permission for a single folder, I start by granting the “List Folder Contents” standard permission, which assigns the following permissions to the folder and subfolders (not to files):

  • Traverse folder/execute file
  • List folder/read data
  • Read attributes
  • Read extended attributes
  • Read permissions

With icacls, this permission looks like this:

C:>icacls s:citZTest
s:citZTest BUILTINAdministrators:(OI)(CI)(F)

The (CI) indicates “Container inherit,” which means that permission (ACE) will be inherited by subfolders. Now I open the advenced security dialog, and edit the ACE to change the “Apply to” control to “This folder only.” Now the browse permission applies only to the particular folder. In icacls, it looks like this:

C:>icacls s:citZTest
s:citZTest BUILTINAdministrators:(OI)(CI)(F)

I changed the permissions on the client’s folder, and her access was restored.

See also:

Tuesday – March 24

Home directory permissions issues.

Found: How to display the security permissions of a file from the filer which mentions the fsecurity command. Also found the white paper Bulk Security Quick Start Guide. Information about the Security Descriptor Definition Language SDDL at MSDN. From a comment on that page, I found Mark Minasi’s newsletter describing the SDDL syntax.

After poking at a few things with SubInACL.exe, I used the secedit utility from NetApp to create a security job file.

I created a new file, added a location”/vol/testvol”, then added the BUILTINAdministrator user with Full Control. This generated a file containing the following:


The instruction are specific that you can’t remove the “Everyone” ACE, which is exactly what I wanted to do. So I edited the generated text file to remove that ACE, resulting in the following:


The command fsecurity apply /vol/path/to/file appears to have corrected the permissions just fine. I edited the file’s location to another affect volume and that worked as well.