I've just installed windows server 2008 r2 along with visual studio and dropbox. I'm using it as a VM for development and dropbox helps me keep my files in sync with other machines.
I've got my site set up in IIS but I'm getting an access denied error when trying to view the site. I've had this before and to get around it in the past I've gone through and added the IIS_User account to the list of permissions to read/modify the files. I assume because the file's have been copied down with drop box the files don't have the necessary permissions. Here's the bugger, I can't batch update the files by modifying permissions on a folder, I'm having to do it right to the file level and even worse, one at a time! I can't have this.
I'm relatively new to 2008 r2 and IIS 7 so I have no idea what's happening here. Can someone explain what is going on and if there's an IIS/file permission setting I can update to resolve it at the top level folder?
I've tried adding anonymous permssions on the website in IIS and I've added permissions on the folder for IIS_User (even Everyone). I have an Administrator account and that's already set to allow me to read/write/modify the files.
This is typically the message I'm getting 'An error occurred loading a configuration file: Access to the path X is denied'.
This is happening on ascx & aspx files as well as config files.
Edits:
The site is visible when debugging from Visual Studio.
The site is operating in Full Trust (internal)
Please help, this is stopping me from working and driving me insane!
By default in IIS 7, websites run as the local system's network account (NetworkService), not as IIS_User.
To verify, in IIS Manager, select the Site in question, click Basic Settings... and check the Application Pool it is assigned to. Then go into Application Pools and check the Identity for that Application Pool. Make sure that user listed is in the ACL.
Adding Everyone to the ACL should work instead, but just in case I would suggest you check the above. Also of course make sure when you set the ACL to check the box for resetting inheritance on all subfolders, if that is appropriate for your application.
You could also try setting the identity of the application pool to a local (or domain) user you have created which has access to your application directory.
Hope that helps.
Regarding whether other identities would work for your app pool, that depends entirely on whether those identities have permissions to all the files and/or databases and other resources you application needs to access. Right now you have the application running under your user account, which is generally not recommended. IIS has your password cached, and if you change it, your application will stop working until you update the application pool configuration.
As far as setting NTFS permissions, it can get tricky. Once you have disabled permissions inheritance, that file or folder will need to be updated individually every time you need a permission change. The flip side of this is that you cannot remove inherited entries on an ACL, you can only add to them. However you can design a strategy that offers a baseline level of permission at the root of a file structure, and then add permissions to subfolders/files.
In order to check & reset inheritance on a folder, go into its properties, security tab, click advanced, then click Edit. You can see whether this folder inherits permissions from its parent, and optionally wipe out all subfolder/file permissions and enable inheritance on all child folders & files.
Hope this helps.
Related
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
Error Code : 0x80070005
Config Error : Cannot read configuration file due to insufficient
permissions
When add new web application in IIS 7.5 and run it, this page shown to me, how to solve this problem win7 ultimate visual studio 2010
The message is clear.
Cannot read configuration file due to insufficient permissions
How to solve it.
Every asp.net application is run under one pool assigned to it, and each pool is run under a specific account.
Open the IIS, locate the pool under which your app is try to run, see the user that is assigned to that pool, and give read permissions to that user on your full site directory tree.
Especial for the web.config
The web.config, its the configuration file that message says, must have (and) write permissions.
So you locate web.config on the root of your site, right click on it, go to permissions and give on the pool-user, the write capability. The pool user, is the user under the witch the pool is run, as I explain below.
More details
To been able to run a public asp.net site with IIS, each file on the directory must have permissions for two accounts.
One account that is permitted for public access, and the account that assigned to that application pool have.
To find/assing the first account you go to your iis site | Authentication | Edit, and see or change it as you see on that screen shot.
Now note that name and we going to find the user under with the pool run.
Go the your IIS Site and click on the Basic Settings to find the pool name, then go to the IIS | Application Pools and see the Identity column, and note the name of the user under the witch your site is run.
Now that we have the two users names we go to the root of the site and set the minimum of permissions that is the read as
Some Notes
If the IIS_Public_ACCESS_USER is not give read permission the site is run, but ask for password
On some directories you need and write permissions, if you let for example your users upload images, or keep on App_Data, some database files. Only for that directories you give and the write permissions to the IIS_POOL_USER.
Some directories, like the App_Data and App_Code have direct protection from asp.net and they not allow anyone from the client side to run or view whats is in there.
On the public directory that allow write access to your user add one web.config and totally disable all the running of asp.net files.
More to read for the directories that give write permissions I've been hacked. Evil aspx file uploaded called AspxSpy. They're still trying. Help me trap them‼
It looks like your IIS_User doesn't have the necesarry permissions to access your website in C:\Users....\Visual Studio 2012\Websites...
Also make sure your application is running the correct .NET version (2.0, 4.0, ...)
I recently started an Orchard-CMS website. That's a new CMS which uses ASP.NET MVC 3. http://www.orchardproject.net you can find more info.
It has to be really easy to install a theme. But everytime i try that, i get the error that the dependencies.xml file is not accessable. (Orchard needs the dependencies.xml file, to write the links to new theme's and modules)
My site is running on an IIS7 local machine and i granted all permissions to the ASP.NET user and the NETWORK USER. But i still have permission-problems, any ideas?
By default the IIS 7 application pools run under IUSR account, so you should grant this user the appropriate permissions. From security perspective it's good to create a new, separate account for each application pool and I'd advise you to do so. It'll also give you more fine-grained control.
Also, check whether the permission changes were correctly propagated to App_Data and App_Data/Dependencies folder and their content. If not, change permissions for Dependencies folder explicitly. I've noticed that sometimes they don't get propagated correctly if you change permission at the root level.
Our asp.net app writes errors to a text log file in the web sites root folder. This has lead to all sorts of permission problems, different flavors of IIS and windows allow different things by default.
So what I am wondering is there a location somewhere in Windows where all types of users can write a file without any extra permissions that will also work for all IIS and flavors of windows?
I am thinking of the ApplicationData folder, but did this exist in Server 2003 ?
Thanks,
AJ
The easiest solution would be to use the App_Data subfolder of your web application for this. By default it's not viewable from the web, so Internet clients won't be able to read the logs.
Depending on your deployment method, you might have to change the permission to allow write access to this folder (to the user under which your web application is running).
Alternatively, there is a place where every user can write to: It's that user's temporary folder, which you can access through Path.GetTempPath. This, however, does not sound like a suitable location for log files.
You should always first think about wwwroot folder (%systemdrive%\inetpub\wwwroot) because it has the required permission.
The permission you need is to set a full control for IIS_IUSRS
Edit: you can simply give Everyone Full Control (not recommended at all) but this solves most of ntfs permissions issues with IIS
We're having trouble migrating our ASP.NET applications to Windows Server 2008 R2 x64 and IIS7.5. The problem is that our ASP.NET apps write log files, and these log files are not being written. The only way the apps write their log files is if I'm logged into the server as the local Administrator user or if I right click and run IE as Run as Administrator, neither of which is an acceptable solution for us.
Our platform is:
Windows Server 2008 R2 x64 (UAC setting is the default setting)
IIS7.5
ASP.NET 4.0 (using Windows authentication and impersonation, both on in web.config)
Our app gets installed to:
D:[appname]
[appnameWebSite] (all the .aspx, .dll, etc. files are in here)
\Log (the app tries to write the log file to this folder)
On the server:
Created new App Pool (name: [appname], .NET 4.0, Managed Pipeline Mode: Classic, Identity: ApplicationPoolIdentity, Load User Profile: False, all other properties are the defaults)
Created IIS application pointing to D:[appname][appnameWebSite] and added it the the new App Pool (Full trust level)
Have a domain user in local Administrators group
With all the configuration and default settings listed above, the ASP.NET app will not write the log file. The app appears to work fine in the browser, but no log.txt file.
To try to "fix" this issues, we've tried many things:
Tried Application Pool setting: Managed Pipeline Mode: Integrated
Tried Application Pool setting: Identity: NetworkService
Tried Application Pool setting: Identity: LocalSystem
Tried Application Pool setting: Load User Profile: True
Gave Users group full control to file system for our application folder structure (tried appname folder, tried Log folder only, tried appnameWebSite and Log folders only)
Gave IIS AppPool[appname] (matching the new App Pool) user full control to file system for our application folder structure (tried appname folder, tried Log folder only, tried appnameWebSite and Log folders only)
None of these things helped. Again, the app would run fine, just no log file created.
As mentioned above, the only way that the log file is created when the app runs is if we log into the server using the local Administrator account (which makes sense since he's a super user) or if we run IE as administrator and elevate privileges.
Any suggestions? Help? Questions?
Thanks!
I tried granting every permission possible and still wasn't getting any log files. Finally I came across this which suggested changing the ownership of my logfiles directory. I checked, and the directory ownership was set to SYSTEM. I changed it to Administrators and applied the change recursively. I bounced IIS, hit a webpage from the site in the browser, and now I have log files. Hooray!
Note: the thing that tipped me off was checking the System event log. I was getting 15006 errors saying "Owner of the log file or directory C:\inetpub\logfiles\W3SVC1\some.log is invalid. This could be because another user has already created the log file or the directory."
Well, after days of trying every IIS option, user and group accounts, file system permissions, Process Explorer, etc., I think we got it working:
We reset all our IIS app pool and web site settings to their default values
We also reset the folder/file system permissions on our Log folder to the default settings
Then we turned off Internet Explorer Enhanced Security Configuration on the server
And success! The log file is written as expected no matter what user is using the ASP.NET application, and no matter if they're running it on the server itself or from a workstation.
I don't know if turning off Internet Explorer Enhanced Security Configuration on the server is the "correct" thing to do or if it violates any best practices, but it seems to work for us.
Does anyone have anything to add?
I struggled with this one for a while. The ApplicationPoolIdentity is a member of the Users group and the Users group has limited access.
From Explorer, right-click on the folder where you are trying to write and go to Security. Click the Advanced button. you will see that Users have Read and Execute permission and the Users group may or may not have Special permissions. If not, Click on Change Permissions and give Users the ability to Create files / write data and Create folders / append data. This is restricted to this folder. I usially use a subfolder so that I not provide write access to my whole website.
Try creating log files again. This is the only permission that I needed to set to make it work.
For me the trick was giving write access for SYSTEM and Administrators not only to the log folder itself, but also every folder in the path. This is not how permissions usually work in Windows, but IIS appears to be really rather particular about it. Not that there is a good reason to remove these two from the ACLs to begin with.
If you suspect this to be the problem, check the Event Log under Windows Logs / System. This issue manifests itself as an Error entry from source HttpEvent, and reads "Unable to create log file C:\path\to\logs\W3SVC1\u_extend1.log. Make sure that the logging directory is correct and this computer has write access to that directory."
P.S. This is true for IIS 10 but may apply to other versions too.
Setup
There is an IIS 6 application running in a .NET 2.0 App Pool on Server-A. IIS 7 Server-B needs to host that same code-base under a different URL. I created a virtual directory under Server-B's website to the network path of the application on Server-A. I've enabled this virtual directory on Server-B as an application running in its own .NET 2.0 App Pool in Classic Mode. Both app pools run as the same domain account that has access to that folder.
Issue
When accessing the site from Server-A it works fine. Accessing it from Server-B however generates the infamous "Required permissions cannot be acquired." error.
I have been trying to find a solution to this problem for two days. The two most common solutions have been to check the CLR Trust level on the Server-B box or to set the Load User Profile property on the App Pool to "True". Since I have full administrative rights I set the Trust level to Full and set the profile sitting to "True". Strongly naming all the assemblies the application and throwing them in the GAC is not where I want to go.
I'm sure I'm just missing some configuration somewhere. Any ideas? Thanks.
We have had a similar problem once.
In our case the user that was the identity of the app pool have never logged on to the server. Therefore, there was no local user profile, therefore there was a problem when the system tried to use the profile.
As a test try and set the identity of the app pool to the admin account you use to log in with.
Manually verify that user can access that share. Try logging into windows as that user and then accessing that share (or fake it with something like a "runas /User:{Domain\UserName} net use {\server\share}").
Also try loading ShareMonitor wherever the files actually live. It should tell you what user account is trying to access a given share. It might not be the account you think it is. I cannot recall if it was this program or not, but I have used something very similar in the past to figure out a really odd permission problem.
That should determine if it is a file access problem. If it isn't, then all I can say is to make sure you have ASP.NET enabled (on windows server it is a separate option).
Also check out the file permissions on your "Temporary ASP.NET Files" directory. I've had to explicitly add users write access to that before to get things working.
in my case my IIS App Pool had LoadUserProfile=false, so it was not loading the profile of the app pool's Identify (a domain account). This caused this unable to acquire permissions even though my Webroot files/folders (including /bin) had correct permissions. Setting LoadUserProfile=true fixed the issue for my setup.
I would set that application pools identity attribute (in advanced settings) as administrator. That way, you application will work on the server, just like it works on the local setup.