1

I have a function which grant the user permission to a folder.

$acl = Get-Acl $Path
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule('Users', 'FullControl', "ContainerInherit,ObjectInherit","None", 'Allow')
$acl.AddAccessRule($rule)
Set-Acl $Path $acl

It works fine with path like 

$Path = 'C:\Test\'
$Path = '\\$env:computername\e$'

But it doesn't work if

$Path = 'E:\'

'E:\' only works with 

 $acl = (Get-Item $FolderName).GetAccessControl('Access')

I don't quite get it since '\\computername\e$' and 'E:\' point to the same place. Does anyone have idea of what is the difference.

Liu
  • 970
  • 7
  • 19
  • Out of curiosity, are you trying to get an admin share of E:\? Also, as I'm not sure on this, `$` is a regex term, you may have to e\$ to escape out of it first. – Nate Dec 01 '15 at 19:55
  • e$ would only matter if a regex were being invoked. Otherwise it is just a plain old string and used as a path it would point to the default hidden share that shares e: – EBGreen Dec 01 '15 at 20:11
  • Having said that, this would not work: $Path = 'C\Test\'. There is a missing : but I suspect that is simply a typo in the post. – EBGreen Dec 01 '15 at 20:12
  • 1
    Do you get an error? – EBGreen Dec 01 '15 at 20:14
  • I don't really know the answer, but the first idea that comes to mind is that one ('E:\') would be file permissions and the other ('\\computername\e$') would be share permissions. The two are not exactly the same thing. – EBGreen Dec 01 '15 at 20:17
  • @EBGreen No. `Get-Acl` and `Set-Acl` always operate on filesystem permissions when used with a path (local or remote). – Ansgar Wiechers Dec 01 '15 at 21:42
  • I can't reproduce the problem. Both `Get-Acl` and `Test-Acl` worked with each of `C:\path`, `\\server\e$`, and `E:\` when I tested. How *exactly* did the code "not work" for you? Which statement failed? What error do you get? – Ansgar Wiechers Dec 01 '15 at 21:55
  • 1
    I couldn't reproduce it with Get-ACL, but Set-ACL threw a permissions error for me using E:\ that I haven't had the time to investigate. – EBGreen Dec 01 '15 at 22:14
  • @EBGreen, it'a typo, it should be C:\Test. Thanks The problem is the error from Set-Acl when I use "E:\" but not "\\$env:ComputerName\e$", I found the fix in another post http://stackoverflow.com/questions/6622124/why-does-set-acl-on-the-drive-root-try-to-set-ownership-of-the-object I just don't understand why the code is working for "\\$env:Computername\e$" but not "E:\" – Liu Dec 02 '15 at 10:40
  • That is a puzzler. I could understand working for E:\ and not for \\localhost\e$ as being due to share permissions. Share permissions will also be more restrictive than the ACLs - for a given user. **BUT**, if \\locahost\e$ is mapped with a different user, and that different user has more rights, then that would explain the discrepancy. You could look at Administrative Tools, Computer Management, Shared Folders, Sessions, to see what account is used to access \\localhost\e$ – Χpẘ Dec 03 '15 at 02:51

0 Answers0