Set Owner with PowerShell: “The security identifier is not allowed to be the owner of this object”

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

$ID = new-object System.Security.Principal.NTAccount($domain, $username)

$path = pathPrompt

write-host $path

$acl = get-acl $path
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.


20 comments so far

  1. Nick Williams on

    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!

    • Markus Igelmund on

      thanks, it works! But i do not understand why. Do you have any idea why this is the case?

      • Marquis Calmes on

        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.

  2. Dave on

    Very clever! Good find on this one.

  3. Adam on

    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).

  4. Martin on

    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!

  5. Niklas on

    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.

    • Marquis Calmes on

      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) {

  6. Tony on

    This was so amazingly helpful. Thank you.

  7. John on

    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.

  8. on

    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!!!!!

  9. Chris on

    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

  10. VirtualizeME-123 on

    you’re the man.. simple and worked for me!

  11. A User on

    Thank you for the post. Worked for me as well.

  12. Paul on

    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.

    • Paul on

      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!)

  13. Aaron on

    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.

  14. chris mayer on

    Many thanks for that Post, it saved a lot of time troubleshooting a script to remove the everyone group from millions of files.

  15. Joe on

    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.

  16. Mac MacAnanny on

    sooo many thanks lol use \\localhost\c$\path instead — just like delete doesn’t prompt when you use the UNC path… #niceMS

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: