Set-Owner

This function allows you to change the owner of a file(s) or folder(s) to another user or group. This is similiar to the takeown.exe command that is available from the command prompt, but in PowerShell. The function will elevate the token of the account (only in console session

Set-Owner.ps1
 
 
 
 
 
4.1 Star
(29)
36,401 times
Add to favorites
Storage
6/25/2014
E-mail Twitter del.icio.us Digg Facebook
Sign in to ask a question


  • Can this be used as a scheduled task?
    1 Posts | Last post January 11, 2017
    • I want to change some folders and I need to take ownership of new folders inserted in a certain folder. Your Set-Owner seems like the best way. Can I use it in a Scheduled Task?
      
      Thanks
  • Utilizing this script
    1 Posts | Last post January 09, 2017
    • Is there a means of incorporating this function within another script or must it be dotted in.
      
      I ask because I have added it into an existing script which is utilized to maintain (remove) terminated user folders.  The script currently makes sure the total folder+file path is less than 249 characters then removes the entire structure.
      
      We have run into a few situations where the user has altered permissions and are looking to make sure that the admin account performing the removal has access to each and every item within the structure.
      
      After incorporating this script into the main script, numerous errors occur when the initial try/catch encounters the catch.
      Initial error:  Preprocessor directives must appear as the first non-whitespace character on a line.
      
      Yes, this does not make sense to me at all and I am hoping that it will to you.
  • Suggestion
    2 Posts | Last post May 12, 2016
    • Hi Boe,
      
      Thanks so much for your such great powershell script. I am supporting network shared folder access management and often get folders that I  do not have access to.
      
      I have wrote a scrip myself to automatically take folder ownership. It works well until to the last recurse folder. And then I found this amazing script here. Awesome!!!
      
      Suggestion:
      
      I have already implemented a module named "NTFSSecurity" which has a cmdlets "Set-NTFSOwner",and it's alias is also named "Set-Owner". So hope there is a way to avoid conflict names?
      
    • Also get this error "Get-Item : The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters."
  • Problem on Windows 2012
    1 Posts | Last post January 19, 2016
    • Hi :-)
      
      I'm trying to run this on Windows 2012, and I am running into a few issues.
      
      I'm running it as domain Administrator, and I got loads of:
      WARNING: Couldn't take ownership of D:\Data\North America\L58412665.docx!
      I get the same for lots of directories.
      
      I can manually go in and change the Owner, but I had hoped to avoid this.
      
      Is there a way to force this?
      I am running  PowerShell as admin, and I am, naturally, admin on the box.
  • Recurse
    3 Posts | Last post June 01, 2015
    • This is really a great function, thank you very much for sharing it. However, when I try the option '-Recurse' it works fine to set the owner to the 'BUILTIN\Administrators' everywhere but not for a non privileged account like 'Domain\Bob'. 
      
      When using another account for setting ownership than the 'BUILTIN\Administrators' it's spitting out warnings for all folders except the top folder and the first subfolder:
      
      Set-Owner 'S:\Test\TopFolder' -Recurse -Account 'GROUPHC\Gijbelsb' -Verbose
      
      VERBOSE: FullName: S:\Test\TopFolder
      VERBOSE: Performing the operation "Set Directory Owner" on target "S:\Test\Topfolder".
      VERBOSE: FullName: S:\Test\TopFolder\SubFolder1
      VERBOSE: Performing the operation "Set Directory Owner" on target "S:\Test\Topfolder\SubFolder1".
      VERBOSE: FullName: S:\Test\TopFolder\SubFolder2
      VERBOSE: Performing the operation "Set Directory Owner" on target "S:\Test\Topfolder\SubFolder2".
      WARNING: Couldn't take ownership of S:\Test\Topfolder\SubFolder2! Taking FullControl of S:\Test\Topfolder
      WARNING: S:\Test\Topfolder\SubFolder2: Exception calling "SetAccessControl" with "1" argument(s): "The security identifier is not allowed to be the owner of this 
      object."
      
      Does this work for you on all the subfolders when using a regular account to set as 'Owner'?
    • I had to recursivly change the ownership of a large directory based on some criteria. What way better then solve this with PowerShell? Well, that turned out to be not so easy, just like the author of this module said in his blog. Thank god he wrote this module which saved me a great deal of time.
      
      So after setting up a script to match the criteria I was happy to start testing with Set-Owner recursivly. But that happiness flew out the window the moment I noticed the function failed on setting ownership of the second folder it encountered. Wait what? That sounds confusing, lets get a clear picture.
      
      Setting ownership of these folders succeeds:
      D:\NETWERKDATA\USERPROFILES_RDS\abes.OBBH.V2
      D:\NETWERKDATA\USERPROFILES_RDS\abes.OBBH.V2\AppData
      D:\NETWERKDATA\USERPROFILES_RDS\abes.OBBH.V2\AppData\Roaming
      D:\NETWERKDATA\USERPROFILES_RDS\abes.OBBH.V2\AppData\Roaming\Adobe
      D:\NETWERKDATA\USERPROFILES_RDS\abes.OBBH.V2\AppData\Roaming\Adobe\Acrobat\10.0
      D:\NETWERKDATA\USERPROFILES_RDS\abes.OBBH.V2\AppData\Roaming\Adobe\Acrobat\10.0\Forms
      
      But then it encountered a folder where more folders existed:
      D:\NETWERKDATA\USERPROFILES_RDS\abes.OBBH.V2\AppData\Roaming\Adobe\Acrobat\10.0\JSCache
      
      WARNING: Couldn't take ownership of D:\NETWERKDATA\USERPROFILES_RDS\abes.OBBH.V2\AppData\Roaming\Adobe\Acrobat\10.0\JSCache!
       Taking FullControl of D:\NETWERKDATA\USERPROFILES_RDS\abes.OBBH.V2\AppData\Roaming\Adobe\Acrobat\10.0
      WARNING: D:\NETWERKDATA\USERPROFILES_RDS\abes.OBBH.V2\AppData\Roaming\Adobe\Acrobat\10.0\JSCache: Exception calling "SetAcce
      ssControl" with "1" argument(s): "The security identifier is not allowed to be the owner of this object."
      
      What was happening?
      It seems the privileges seTakeOwnershipPrivilege, SeRestorePrivilege and SeBackupPrivilege are set each time the Set-Owner function is invoked. Moving those to within the For-Each loop will fix this issue.
    • Change this:
      
                  Add-Type $AdjustTokenPrivileges
              }
      
              #Activate necessary admin privileges to make changes without NTFS perms
              [void][TokenAdjuster]::AddPrivilege("SeRestorePrivilege") #Necessary to set Owner Permissions
              [void][TokenAdjuster]::AddPrivilege("SeBackupPrivilege") #Necessary to bypass Traverse Checking
              [void][TokenAdjuster]::AddPrivilege("SeTakeOwnershipPrivilege") #Necessary to override FilePermissions
          }
          Process {
              ForEach ($Item in $Path) {
                  Write-Verbose "FullName: $Item"
                  #The ACL objects do not like being used more than once, so re-create them on the Process block
                  $DirOwner = New-Object System.Security.AccessControl.DirectorySecurity
      
      Into:
                  Add-Type $AdjustTokenPrivileges
              }
          }
          Process {
              ForEach ($Item in $Path) {
                  Write-Verbose "FullName: $Item"
                  #Activate necessary admin privileges to make changes without NTFS perms
                  [void][TokenAdjuster]::AddPrivilege("SeRestorePrivilege") #Necessary to set Owner Permissions
                  [void][TokenAdjuster]::AddPrivilege("SeBackupPrivilege") #Necessary to bypass Traverse Checking
                  [void][TokenAdjuster]::AddPrivilege("SeTakeOwnershipPrivilege") #Necessary to override FilePermissions
                   #The ACL objects do not like being used more than once, so re-create them on the Process block
                  $DirOwner = New-Object System.Security.AccessControl.DirectorySecurity
  • Suggestion
    1 Posts | Last post December 15, 2014
    • Thank you, I just implemented and adapted your script in an automation environment.
      
      One suggestion though, to fix i18n issues, something like:
      
      $BuiltinAdministrators = (New-Object System.Security.Principal.SecurityIdentifier("S-1-5-32-544")).Translate([System.Security.Principal.NTAccount])
      
      for default values.
      Also, I added a -Force option, because defaulting to upstream traversation on a UNC path by a (selectively clueless) Domain admin is not such a good idea in those scenarios. ;)