Windows 10: Win 10 (10240) Upgrade Keeps Apps From Accessing Their Settings

The title "Win 10 (10240) Upgrade Keeps Apps From Accessing Their Settings" is my impression of what is happening. The reasons are:

• Skype won't login and it tells me it can't access the profile folder. If I try to browse to C:\Users\username\AppData\Roaming\Skype I get a prompt "click continue to permanently get access to this folder"
• Firefox tells me the profile folder is missing, but it is there, it just can't access it (it wasnt as smart as skype to tell me it is there, it just can't access it).

Some applications go thru their initial preference setup process every time they are started:

• Greenshot
• NetSpeedMonitor
• Winamp 5.666 (this one won't even start, it just loops thru the initial setup).

I even uninstalled and reinstalled some of these apps, but the problem persisted.

I've disabled UAC. Then I re-enabled it to see if for example Skype would cause a prompt to access its profile folder. This made no difference.

I ran an SFC scan, but "Windows Resource Protection did not find any integrity violations".

I reset the permissions and enabled inheritance for C:\Users\username\AppData\ to full control for administrators, my_username and SYSTEM. A few files in there couldn't be accessed (failed to enumerate objects in the container. access is denied), so I cascaded ownership of the folder to my_username (still failed for some objects, such as Malwarebytes, but this might be by design as MBAM is a pretty well built piece of software). Then i tried to cascade permissions again. Some folders still gave me the: failed to enumerate objects in the container. access is denied.

To reiterate, everything worked fine under win7 before the upgrade. After the upgrade, it only started working after the permissions reset steps above. Have others encountered the same problem?

The main point to this post is serve as guide to other people who encounter the same problem. But in order to do so, please inform if the permissions outlined above are the proper permissions for 100% of objects in C:\Users\username\AppData\*. I will update the post accordingly.

TIA

:)

 

Homegroup problems in Windows 10

Windows 10 Home Build 10240. Updated from Win 7. Entered Homegroup password and system set up Homegroup. My 3 other Win 7 systems can see/access/modify the Win 10 system drives with no problem. The Win 10 system cannot access or see the drives on the
Win 7 systems. All these systems are on a wired network.

 

MCT for upgrading Windows 10 1151 10586 does not let me save files and apps...?!

Hi,

I have a dilemma on upgrading from 10240 to 10586...

as for the Win Update @ Setting>Windows Update keeps on failing..

did all the things I could find from google and MS community (sfc /scan, and everything else)

so I came to the conclusion of using Media Creation Tool and then this

problem occurs that it won't let me save my app and files from the choices.

so that's about it.

Hope someone can help me sort this out...

P.S. I don't wanna do another clean install as I have been doing it since Win 10 had been released in order to just upgrade from

Win 8.1

thanks.

 

Hi there

Looks like I had the same problem, or, something pretty similar.
Yesterday I installed a Win 10 Pro v10240, and when I tried to copy/paste stuff into any AppData/Roaming folder I had an access denied box that would pop up.

So I tried
- to delete a file -> it was working
- to rename a file -> working
- to create a file -> working

This was insane. *cry
Why does the copy/paste don't work?! It's an aggregation of these rights!

So I ended up deleting the file I wanted to replace, then I created an empty text file, then I renamed it to the target, and I filled the file up with what I wanted.
That was for some Opera browser configurations that were text files.

Then I had to do the same for Firefox, but this time for a binary file. Copy/paste was triggering an access denied as well. And this time, I didn't feel like hitting my hex editor to just ... you know copy/paste the contents.
So I opened up a cmd as administrator and made copy that way. And behold, it worked fine.

UAC was disabled and the current user was the only one. And he was an administrator.
Also this account was a local machine account, not an m$ account.

And something else: both Firefox and Opera were working fine and were writing stuff in their respective folders. And of course they were not started as administrator. They were just started like that without hacks.
That was just ME not being able to copy/paste stuff. Crazy.

I don't remember if I checked the AppData folder permissions, but that was after a fresh Win10 install. So it's not like I was trying to reuse an existing AppData folder that had faulty ACLs.

What I think happened, in my case, is that the file I wanted to copy was still having the old ACLs on it. And perhaps Win 10 is be checking these stuff when copying a file say, from User A to a folder belonging to User B and it would refuse the copy? Like, it was the source file ACLs that ... had something wrong? I dunno, I gotta investigate.

So pretty much for me it's the same problem as you but in the 'opposite' effect: my apps can access their appData, but the win user itself can't fully. *Huh

 

Reporting back here.

My problem was that the files I was trying to copy/paste were from another NTFS partition (an USB disk) that had different ACLs.
And the weird stuff is, Win10 seems to check the source file ACLs (the one being copied) against the target folder ACLs. If they're not the same or something it will throw an Access Denied. I'm really not sure what ACL is causing this error.

So I pretty much had to completely "reset" the ACLs on my USB disk, but not on my Win10 partition...
And to make things worst the "reset" ACLs commands that can be found all over the net; using takedown and icacls were not working fully: I still had some Access Denied popping in the cmd window for some folders.

But a dude on a StackEchange has the right magic to reset the ACLs properly:
SetACL.exe -on %target% -ot file -actn setprot -op "dacl:np;sacl:nc" -rec cont_obj -actn setowner -ownr "n:S-1-5-32-544;s:y"
SetACL.exe -on %target% -ot file -actn ace -ace "n:S-1-5-32-544;s:y;p:full"
Credits to this awesome guy.

From there on, I could enjoy copying and pasting stuff from and to my UBS disk again...

One last thing, to make sure I had to proper rights to do the above commands, I enabled the Administrator account and did all of this from its session. Overkill but I wanted to get rid of this insane issue for sure.

 

Would you please link to that SO answer?

You can also use Code: SetACL -on D:\ -ot file -actn delorphanedsids[/quote] to remove orphan ACLs. I also had to run this on all my drives (except C, do not run this on C).

Keep in mind that SetACL hasnt been updated to properly identify some of the accounts that exist in Win10 - it believes that the ACLs are orphans (you can see this if you run the 1st, 2nd and 3rd commands on the blog post) but if you open them in the security manager you will not see any orphan ACLs (as in they all have names, none of them are just numbers and letters).