Is TAKEOWN of a whole User tree dangerous?

I'm waiting for delivery of physical parts to repair laptop A
The user urgently needs her data on laptop B until A is fixed (or thrown away & replaced)
What I did
I attached via USB the System disk from A to temporary system B, where it was F: drive
Then to enable explorer to show me the data I used TAKEOWN

Code:

TAKEOWN   /F   F:\USERS\<username>  /R

(I should have added something to discard all the success text
Unfortunately the scope included APPDATA )

My question
WHERE are the permissions stored?

In the registry of system B running TAKEOWN ?
OR
In the MFT of the the F: drive, which I hope to boot again in system A after repair ?

If A's MFT is changed, I fear I may have messed up the system disk when it is rebooted after repair. Have I?
If permissions are recorded in TEMP system B's registry, I think no harm should have been done
Can you please clarify or give other guidance for the future - e.g "a better would have been...."

Thanks in advance

Spilly
Amateur system maintainer for local friends

Permissions and ownership are nothing to do with the registry on the machine that runs the command - they are part of the NTFS file system and are stored in the MFT of the volume concerned.

What you didn't do (which would be worse) is after taking ownership grant yourself permissions so at the moment your only issue is everything is owned by the wrong person. From a functionality point of view, this probably doesn't matter much - the Administrators group will still have authority to write to their files and so on.

What you have done is changed the ownership (stored on drive A) from whatever it was to your user on machine B. If you look at the owner you should see it. You can see the owner using get-acl in powershell.

Code:

PS C:\WINDOWS\system32> get-acl C:\Windows

    Directory: C:\

Path    Owner                       Access
----    -----                       ------
Windows NT SERVICE\TrustedInstaller CREATOR OWNER Allow  268435456...

PS C:\WINDOWS\system32> get-acl 'C:\Program Files\WindowsApps\'

    Directory: C:\Program Files

Path        Owner                       Access
----        -----                       ------
WindowsApps NT SERVICE\TrustedInstaller NT AUTHORITY\RESTRICTED Allow  ReadAndExecute, Synchronize...

PS C:\WINDOWS\system32> get-acl 'C:\Program Files\WindowsApps\Microsoft.3DBuilder_15.0.2223.0_neutral_~_8wekyb3d8bbwe\'

    Directory: C:\Program Files\WindowsApps

Path                                                    Owner               Access
----                                                    -----               ------
Microsoft.3DBuilder_15.0.2223.0_neutral_~_8wekyb3d8bbwe NT AUTHORITY\SYSTEM BUILTIN\Users Allow  ReadAndExecute, Synchronize...

PS C:\WINDOWS\system32>

This means that whereas before somethings were owned by SYSTEM or TrustedInstaller or the users who used machine A they are now all owned by "you". In this case "you" is a user that doesn't exist on machine B.

• Will it boot again? Yes, most likely.
• Is it compromised? I'd say yes but only because Microsoft set different owners for a reason.
• Can you fix ownership? No. Unfortunately (unless you backed them up before) you can't. There are various old utilities which will reset ownership and permissions based on the parent folder but these are from XP days and no longer applicable. For example appdata and WindowsApps (as you can see above) have specific non-inherited permissions.

Best case (in future) is not to take ownership. A better way to do what you are trying would be (while signed on as an administrator) copy the data somewhere else. You can then play with permissions to your hearts content. If you are changing data copy it back via C:\Users\Public then (when signed onto the machine again) move it from there to the user folder. This will get rid of permission/ownership issues resulting from access from an external system.

What I would do now if it was my PC is copy the data somewhere, clean install, sign onto user account and copy it back.

If it was someone else's PC not at risk of anything (like my young sons for example) I'd perhaps just leave it as I'm going to have to do a clean install eventually anyway. I think it will still work OK but you might run into problems down the road as new folders are created and inherit ownership for a user that doesn't exist.

That's a MOST helpful reply, thank you.
I thought permissions probably HAD to be in the MFT index on the disk.

I used TAKEOWN because when the drive was attached to Machine B for temporary use, I couldn't access any of the user libraries on the "foreign" disk. (at least I thought I couldn't read or see sub-folders. It's a bit late now)
I couldn't make a copy beforehand (e.g. to Public docs) with the drive as a running system because the hardware had a fault and would not boot.
So I was up the creek without a paddle.

Instead of TAKEOWN, could I have given myself Read permissions with ICACLS on the whole of the user tree ? Would that have been safer?
Could you please tell me the command (I'm a coward with ICACLS!)

But all is not lost. I have now learned that Win 10, Anniversary edition was re-installed last year in Italy in Italian language, so I can see a clean install on the horizon. I have a USB with Creators v 1703. It's the plain "Windows 10" edition in English.
FWIR, the Creators USB will refuse to update the Italian language system. Is that right? If so, it's a clean install.

I'd much prefer an in-place update because all of the installed apps are maintained, & I don't have to scrabble around downloading later versions and hunting for valid product keys. I don't know of any way round this. I've got to use Belarc Advisor, and a clean burn to a blank disk - Having secured the user data elsewhere first, of course.

Any tips much appreciated

Spilly
BTW, neither of the two systems used as above belong to me, so I want to get it right.