Cannot create files in C:\ProgramData\ even after granting Users group full permission

Question

We have an application which tries to write to an Access database (.mdb) in the C:\ProgramData\ folder. On computers with UAC enabled we find that accessing the database fails as it seems it cannot create the lock file. It seems that by default (and perhaps due to UAC) users (including admins) don't have permission to write to the applications folder by default.

We thought that granting the "Users" group full permissions to this folder would fix the problem, however it makes no difference. Even granting "Everyone" full control still doesn't help. The only thing which fixes the problem seems to be to move the database into another folder (eg C:\applicationname) which is not best practice OR running the application with Administrator privileges by changing the shortcut.

How can we make it so normal users can write (and create files) in the C:\ProgramData\ folder? Or are we misusing this folder? I was under the impression that is the correct place to put shared program data (for all users) and many other applications seem to have put their data there on my computer.

Update:

I have found that a clone copy of the database has been put in to following folder: C:\Users\\AppData\Local\VirtualStore\ProgramData\

If I delete this folder, the application then performs normally. Why was this folder created? Can I prevent this somehow? Could it be because the installer does not give adequate permissions to the Users group on the folder in C:\ProgramData\ ?

Otti

I am unable to recreate your issue. I created the folder "C:\ProgramData\myApp\" using my "Administrators" account and with the default permissions "Users" had read-only access. However, once I granted them "Modify" permissions on the folder then they could open the database and create the lock file. – Ammons

I can't reproduce it on my own machine either, but I CAN reproduce it on two different test machines and on a customer's computer. I'm not sure what the differences are between the computers as the folder permissions seem identical to me. – Otti

Answer 1

Could it be because the installer does not give adequate permissions to the Users group on the folder in C:\ProgramData\ ?

Actually, it is more likely that the installer did not have sufficient permissions to mess with "C:\ProgramData\" directly. (I thought that this scenario sounded familiar....)

When Microsoft introduced UAC they needed a way for older applications to continue working, at least for a while. What they came up with was "File and Registry virtualization", where legacy applications that tried to access (now-)verboten System folders or registry entries would be redirected to their own user-specific "virtualized" copy of those resources. As the Wikipedia article on UAC describes it:

Applications written with the assumption that the user will be running with administrator privileges experienced problems in earlier versions of Windows when run from limited user accounts, often because they attempted to write to machine-wide or system directories (such as Program Files) or registry keys (notably HKLM).[4] UAC attempts to alleviate this using File and Registry Virtualization, which redirects writes (and subsequent reads) to a per-user location within the user's profile. For example, if an application attempts to write to a directory such as "C:\Program Files\appname\settings.ini" to which the user does not have write permission, the write will be redirected to "C:\Users\username\AppData\Local\VirtualStore\Program Files\appname\settings.ini". The redirection feature is only provided for non-elevated 32-bit applications, and only if they do not include a manifest that requests specific privileges.[13]

If your installer requests "Run as administrator" privileges then you should be able to avoid this issue.

Ammons

So if the installer gives the C:\programData\appname folder User write permissions, will that prevent the "clone" copy being created in VirtualStore? (and therefore fix the problem?) – Otti

It should, if the installer runs with elevated privileges, because the installer would be creating a real "appname\" folder instead of a virtualized one, and then applying sufficient permissions so the other users can have read/write access to the one "real" folder. – Ammons

Is your edit definitely correct? How can an installer not have permissions? If it didn't run as admin, it wouldn't be able to install the app. Or am I misunderstanding? – Otti

That would depend on what specifically the installer was doing. Most "normal" installers need to run with elevated privileges (and hence trigger a UAC prompt, even when run from an account that is a member of the "Administrators" group), but in your particular case it may have simply run with the normal privileges for the user that launched the installer. – Ammons

The installer runs as an admin user. Oddly, I now can't reproduce the problem so I'm still very confused about exactly what causes it. If I try and repro it now, the database lock files simply get created in the VirtualStore folder and the application works fine. – Otti

When you run your installer do you get a UAC prompt like this? – Ammons

Any chance all the affected machines had previously run an earlier, broken version of the installer? Once the virtualized copy of the folder existed, it might interfere with the installer even once the original problem was fixed. – Louralourdes

Yes - it does generate that prompt. It's a standard installer created with InnoSetup. – Otti

@HarryJohnston Not sure what you mean by "broken" in this context? There is only one version of the installer and the problem happens on customers computers who've never used the application before. – Otti

Answer 2

I know this is old, and may not help NickG now..

But maybe for the next person, this:

1. Left-click on the folder
2. Select Properties.
3. Click Security tab.
4. Click Advanced.
5. Click “Enable inheritance” if disabled.
6. Click “Replace all child object…” check box
7. Click OK.

Source

Seems like a similar issue, and that solved it for him.

Wilt

Thanks for the late reply :) – Otti