可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I have setup a application in my IIS7 that uses .NET Framework 4.0 (runned by NetworkService) but when browsing the site I get this:
Access is denied.
Description: An error occurred while accessing the resources required to serve this request. You might not have permission to view the requested resources.
Error message 401.3: You do not have permission to view this directory or page using the credentials you supplied (access denied due to Access Control Lists). Ask the Web server's administrator to give you access to*
I have tried to give NetworkService full permission on the folder that holds the website (the one that the web application in IIS is pointing against) but I do still get the access denied?
Why?
回答1:
I gave access to "IIS_IUser" but instead it should be "IUSR". That solved the problem.
回答2:
For me, nothing worked except the following, which solved the problem: open IIS, select the site, open Authentication (in the IIS section), right click Anonymous Authentication and select Edit, select Application Pool Identity.
回答3:
I had the same problem, I enabled "Anonymous Authentication" but it still did not work.
So I also ENABLED "Forms Authentication" Then it worked without any problems.
回答4:
OS : Windows 7 & IIS 7
If you still have permission denied after adding IUSR & NETWORK SERVICE.
Add also IIS_WPG. The addition of this last user solved my problem.
For people who can't find those users:
when you're trying to add a user in security of the folder (properties of the folder), click on "Advanced" of the window "Select Users or Groups". Change the location to the computer name then click on "Find Now". You'll find those users in the list below.
回答5:
For me in windows 7 it started to work only after I gave 'Read & execute', 'List folder contents', 'Read' permissions to site folder for both users
回答6:
In the Authentication settings for APP itself (IN IIS), see if you have anonymous enabled.
回答7:
In my case running c:\windows\Microsoft.Net\Framework64\v4.0.30319\aspnet_regiis.exe /i resolved the 403 access denied issue.
回答8:
It was due to WWWRoot directory security issue.
Simple solution is, Just copy applicatio folder to some other drive, Instead of "C:\Inetpub\wwwroot"
and then create a virtual directory for this new path. That's it.
回答9:
We need to create a new user ComputerName\IUSR by going to the website folder-->Properties--->Security--->Edit-->Add and give read access. This would work definitely.
This solution is for IIS7
回答10:
If you're using Anonymous Authentication, IIS 7 will use the "IUSR" account for directory access (unless you've set it to use the app pool identity. If you haven't granted IUSR sufficient permissions on your site's folders and files, you'll get this error
回答11:
I went round and round on this and it turned out to be improperly set default page. Hope this helps someone else avoid an hour of wasted time.
回答12:
Tried most of the solutions here, but no luck. What worked for me was adding "Everyone" to the security permissions. Properties -> Security -> Edit -> Add -> Everyone. The given defaults were enough for me to regain access.
In the near future, I should probably figure out what credentials are being sent to the server so that I can give proper permissions. But I hope it helps someone!
回答13:
If the IUSR user is already specified in Authentication and you're still getting this issue, it could be that your Directory Listing isn't enabled. Be sure to check that. That was the case for me.
回答14:
This is what happened to me:
Get
- Post
is ok. Working well.
When I try to use Options
verb, the server return error like that.
Then, beware with urlScan
I add OPTIONS verb to urlscan configuration .ini file, then everything works well.
To check if urlscan is installed or not, open your iis manager, and open ISAPI FILTERS
url scan should appear at the list.
回答15:
After some thinking and a lot of of trial and error I found out that this error occurred because part of my web.config was encrypted and for some reason the key was no longer valid.
Re-encrypting the config section solved the issue.