Managing permissions with PowerShell is only a bit easier than in VBS or the command line as there are no cmdlets for most day-to-day tasks like getting a permission report or adding permission to an item. PowerShell only offers Get-Acl and Set-Acl but everything in between getting and setting the ACL is missing. This module closes the gap.
MIT License
431
stars
61
forks
source link
Set-NTFSOwner with a filesystem object as a positional parameter #88
Set-NTFSOwner works on files or directories (file system objects), and has the file path as the first parameter. This parameter is an alias of FullNameaccording to the docs (Set-NTFSOwner), so I assumed it would automatially pick up the FullName property of an object that was passed to that parameter.
I was surprised to find that in a typical Powershell loop across a file tree-
$FileTree = Get-Childitem $Root -Recurse -Force
foreach ($Item in $FileTree) {
# Items not owned by the expected user
if ($Item.Owner -ne 'localmachine\localuser') {
Set-NTFSOwner $Item -Account 'localmachine\localuser'
}
}
this fails with the error Set-NTFSOwner : Unable to find the specified file.
It is fixable by changing key line to-
Set-NTFSOwner $Item.FullName -Account 'localmachine\localuser'
or-
Set-NTFSOwner -Path $Item.FullName -Account 'localmachine\localuser'
Perhaps Set-NTFSOwner is trying to access the relative filename rather than the full path to the file?
I don't think this is consistent with the majority of built-in Powershell cmdlets that operate on files, that seem happy to accept a filesystem object or a full file path for a Path paramater, and do the right thing with either.
Is this behaviour consistent across all the NTFSSecurity cmdlets, or is Set-NTFSOwner differnt in this regard?
Set-NTFSOwner
works on files or directories (file system objects), and has the file path as the first parameter. This parameter is an alias ofFullName
according to the docs (Set-NTFSOwner), so I assumed it would automatially pick up the FullName property of an object that was passed to that parameter.I was surprised to find that in a typical Powershell loop across a file tree-
this fails with the error Set-NTFSOwner : Unable to find the specified file.
It is fixable by changing key line to-
Set-NTFSOwner $Item.FullName -Account 'localmachine\localuser'
or-Set-NTFSOwner -Path $Item.FullName -Account 'localmachine\localuser'
Perhaps Set-NTFSOwner is trying to access the relative filename rather than the full path to the file?I don't think this is consistent with the majority of built-in Powershell cmdlets that operate on files, that seem happy to accept a filesystem object or a full file path for a
Path
paramater, and do the right thing with either.Is this behaviour consistent across all the NTFSSecurity cmdlets, or is
Set-NTFSOwner
differnt in this regard?