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
}

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

About these ads

14 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

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

      • 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. nospam@nospam.com 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.


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: