I *still* can not believe I did this to myself!!!


Recommended Posts

Ok...this is going to appear to be a TOTAL AMATEUR job on my part...and I'm even ashamed of posting this, but I am hitting a brick wall on this issue.

 

I've been having some slight quirks on my Windows 10 system (Insider - Slow Track - Build 14965.rs_prerelease.161104-1700). I have a little utility that helps me streamline my workflow with multiple apps and frees me from having to hit the Windows key or click on the Windows Start Menu to get to apps. Well, this app took a nose-dive (and I'm trying to diagnose that separately), and I thought that it would be easier to just grab the icons from the requisite "Start Menu" folders. Easy, right?

 

Well, not so easy as it would seem, since the permissions for C:\Users\All Users\Start Menu were set such that I had absolutely *no* access to the folder, regardless of the fact that my main account on this box *is* in the Adminstrator's Group (I know, "playing-with-fire", etc - I follow good practices, Security, etc)

 

So, I attempted to take ownership of the said folder using the Advanced Properties sheets, and it appeared that it worked...but it didn't. So, in order for me to get things back and working, I reverted the folder back to SYSTEM ownership of the folder.

 

All's good, right. Oh, NO it's NOT. Now, when I go to the Prop sheet and Security tab for the said folder I don't even have Read permissions to view the PROPERTIES. Even going back and trying to take ownership of the said folder gets me nowhere, with messages indicating "Unable to display current owner" and the "Change" option highlighted. I enter either my AD credentials or my Local Account credentials, and am presented with:

 

An error occurred while applying security information to:

 

C:\Users\All Users\Start Menu

 

Failed to enumerate objects in the container. Access is denied.

 

If *anyone* has any ideas on how to fix this so that the proper security descriptors / ACLs are set for that folder & children, PLEASE let me know.

Link to comment
Share on other sites

Maybe take a look at cacls.exe or SetACL (don't remember the win 10 exe to be honest) from an elevated command prompt. You can google setting all from command prompt for more info.

Link to comment
Share on other sites

"C:\Users\All Users\Start Menu" is a hard link, and "All Users" is not a folder either, its a junction to "%ProgramData%" (aka C:\ProgramData).  Unless I'm incorrect in what you are looking for, you're actually looking for "%ProgramData%\Microsoft\Windows\Start Menu\" I believe.  Note that Windows Explorer does not have the ability to traverse hard links, only junctions, so you cannot enter the folder your trying to enter because its not really there so far as Explorer is concerned.

 

These types of links take on the permissions of what they are linked to generally, and you don't want to change the ACLS on these directly but the actual targets they redirect to. I mean, yes, they do have ACLS, but they should be treated as unique to the object without descending into the target and altering the real ACLS assigned to the real directories.  The ACLS on a Junction or hard links are really more there to restrict access to the original target via inherited rights. I'm sure it can be explained better, but generally, don't change the ACLS on subfolders your accessing through a junction.  Its a best practice type thing.

 

If your ACLS are really broken and you want to repair them, you may want to clone them from another copy of Windows using PowerShell's Get/Set ACL commands, at least for the junctions themselves.  Just beware of recursive changes on a Junction, it can really break things.

Edited by ITFiend
Link to comment
Share on other sites

 Sorry, I should have probably said symbolic link before instead of hard link, A junction was probably more what a hard link is in Linux land.  Been a long time since I really thought about any of it. :p 

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.