Windows 7 Forums

Welcome to Windows 7 Forums. Our forum is dedicated to helping you find support and solutions for any problems regarding your Windows 7 PC be it Dell, HP, Acer, Asus or a custom build. We also provide an extensive Windows 7 tutorial section that covers a wide range of tips and tricks.


Windows 7: Ownership of foreign files - XP vs 7P access issues

12 Apr 2016   #1
tns1

PCs: xp32, 7pro64, 10pro64, Linux
 
 
Ownership of foreign files - XP vs 7P access issues

I added a new drive with a new 7P install to an existing XP box. Both drives are NTFS. Using F12, the system can be booted to either OS with both drives visible. For lack of terminology, lets say that when booted under XP, the local drive & files are 'local', and the 7P drive & files are 'foreign' to XP. Likewise when booted under 7P, the XP drive and files are 'foreign'. Ideally the foreign drives would appear read only to the booted OS, so that mistakes/malware on one OS could not mess up the other drive. Can this be done?

I Ran into the access denied issue under 7P when trying to copy some files over from XP the drive. Most files copy just fine, but a handful of jpg, pdf, txt and other non-system files get 'access denied'. Under 7P, I tried using a 'regular' unelevated administrator acct, an 'elevated' administrator acct, and an explorer window granted admin access. All get denied for these few files. After reading similar posts, this seems to be a common ownership problem that causes much frustration. I know of a few ways to get the files copied. This post is more about getting a better understanding of what is happening. There may be a great explanation out there I just have not seen.

I have to ask: Is there a way to get a SUPERDUPER-elevated admin acct that would never be denied access (SYSTEM level maybe?), or does ownership always trump permissions under 7P?

The working solutions I am aware of:
1) Under XP, copy the local files to an external (non-NTFS?) drive, which changes file ownership to 'everyone'. Under 7P these can then be copied to the 7P drive without issue.
2) Under 7P, use the 'take ownership' shortcut, which changes ownership by (modifying the ACL?) of the foreign drive/file. Seems like this would not be possible if the foreign drive were read only, and modifying a foreign drive seems like a bad idea leading to problems for that foreign OS. If any writing is needed, it should happen only from the local OS.
3) There is supposed to be a way to grant ownership from XP so a foreign OS can later take ownership. If this can be done without the concern of option #2, it would be preferred. Can it?

So what is the actual difference in these files?
I have an XP folder containing a couple of simple pdfs. Under 7P, I have access to one of these, but the other gets 'access denied'. At some level there is a difference that 7P sees. Looking at the properties for these two files locally under XP shows no differences in permissions or ownership. The difference is there, but XP can't see it/isn't showing it. There is only one User-Admin acct under XP, so what circumstance caused the problem file to be different?
Is there another tool under XP that would show me this difference and allow me to locate all the problem files to better anticipate & deal with them?

For this particular file, I stumbled across another solution:
4) Under XP, make a local copy of the problem file first. Under 7P, this new copy did not have access issues. Maybe this is the general solution to all my problem files, but it would be nice to identify the few files and just deal with those.

Thoughts?


My System SpecsSystem Spec
.
13 Apr 2016   #2
Pyprohly

Windows 10, Windows 8.1 Pro, Windows 7 Professional, OS X El Capitan
 
 

Hi Tns1,

Quote   Quote: Originally Posted by tns1 View Post
Ideally the foreign drives would appear read only to the booted OS, so that mistakes/malware on one OS could not mess up the other drive. Can this be done?
Not easily. Access control is handled on a per user/group basis, irrespective of the OS or machine accessing the resource. One way to achieve what you have described would be to create a group on each of the machines, add all the user accounts to the groups, then deny the groups from writing to the foreign drive.

Quote   Quote: Originally Posted by tns1 View Post
an explorer window granted admin access.
Not exactly sure what you mean by this. If you just opened explorer.exe by right-clicking and selecting Run as administrator, the resulting Explorer window may not necessarily be granted "admin access".

Quote   Quote: Originally Posted by tns1 View Post
After reading similar posts, this seems to be a common ownership permissions problem that causes much frustration.
That was misleading.

It is a misconception that simply giving yourself ownership of a file will give you access to it. This is hardly the case. In fact, in any situation, by taking ownership of an object you will not gain any more access to it than originally possessed.

Quote   Quote: Originally Posted by tns1 View Post
Is there a way to get a SUPERDUPER-elevated admin acct that would never be denied access (SYSTEM level maybe?)
No. All administrator accounts under Windows exist with equal rights (for the most part, that is). Not even the SYSTEM "account" is king in it's own territory; it just so happens that SYSTEM is listed as having full access in the Access Control List (ACL) of many files. All user accounts are subject to NTFS permission restrictions equally.

Quote   Quote: Originally Posted by tns1 View Post
1) Under XP, copy the local files to an external (non-NTFS?) drive, which changes file ownership to 'everyone'. Under 7P these can then be copied to the 7P drive without issue.
You must be careful when being non-specific. What file system are we talking here? Some file systems do not support permissions (and the concept of ownership for that matter) at all, in which case the files it holds are "owned" by everyone by default.

From my limited testing, if one moves a file from Windows to an NTFS formatted drive, the file's owner will change to that of the user account that conducted the move, not "Everyone".

Quote   Quote: Originally Posted by tns1 View Post
2) Under 7P, use the 'take ownership' shortcut, which changes ownership (by modifying the ACL?) of the foreign drive/file.
Nope. It changes the owner by changing the owner. Ownership is stored separately from the ACL. The ACL contains that actual access rules of an object.

And if by "'take ownership' shortcut" you mean registry tweaks like this one, they are not guaranteed to grant you access. They may fail under certain permission configurations involving deny entires.

Quote   Quote: Originally Posted by tns1 View Post
Seems like this would not be possible if the foreign drive were read only, and modifying a foreign drive seems like a bad idea leading to problems for that foreign OS.
There are many definitions of read-only, and your statement may or may not be true depending on your definition.

Nothing is a bad idea if you are in control, and know what you are doing.


Quote   Quote: Originally Posted by tns1 View Post
3) [Is there] supposed to be a way to grant ownership from XP so a foreign OS can later take ownership.
If the XP machine is using NTFS, you can change the owner of the object through the security tab, as usual. But again, simply changing the owner of a file will not do very much.


Quote   Quote: Originally Posted by tns1 View Post
I have an XP folder containing a couple of simple pdfs. [...] Looking at the properties for these two [PDF] files locally under XP shows no differences in permissions or ownership. [...] There is only one User-Admin acct under XP, so what circumstance caused the problem file to be different?
There should be no difference in the security settings of these files between your XP and 7 operating systems. Permissions don't just change themselves.

If I may view the permissions of both PDFs you mention, I may point out to you exactly why you do not have access to one of them.

On your Windows 7 install, open an Elevated Command Prompt and enter the below command twice: once for each of the PDFs you've mentioned.
Code:
icacls "C:\path\to\file.pdf"
Copy and paste the outputted text here.
My System SpecsSystem Spec
13 Apr 2016   #3
tns1

PCs: xp32, 7pro64, 10pro64, Linux
 
 

Quote:
Quote: Originally Posted by tns1
an explorer window granted admin access.


Not exactly sure what you mean by this. If you just opened explorer.exe by right-clicking and selecting Run as administrator, the resulting Explorer window may not necessarily be granted "admin access".
Yes, exactly this.

Quote:
Quote: Originally Posted by tns1
1) Under XP, copy the local files to an external (non-NTFS?) drive, which changes file ownership to 'everyone'. Under 7P these can then be copied to the 7P drive without issue.


You must be careful when being non-specific. What file system are we talking here? Some file systems do not support permissions (and the concept of ownership for that matter) at all, in which case the files it holds are "owned" by everyone by default.
A fat32 drive.

Quote:
Quote: Originally Posted by tns1
2) Under 7P, use the 'take ownership' shortcut, which changes ownership (by modifying the ACL?) of the foreign drive/file.


Nope. It changes the owner by changing the owner. Ownership is stored separately from the ACL. The ACL contains that actual access rules of an object.

And if by "'take ownership' shortcut" you mean registry tweaks like this one, they are not guaranteed to grant you access. They may fail under certain permission configurations involving deny entires.
OK, it modifies the MFT. The point is that a file system created under one OS is being modified by another OS. Even if both of these OSs follow the same file system standard, it seems like a less secure way to go about things. Maybe the NTFS standard and implementation has been done so well on these respective OSs that a take ownership scenario is never going to mess up a foreign drive. The sure way is to grant those rights/ownership from the local OS/owner in a way that requires no writes from the foreign OS. When I say no writes, I mean not one bit hidden or otherwise needs to be modified. Not possible?

Quote:
On your Windows 7 install, open an Elevated Command Prompt and enter the below command twice: once for each of the PDFs you've mentioned.
Code:
icacls "C:\path\to\file.pdf"
Copy and paste the outputted text here.
The first file below can be accessed, the 2nd cannot. Both were downloaded from commercial websites:

F:\PDownloads\network>icacls "F:\PDownloads\network\New network 2015\E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf"
F:\PDownloads\network\New network 2015\E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf
BUILTIN\AdministratorsI)(F)
NT AUTHORITY\SYSTEMI)(F)
No mapping between account names and security IDs was done.
(I)(F)
BUILTIN\UsersI)(RX)
Successfully processed 1 files; Failed processing 0 files

F:\PDownloads\network>icacls "F:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf"
F:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf: Access is denied.
Successfully processed 0 files; Failed processing 1 files
My System SpecsSystem Spec
.

13 Apr 2016   #4
Pyprohly

Windows 10, Windows 8.1 Pro, Windows 7 Professional, OS X El Capitan
 
 

Quote   Quote: Originally Posted by tns1 View Post
A fat32 drive.
The FAT32 file system does not support permissions, or the concept of ownership for that matter. So moving a file onto such will not change the file's owner to ‘Everyone’.

Quote   Quote: Originally Posted by tns1 View Post
OK, it modifies the MFT. The point is that a file system created under one OS is being modified by another OS. Even if both of these OSs follow the same file system standard, it seems like a less secure way to go about things. Maybe the NTFS standard and implementation has been done so well on these respective OSs that a take ownership scenario is never going to mess up a foreign drive.
How so? I do not share the insecurity you feel.

Running the Take Ownership shortcut on a foreign drive is only going to mess it up as much as it would be messed up if you did so using the correct OS.

Quote   Quote: Originally Posted by tns1 View Post
The sure way is to grant those rights/ownership from the local OS/owner in a way that requires no writes from the foreign OS. When I say no writes, I mean not one bit hidden or otherwise needs to be modified. Not possible?
I see your intentions. I’m sorry, but you'll always be under the influence of NTFS permissions while in Windows.

Quote:
F:\PDownloads\network>icacls "F:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf"
F:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf: Access is denied.
Successfully processed 0 files; Failed processing 1 files
That’s no good. I was hoping to avoid having to use Cacls on the XP machine. Unless you can copy the Icacls tool over, repeat the commands on the XP machine, but using Cacls, and post the results here another time.
My System SpecsSystem Spec
14 Apr 2016   #5
tns1

PCs: xp32, 7pro64, 10pro64, Linux
 
 

Quote:
The FAT32 file system does not support permissions, or the concept of ownership for that matter. So moving a file onto such will not change the file's owner to ‘Everyone’.
When you copy files to a Fat32 drive from XP, you don't see any ownership or security info in the file properties, but when the drive is viewed from 7P, those same files show "Owner: Everyone" in the details tab for every pdf, txt, xls, and probably every non-executable. For some reason zip and exe files don't have that info. My guess is that this is just 7P pointing out there is no ownership.

Quote:
Running the Take Ownership shortcut on a foreign drive is only going to mess it up as much as it would be messed up if you did so using the correct OS.
Different patch and update levels? Malware? Failing HW? There are lots of reasons a foreign chunk of code might not handle your data properly.



cacls output for the same two files:
C:\PDownloads\network\New network 2015>cacls "E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf"
C:\PDownloads\network\New network 2015\E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
XPS630\T:F
BUILTIN\Users:R


C:\PDownloads\network\New network 2015>cacls "GS108E_IG_PE_17Dec10.pdf"
C:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf NT AUTHORITY\SYSTEM:F
XPS630\T:F


C:\PDownloads\network\New network 2015>
My System SpecsSystem Spec
14 Apr 2016   #6
Pyprohly

Windows 10, Windows 8.1 Pro, Windows 7 Professional, OS X El Capitan
 
 

Quote   Quote: Originally Posted by tns1 View Post
Quote:
Running the Take Ownership shortcut on a foreign drive is only going to mess it up as much as it would be messed up if you did so using the correct OS.
Different patch and update levels? Malware? Failing HW? There are lots of reasons a foreign chunk of code might not handle your data properly.
I don't see how running Take Ownership on files located in places other than the boot partition may increase your chances of data loss via malware, failing hard drive, etc.

The 'Take Ownership' shortcut is not built from foreign code. It's a well-defined sequence of commands that are especially designed for Windows.

Quote   Quote: Originally Posted by tns1 View Post
cacls output for the same two files:
Code:
C:\PDownloads\network\New network 2015>cacls "E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf"
C:\PDownloads\network\New network 2015\E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf BUILTIN\Administrators:F
                                                                               NT AUTHORITY\SYSTEM:F
                                                                               XPS630\T:F
                                                                               BUILTIN\Users:R


C:\PDownloads\network\New network 2015>cacls "GS108E_IG_PE_17Dec10.pdf"
C:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf NT AUTHORITY\SYSTEM:F
                                                                XPS630\T:F
As you may observe, the permissions for the two PDFs are indeed different.

On PDF 1, “E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf”, the permissions grant full access to members of the Administrators group, SYSTEM, and a user named ’T’ on computer ‘XPS630’. And read-only access is granted to members of the Users group.

On PDF 2, “GS108E_IG_PE_17Dec10.pdf”, full access is granted to SYSTEM, and a user named ’T’ on computer ‘XPS630’.


Using this data from Cacls, here are the resulting permissions in effect when accessing the PDF from the two computers:
Code:
        ╔══════════════════════════╦══════════════╗
        ║            7P            ║      XP      ║
╔═══════╬══════════════════════════╬══════════════╣
║ PDF 1 ║ Read* and Full control** ║ Full control ║
║ PDF 2 ║ No access                ║ Full control ║
╚═══════╩══════════════════════════╩══════════════╝
*Or Read and Execute. The old Cacls tool is unable to distinguish the difference.
**When running as administrator.
My System SpecsSystem Spec
14 Apr 2016   #7
tns1

PCs: xp32, 7pro64, 10pro64, Linux
 
 

Quote:
Quote: Originally Posted by tns1
Quote:
Running the Take Ownership shortcut on a foreign drive is only going to mess it up as much as it would be messed up if you did so using the correct OS.


Different patch and update levels? Malware? Failing HW? There are lots of reasons a foreign chunk of code might not handle your data properly.



I don't see how running Take Ownership on files located in places other than the boot partition may increase your chances of data loss via malware, failing hard drive, etc.

The 'Take Ownership' shortcut is not built from foreign code. It's a well-defined sequence of commands that are especially designed for Windows.
'Foreign' as in originating from a different install under a different OS and almost certainly NOT running the exact same set of instructions. I am sure everything possible is done to have consistent results on every win platform from XPx32 to W10x64, and if every platform is running fully patched code, on sound HW, on pristine installations, with reliable power, then the only thing you really have to trust is that MS got it right. You see that there is a trust level and a risk even in this fantasy setup. A strict read-only scenario would be largely immune from these risks as well as the much larger real-world risks. If windows-ntfs doesn't support that scenario, I'll just have to live with it.

Quote:
As you may observe, the permissions for the two PDFs are indeed different.

On PDF 1, “E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf”, the permissions grant full access to members of the Administrators group, SYSTEM, and a user named ’T’ on computer ‘XPS630’. And read-only access is granted to members of the Users group.

On PDF 2, “GS108E_IG_PE_17Dec10.pdf”, full access is granted to SYSTEM, and a user named ’T’ on computer ‘XPS630’.
By testing, it looks as though every file that shows BUILTIN\Administrators:F, and BUILTIN\Users:R in the ACLs, has no access problems from 7P. Files that don't show these will deny access. How were these files created without similar ACLs? Is this due to platform or did the creators just edit the ACLs?

Is it enough to add the missing BUILTIN users-groups to those files, or is there more? Under 7P when I look at properties->security->edit->add->advanced->find now, there is no BUILTIN listed.

edit
If I make a local copy under XP, that copy includes the BUILTIN users-groups and has no access issue. I noted before this is probably the easiest solution, but still looking to understand it. I see now that I can select BUILTIN categories from find now. Would the missing BUILTINs mentioned be 'authenticated users' or some other on the list?
My System SpecsSystem Spec
14 Apr 2016   #8
LMiller7

Windows 7 Pro 64 bit
 
 

I agree with Pyprohly

The concept of taking ownership is not something new that Microsoft is still working the bugs out of. It has been a part of the NT platform since it was introduced in 1993. Since then it has been extensively tested by Microsoft and used by large corporations with a great deal to lose if something were to go wrong.

There is no mechanism in Windows to assign ownership to another OS.

I would rather trust taking ownership than any other method you might think of.

It doesn't matter what OS is used to take ownership, whether it be Windows 2000 or Windows 10, 32 bit or 64 bit, the end result is the same.
My System SpecsSystem Spec
15 Apr 2016   #9
Pyprohly

Windows 10, Windows 8.1 Pro, Windows 7 Professional, OS X El Capitan
 
 

Thank you LMiller7, that was precisely what I had to say.


Quote   Quote: Originally Posted by tns1 View Post
By testing, it looks as though every file that shows BUILTIN\Administrators:F, and BUILTIN\Users:R in the ACLs, has no access problems from 7P.
Your access control to files with only those two permissions on them will be exactly the same on both your operating systems: Read (and maybe Execute) or Full control when running applications as administrator.

Quote   Quote: Originally Posted by tns1 View Post
Files that don't show these will deny access.
Just to be clear, things aren’t that simple, and your observation will not hold true for many cases. You can have a file with those mentioned permissions and still not have access to them.

Quote   Quote: Originally Posted by tns1 View Post
How were these files created without similar ACLs? Is this due to platform or did the creators just edit the ACLs?
Like the difficulty associated with finding the absolute creation date of a file, it’s difficult to know how certain combinations of permissions find their way on files. One of your PDFs likely has inheritance enabled and the other does not. How this happened, we can only imagine.

If you use the newer Icacls instead, we’d be able to tell which of the permissions are inherited and which are not.

Quote   Quote: Originally Posted by tns1 View Post
Is it enough to add the missing BUILTIN users-groups to those files, or is there more?
Yes and no. I can't easily answer this without knowing the exact definition of ‘enough’. Does ‘enough’ mean the same permissions as PDF 1? Read (and Execute) and or Full control (as admin)? If that’s the case then adding those ACEs will most likely be enough. But if you do so you’ll be adding explicit permissions, not addressing the permission inconsistencies, only plugging it.

Quote   Quote: Originally Posted by tns1 View Post
If I make a local copy under XP, that copy includes the BUILTIN users-groups and has no access issue. I noted before this is probably the easiest solution, but still looking to understand it.
Copying a file doesn’t copy the permissions settings with it. The copy file gains a new set of permissions (inheritance) depending on where you copied the file to.

And using your ‘Take Ownership’ shortcut would be the easiest solution.

Quote   Quote: Originally Posted by tns1 View Post
Would the missing BUILTINs mentioned be 'authenticated users' or some other on the list?
I don’t quite understand your question. There was nothing missing.
My System SpecsSystem Spec
17 Apr 2016   #10
tns1

PCs: xp32, 7pro64, 10pro64, Linux
 
 

Quote:
Quote: Originally Posted by tns1
If I make a local copy under XP, that copy includes the BUILTIN users-groups and has no access issue. I noted before this is probably the easiest solution, but still looking to understand it.


A copied file doesn’t copy the permissions settings with it. The copy file gains a new set of permissions (inheritance) depending on where you copied the file to.

And using your ‘Take Ownership’ shortcut would be the easiest solution.

Quote: Originally Posted by tns1
Would the missing BUILTINs mentioned be 'authenticated users' or some other on the list?


I don’t quite understand your question. These was nothing missing.
From XP, copying these files to the 7P drive gave them identical properties as viewed under icacls:
BUILTIN\Administrators:(I)(F)
T AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Users:(I)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)

Had I instead first added the BUILTIN entities under XP, and then initiated a copy FROM 7P, would I have achieved the exact results?

Since these files were initially 'copied' to XP (downloaded or transfered from media), using the same acct, are sitting in the same location, and were never post edited, why do they not have the same access properties? WRT modifying access permissions, is a cut & paste different from a copy & paste, or move operation? Only the very last copy I did XP:(XP to 7P) seems to have 'standardized' permissions as per location.

If this is all basic stuff, is there a summary tutorial or set of exercises I could read? Thanks.
My System SpecsSystem Spec
Reply

 Ownership of foreign files - XP vs 7P access issues




Thread Tools Search this Thread
Search this Thread:

Advanced Search




Similar help and support threads
Thread Forum
Issues Transferring Ownership Of Old HDD Via USB Enclosure
So ive been having a very frustrating week trying to get info off of my old drive. Im currently running Windows 7 Ultimate x64 on my new SSD. What happened was about 2 weeks ago I started noticing signs of my drive failing. I had most everything backed up but not my app data and other user folders...
Hardware & Devices
Permission not granted to access files even after taking ownership
I have a 250gb hard drive from an old PC that has ALOT of pictures ,videos, and music stored on. The PC was running Window XP. It died and I removed the hard drive and bought an enclosure to install it in. I have it hooked to a newer PC running Windows 7. At 1st when I pulled up the folders with...
General Discussion
Ownership issues, restricted access and pure frustration.
Hello, so I'm currently writing on a laptop which is owned by a company. It's my dad's laptop and he asked me to install certain programs he needs for his work which are on multiple CDs. Even before he asked me I tried installing an antivirus and I couldn't because the access was denied. I let...
General Discussion
Windows files, folders and drive ownership issues!
So I formatted my system today and did a clean install of Windows 8 and now my USB storage drive says cannot access. I remember vaguely adding permissions or taking ownership to the files when I was on Win 7 but dont remember what it is I did exactly. I was trying to hide my files from other users...
General Discussion
File Ownership Issues after restoral
HI all, After restoring files from Acronis backup to a freshly installed Windows 7 Professional 64-bit system, I notice there seem to be some ownership issues. Hundreds of documents would now appear to not know they should simply open for the owner of the "my documents" and desktop folders they...
Backup and Restore
Took ownership, but still no access??
I got a problem, after i click take ownership, nothing happens i still doesn't have access to that file
General Discussion


Our Sites

Site Links

About Us

Find Us

Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd

All times are GMT -5. The time now is 20:56.

Twitter Facebook Google+



Windows 7 Forums

Seven Forums Android App Seven Forums IOS App