takeown
is an in-built Windows tool that lets you take ownership of files and folders. Unlike other tools (e.g. icacls
) which only let you give someone the right to take ownership of a file or folder, takeown
seems to actually let you become the owner. And not just yourself, you can run it under a different context and that user account can be made the owner.
But it has a quirk which isn’t obvious until it turns around and bites you!
Here’s what I am using takeown
for. I have a bunch of roaming profile folders that my admin account can’t view because only the user has full access to it. If I were using the GUI I would have opened the security tab of these folders, changed ownership to myself or the Administrators group, set that to propogate to all the child folders, and then add myself to the ACLs of this folder setting it to replace the ACLs of this folder and its children.
I have a large number of such folders, however, and I want to create a batch file to do this easily.
The obvious solution is to use takeown
.
1 2 3 |
Y:\>takeown /A /F profile.V2 SUCCESS: The file (or folder): "Y:\profile.V2" now owned by the administrators group. |
But this only sets the ownership of the parent folder. Not a problem, there’s a switch /R
which tells takeown
to recurse, so let’s try that:
1 2 3 4 5 6 7 8 9 10 11 12 |
Y:\>takeown /A /R /F profile.V2 SUCCESS: The file (or folder): "Y:\profile.V2" now owned by the administrators group. You do not have permissions to read the contents of directory "Y:\profile.V2". Do you want to replace the directory permissions with permissions granting you full control ("Y" for YES, "N" for NO or "C" to CANCEL)? y SUCCESS: The file (or folder): "Y:\profile.V2\AppData" now owned by the administrators grou SUCCESS: The file (or folder): "Y:\profile.V2\Citrix" now owned by the administrators group ... |
Note that harmless question: do you want to replace the directory permissions with ones granting us full control? Harmless, because that’s what you would do via the GUI too. Gaining ownership of a folder doesn’t give you any permissions. That’s a separate step, so it seems like the command is only being helpful and offering to do this for you (so it can peek inside the sub-folders and give you ownership there too). And there-in lies the quirk which turned around and bit me. If you answer YES to this question (or use a switch /D Y
to answer YES by default) it replaces the existing permissions with a new set. Yes, replace, not append as the GUI would have done. The net result of this is that once you run the takeown
command as above only the Administrators group has any permissions, even the user loses their rights!
1 2 3 4 5 |
Y:\>icacls profile.V2 profile.V2 BUILTIN\Administrators:(OI)(IO)(F) BUILTIN\Administrators:(CI)(F) Successfully processed 1 files; Failed processing 0 files |
That’s definitely not what we want!
The right approach here seems to be to use a mix of takeown
and icacls
.
First use takeown
to get ownership to the parent folder:
1 2 3 |
Y:\>takeown /A /F profile.v2 SUCCESS: The file (or folder): "Y:\profile.v2" now owned by the administrators group. |
Then use icacls
to recursively grant Full Control to the parent folder and sub-folders. Note that this only appends to the ACLs, it doesn’t replace. (This takes a few minutes and there’s plenty of output).
1 2 3 4 |
Y:\>icacls profile.v2 /grant BUILTIN\Administrators:F /T processed file: profile.v2 profile.v2\AppData: Access is denied. Successfully processed 1 files; Failed processing 1 files |
I don’t know why AppData
failed above. It did for all the profiles I tested with and I didn’t investigate further. Could be an icacls
limitation I suppose.
At this point the roaming profile is owned by Administrators, and the ACLs have an entry for the Administrators group in addition to the existing ACEs.
Now I run takeown
again, recursively, but this time I target only the sub-folders (i.e. not the parent folder, only the ones below it).
1 |
Y:\>takeown /A /F profile.v2\* /R /D Y |
takeown
doesn’t have limitions like icacls
. It’s ruthless! It will change ownership of all the sub-folders – including AppData
– and replace the ACEs granting Administrators full access.
1 2 3 4 5 6 7 8 9 |
Y:\>icacls profile.v2\AppData profile.v2\AppData BUILTIN\Administrators:(OI)(IO)(F) BUILTIN\Administrators:(CI)(F) Successfully processed 1 files; Failed processing 0 files Y:\>icacls profile.v2\Searches profile.v2\Searches BUILTIN\Administrators:(OI)(IO)(F) BUILTIN\Administrators:(CI)(F) |
Now I run icacls
on all the sub-folders, enabling inheritance on them. (This too takes a few minutes, but there’s no output except towards the end). The result of this step is that the botched ACEs set by takeown
are fixed by icacls
as it enables inheritance.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
Y:\>icacls profile.v2\* /inheritance:e /T Y:\>icacls profile.v2\Searches profile.v2\Searches BUILTIN\Administrators:(OI)(IO)(F) BUILTIN\Administrators:(CI)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) MYDOMAIN\profile:(I)(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files Y:\>icacls profile.v2\AppData profile.v2\AppData BUILTIN\Administrators:(OI)(IO)(F) BUILTIN\Administrators:(CI)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) MYDOMAIN\profile:(I)(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files |
And that’s it. That’s how to properly use takeown
and icacls
to take ownership and reset permissions on a folder and its children.