I’ve written several PowerShell scripts to help customers adjust permissions to their directory structures when migrating from other file servers(Linux/Samba, Novell OES/Netware, etc). Part of these scripts includes assigning ownership for the user. While this tends to take a long time quotas and file reporting are worthless if the administrator that copied everything is assigned as the owner.
Recently I tried to adapt one of these scripts for a customer, but when I ran it it failed with the error: “The security identifier is not allowed to be the owner of this object”
A quick internet search found lots of people saying basically this can’t be done with PowerShell. What!!! I know for a fact these scripts had worked before. What’s the deal? After a lot of testing and beating my head against the wall I figure out I was trying to do something different. Previously I had run my scripts against the UNC path (eg. \\servername\share\directory), but this time I was trying to run it on a local directory using the drive path (E:\Share\Directory).
Could it be that simple? Yes. I ran the command again using the UNC path and the script worked as it did before.
Here is an example script to set the owner of a directory or file to test the above:
function pathPrompt {
$tempPath = $null
$tempPath = Read-Host ‘Please enter the path of thedirectory (e.g. “\\file\vol1\users\example”‘
return $tempPath
}$username=”exampleuser”
$domain=”domain”
$ID = new-object System.Security.Principal.NTAccount($domain, $username)$path = pathPrompt
write-host $path
$acl = get-acl $path
$acl.SetOwner($ID)
set-acl -path $path -aclObject $acl
Save the above to a file with a .PS1 extension, change the $username and $domain variables, and run it (make sure you set-executionpolicy to unrestricted and PowerShell as administrator). It will prompt for a path. It will then write the path to powershell and then set the owner if it can.
Below is an example of running it against a local path and a UNC path.
Fixing IT 
Thanks for posting this… it worked for me, and saved me trying to figure out how to get the other solutions working by adjusting the security token to enable the restore privilege. Good job!
Hi,
thanks, it works! But i do not understand why. Do you have any idea why this is the case?
Greets!
I think it has to do with Windows Server treating local directories different then UNC paths (even if it is to a local file resource). It’s been a long time since I worked with this so I don’t remember if I tested turning of User Access Control (UAC) on the server or not, but it might be worth somebody testing.
Very clever! Good find on this one.
Thank you so very much for this! Excellent work!! I was struggling with the same issue on an NFS share where files were moved in from a Linux server (no inheritance).
Thanks a lot – I was targeting the local folders X:\Homefolder and was experiencing this exact error… When I switched to \\fileserver\homefolder everything was working just fine 🙂 Thx a lot!
Many, Many Thanks for that info, I lost half a day, till I found this post 🙂
I may have one Question, how can you set the ownership of subfolders.
For my purpose I only needed to go one sub-folder deep. I was able to do this with the below code.
$subdirs= Get-ChildItem $rootPath | Where-Object {$_.mode -match "d"} | Select-Object name
foreach ($subdir in $subdirs) {
This was so amazingly helpful. Thank you.
Thanks. If only I had found your post before all those others (which had much more complicated work-arounds) , it would have saved me half day’s work.
Wow, thank you. When I set the owner using a local path it did not work. When I shared my local folder and used the UNC path instead, it worked.
THANK YOU!!!!!
Thanks for this. The UNC path is critical to this. The other critical part is running powershell as the administrator. Otherwise you will just get an error claiming that:
the security identifier is not allowed to be the owner of this object
you’re the man.. simple and worked for me!
Thank you for the post. Worked for me as well.
I can confirm that this problem has it’s roots in the .NET Framework. I had the same problem while changing ownership with a C# application. Interestingly as Administrator i was able to change from to HOST\Administrator but not from to (receiving an InvalidOperationException with the above Message)
Initializing my System.IO.FileInfo objects with a UNC Path solved the issue for me.
Post requires edit as I used special characters. (another option would be to clean up the input parser of the comment system on this site!)
Well, here’s something for you. I just spent two days trying to Set Owner on some files on a network UNC path. Only after trying other tools and failing there, too, did I give up.
I had assigned myself all Privileges possibly needed and still could not even use SubInAcl, nor Robocopy, to copy a file and keep ownership. I could also not write ownership in any way using Powershell or .net commands on files on this UNC path.
At this time, I believe it’s a setting on the SAN. I can’t believe there is anything else that could be preventing it. Will talk to our Storage Engineers next week though.
Many thanks for that Post, it saved a lot of time troubleshooting a script to remove the everyone group from millions of files.
Hopefully this helps all those who struggled with the blank output. I had to
1. Run as admin
2. Use UNC path
3. . .\Set-Owner.ps1
3 is the less obvious step that resolved the issue for me. Placing in System32 and .\Set-Owner.ps1 did not work.
sooo many thanks lol use \\localhost\c$\path instead — just like delete doesn’t prompt when you use the UNC path… #niceMS
Thank you! This tip save me after 6hours of troubleshooting.