Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I recently tried to help someone out whose computer crashed (the reason why is not important for now) by recovering the HDD (i.e. remove it from the computer and plug into a docking station to backup the contents), but I'm running into trouble with Windows permissions and ownership.

People always think that because I'm an avid computer programmer and studying mathematics, I should somehow magically know the answers to all everyday computer problems, and it is really hard to convince them that those things are not really related (well they are, but programming and system management are completely different things).

Anyhow, when I plugged the HDD in my docking station and connected it to an other computer (both run Windows Vista, but that is not my choice) the partitions showed up as usual, but when I tried to look through the contents, all partitions were inaccessible (permission denied). I have done this kind of thing before without a problem and the only difference then was that the HDD came from a Windows 7 machine. I figured out that the partitions and their contents still had the old security attributes for the different user accounts set and that somehow Windows was still respecting them. So I tried to add the proper permissions for my local Administrator account with: properties -> security -> edit -> add. I thought that this would recursively set the permissions on all underlying folders and objects, but it did not did the trick, but I could now see the contents of the partitions root at least (sub-directories and objects were still inaccessible).

While I was trying to decide what I would do next, I noticed that there were no object- and folder owners. I do not know exactly what the difference is between owning an object or having the security permissions for an object, but I tried adding ownership to my local user account too, like this: properties -> security -> advanced -> owner -> edit -> apply. And now the problem: halfway while granting ownership to my local user there came a dialog that said that I did not have permissions to change ownership. While investigating what went wrong this time, I noticed two things:

  • I could read/write/execute every folder and object that was granted ownership (thus all folders and objects processed until the dialog appeared).
  • Where there was 1 GB of free space on the partition, there was now only a few KB. It seemed that the granting of ownership took more than a gigabyte, which seemed way to much for some metadata to me.

I tried exactly the same approach, but then with different partitions and the same happened, except for one partitions where there was 20 GB of free space (no additional space was consumed on that partition).

Any thought about what is going on?

share|improve this question

Generally speaking, you cannot move permission based filesystems from one independent operating system to another because the account IDs will not match between the systems. If the hard disk is considered as "external" or "removable" media, permission enforcement is relaxed. If the hard disk is attached and shows up as a "fixed hard disk" Windows will fully enforce permissions and, with the accounts not present on the new system, leave most of the files inaccessible.

If you would like to verify how the disk is attached, you can run this PowerShell command:

Get-WmiObject -Class Win32_DiskDrive | Format-Table Name,Model, MediaType

Regardless of the type, if you do not plan to ever put this disk back into the system it came from, you can perform a brute force takeover of the permissions if you have administrative permissions. (If you do want to use this disk in the other system, you will need to coax it into showing up as a removable or external drive.) From an elevated (administrator) command prompt, execute the following commands:

Brute Force Permission Reset

First, take ownership of everything on the drive (this will just set the owner, not create large ACLs that take disk space) The owner of an object in NT has an inherent, non-revocable right to change permissions of the object. This will ensure that you have permission to perform the next commands.


Next, reset (remove) all the ACLs on all the filesystem objects. This will get rid of unnecessary copies of ACLs that could otherwise be inherited:


Next, Set all the ACLs to inherit permission from their parents:


Finally, you can set the security explicitly on the drive "X:" security tab, and the permissions will simply be inherited throughout the filesystem.

share|improve this answer
Okay, thanks, I'll try that, but why are those ACLs so large? I could imagine a few MB at most, but more than 1 GB? – user314782 Apr 11 '14 at 8:52
That's a fair bit. For a 1TiB drive the default allocation unit on NTFS should be 4kiB - 100,000 files times 4kiB is 400MiB. The filesystem is optimized toward inheritance, so (off the cuff) you should generally have maybe 1 actual ACL to every 10,000 inherited. – Maxx Daymon Apr 11 '14 at 9:00

You must log in to answer this question.