Cannot delete files owned by "Administrators" group

Mystere said:

The difference is in the default permissions of files and folders between XP and Vista, not the privileges of the user account.

In XP, Program Files, Windows, etc.. had default permissions that allowed Administrators to do whatever they wanted. In Vista, this was tightened up. Program Files, for instance, became owned by "TrustedInstaller" instead of Administrators.

Regardless of the technicalities (which most users couldn't care less about) an XP Administrator could accomplish tasks with significantly less clicks, than a W7 Administrator.

Mystere said:

If you're talking about UAC, then that's something different. UAC is widely misunderstood. UAC doesn't limit people or prevent anything. UAC actually *ALLOW* you to do things you otherwise couldn't do.

When you enable UAC, you are really doing three things. First, you're enabling "low-rights" mode. This gives all users, regardless of their actual user groups (with the exception of a few internal accounts) the minimum rights needed tor un applications. In other words, it treats them like a "standard user" even if they are in the Administrators group. This is not UAC itself, but rather a side-effect of enabling UAC.

The second thing it does is provide tools to elevate you to your REAL assigned privilege level upon request. This is the ACTUAL UAC.

I am aware of the "twin security token" system.

Mystere said:

That's also incorrect. Domain Administrators are no different from Local Administrators, except they also have rights to network resources.

There is some confusion here (probably due to my bad phrasing):

• Domain Administrators need to have access to all network resources to be able to manage the network
• Local Administrators do not

Mystere said:

Once again, that's incorrect. The Administrator group, does in fact have this ability. The built-in administrator has this right also, because they are also in the Administrators group.

That does not explain why users can fix problems using the built-in Administrator, when they can't fix problems despite:

• Owning a resource
• Having Full permissions
• Having child objects set to inherit those permissions

There have been multiple threads on SevenForums where this has happened.
I find it unlikely that:

• Every reported instance of this occurring has been PEBKAC
• Users have set the additional specific permission restrictions on themselves.

Mystere said:

Yes, you can set the owner to TrustedInstaller. However, you have to use a slightly different syntax for the user. "NT SERVICE\TrustedInstaller" rather than "TrustedInstaller", which is because TrustedInstaller is not a "real" user, it's what's known as a Managed Service Account. Windows has a number of these.

My bad.

Five years ago I couldn't find any useful information about this.
After spending considerably more time than a clean install would take, I gave up and performed a clean install.

Thanks for this tip. :)

Mystere said:

Adding "Administrators" to your user account does not grant you the knowledge to be an Administrator. You must still know how to do the functions you need to do, and many of those functions will be esoteric or not known by most people.

I'm not quite sure what you are trying to say.
The user account created during install, is part of the Administrators group (in W7 at least).

Obviously simply changing an account to Administrator doesn't magically endow someone with knowledge they didn't previously possess.

Nonetheless it seems you have never come across this issue:

• X owns a folder
• X has Full permissions
• X's permissions are applied to child objects
• Windows will not allow X to access the folder

I see it once or twice a year.

The other variation is when you attempt to take ownership and Windows refuses to apply the changes.
The most recent example of this happening to me was a few weeks ago in W10 (during my search for the Lock Screen wallpapers).

W10 refused to apply the new ownership to a least one child object and displayed the "security enumeration failure" warning.
I was unable to open the folder to view its contents.

I rebooted it and tried again.
Again I received the "security enumeration failure" warning, however despite this I was able to open the folder and view its contents.

Mystere said:

As for Linux, it's because Linux ignores all permissions.

Linux ignores NTFS permissions.
However despite what Linux "Fan Boys" claim, it is not bulletproof either.

There are files in my Home directory that are owned by "root".
Given they are config files for certain applications, it appears those application have been incorrectly written.

When I upgraded from LM17 to LM17.1, I tried using the Home directory backup/migration tool.
After installing LM17.1, I used the tool to restore my Home directory.
The permissions were randomly screwed up.
I ended up performing another clean install and manually copying my files to my new Home directory.

When I mentioned this on the LM forums, other members reported the same experience.

Mystere said:

While that may be true, it doesn't change the fact that XP Administrators had no more rights than Vista, 7, 8. 8.1 or 10 Administrators. I was explicitly addressing your claim that XP's administrator had "supreme power", which it did not. My point is that nothing in the OS itself has changed in this regard, only the configuration of the default permissions. My point is that nothing in the OS itself has changed in this regard, only the configuration of the default permissions.

You are correct about the Windows permission settings. :)

I should have been more specific.
By "supreme power" I meant that I never had to change ownership/permissions to do whatever I wanted in XP, regardless of the technical reason for that.
So by my definition, an XP Administrator, by default, had more power than an Administrator of a later Windows OS.

For a W7 Administrator to do what an XP Administrator could, they have to change ownership and/or permissions on various objects.

Mystere said:

Domain Administrators do not have access to all network resources, only those which Domain Administrators have been given permission to access. This is no different than local administrators. Domain Administrators can be denied access to resources in the exact same way.

My bad (again).

I was referring to IT policy, not Windows permissions.

Mystere said:

Sometimes the problem is that the resource is locked because it's in use. Sometimes the problem is that a folder has the "Inherit parent permissions" disabled. You get into a situation where the UI can't just recursively scan down the tree and reset the inheritance properties. Sometimes objects have 'special' permissions set, and you have to go into Advanced security settings and reset those permissions in order for the UI to cascade those changes.

Those points could certainly explain many oddities, but I'm not sure that they explain all oddities.

I have various other hypotheses, including random glitches, file corruption/damage and bad software behaviour.

Mystere said:

It's completely possible to override all these situations, it's just not always obvious what the problem is because the UI is not always smart about it and can't always automatically reset things. You have to go in with command line tools to reset the permissions.

I've always had more success with the GUI, than the Command Prompt, when it comes to attributes/permissions.
Off the top of my head, I've only used "attrib" (100% success rate) and "icacls" (~20% success rate).

I did have to execute some PowerShell commands in my Networking course.
They were from the text book, so they had a 100% success rate.

In Linux Distros, I always have to use the Terminal to set permissions (the GUI tool is totally unreliable).

Mystere said:

As for why it would work with the built-in administrator, most likely because you're logged in as a different user, which causes the lock to be released. You could just as easily log in with a different Administrator account than your primary one and probably do the same.

If a PC has more than one user account with Administrator permissions/rights, that hypothesis should be easy to test.

Of course by the next time it happens, I'll have forgotten all about this.

Mystere said:

You cut off part of what I said. I was saying that "Please contact your administrator" really means "Please contact someone who knows what they're doing", not "Please contact the person who has been assigned the Administrator security permissions".

This was in response to your comment about contacting the administrator when you're the administrator. The point being, if you don't know how to fix it, or know how to find the solution to fix it, then you should be contacting someone that can.

OK now I follow your point. :)

Mystere said:

No, what you have come across is a situation where the UI is not showing all the permissions for the folder. In reality, there is a permission set that isn't allowing you to make the change in the UI. You have to do it at the command line level to see what the real problem is.

You are suggesting that one or more of the lower level restrictions had been set (e.g. no traverse)?

Mystere said:

I agree that XP and earlier let you do pretty much anything you wanted, so long as the file wasn't locked. And that was a huge problem. One might argue that the new permissions model just creates a new set of problems, and that's true. But systems are definitely more stable these days than they used to be, and I can attest that XP gets malware infestations a LOT easier.

I believe that is why the ownership/permissions/rights system was changed in Vista (and onwards).

I can also recall reading one post from an XP user, who decided to "tidy up" their System32 folder (which trashed their install completely).