12

I am getting the error:

Module  IIS Web Core
Notification    Unknown
Handler Not yet determined
Error Code  0x80070005
Config Error    Cannot read configuration file due to insufficient permissions
Config File \\?\C:\inetpub\wwwroot\web.config

The file itself has full permissions for IUSR. IIS is running its app pool under ApplicationPoolIdentity. I did a file monitor on the file, and I see this:

9:04:43.8035456 AM  w3wp.exe    8104    CreateFile  C:\inetpub\wwwroot\Web.config   ACCESS DENIED   Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, AllocationSize: n/a

No idea why I am getting this error... Any ideas?

Sugitime
  • 1,818
  • 4
  • 23
  • 44

6 Answers6

21

Try giving read/write access to these accounts to the root folder of your Web application and all files/subs within:

NETWORK, NETWORK SERVICE, and of course IIS_IUSRS

Lawrence Johnson
  • 3,924
  • 2
  • 17
  • 30
4

I found that adding the mymachine/USERS with full permissions to C:\inetpub\wwwroot fixed the issue.

The problem was caused because I shared some sites content inside C:\inetpub\wwwroot with other developers. This must have changed permissions and broke my IIS completely.

learnerplates
  • 4,257
  • 5
  • 33
  • 42
0

First, make sure IUSR has Read permission on the config file (which I believe you have done that)

Then, change IIS authentication method to BasicAuthentication

If still not working, probably the .config extension is not properly installed in IIS.

Try all 3! Good luck!

EDIT: Forget to ask you, what kind of appliation is it?

HOKBONG
  • 795
  • 7
  • 17
  • Its a .Net web service (ASP.Net 4.0) IIS has BasicAuth and AnonymousAuth turned on and the file does have read perms for the IUSR. I'll check the IIS config for .config extensions now. – Sugitime Oct 04 '12 at 16:21
  • I did an aspnet_regiis then iisreset. Still getting the same error. – Sugitime Oct 04 '12 at 16:24
  • Can you also try grant permission to your whole app directory? – HOKBONG Oct 04 '12 at 16:59
0

I just came across this and was unable to find applicationpoolidentity as an account in order to add it to the folder security. I changed the application pool identity from applicationpoolidentity to Local Service and the site ran fine.

Jay
  • 1
  • 1
  • 2
    As an fyi, this has security implications. If there is a flaw in your application, and the server gets compromised, the LocalSystem account basically has admin privileges. Consider the Principal of Least Privilege and create a new limited user. https://en.m.wikipedia.org/wiki/Principle_of_least_privilege – Sugitime Jun 30 '15 at 03:23
0

I was copying a live WordPress site to my local machine for editing/updating when this IIS error occurred. Changing permissions did nothing.

In my case, simply deleting the web.config did the trick.

PeterS
  • 1
0

I ran into this issue again today. This time, no amount of granting permissions worked (tried all the usual accounts, everybody, read-only, modify, full control).

Closed processes, restarted IIS, full reboot. No results.

Eventually changed the owner from "Administrators" to myself, and things fell into place.

I usually run Visual Studio at Admin level (using my own account) because I like to use the local IIS for hosting / debugging ASP.NET sites. Perhaps that caused new files to be owned by \Administrators, which in turn may have limited access to those files by the IIS or App Pool processes.

My DefaultAppPool identity is set to load the user profile. I don't know at what point the session manager applies UAC / permissions drops and whether user profile loading has any influence on this. Food for thought...

Mayyit
  • 413
  • 5
  • 10
  • You more or less answered your own problem in the last paragraph. If you set a specific identity to your Application Pool, you need to make sure that identity has the proper permissions to access the files, but this can have other byproduct problems depending on what Windows version you're on. If the identity specified has login credentials, for instance, you could end up requiring that user to be logged in for it to work. – Lawrence Johnson Dec 01 '18 at 22:42
  • @LawrenceJohnson Essentially, but... in this case, the App Pool *had* permissions to the files. However, I think the problem was that the files were also owned by \Administrators group, which restricts access (at least in Explorer) to a non-elevated session. I haven't been able to find specific reference of how this behaviour manifests with respect to a non-logged in user, the AppPoolIdentity (no explorer? how about general UAC?). Simply replacing \Administrators from ownership solved the problem. – Mayyit Dec 05 '18 at 10:45
  • Hmm, interesting. It could maybe be a security policy set on the machine that does that. – Lawrence Johnson Dec 05 '18 at 17:39