We have our sites under a main folder we'll call call "d:\sites". "d:\sites" is shared as \server1\sites with read only access for our Dev and QA groups. I added another read only group to the share permissions (not NTFS) and the site started to recompile. I wasn't sure what I had just seen, so I did it on another server and the same behavior occurred.
We use dynamic recompilation, and I can't find a reference that says this should cause a recompile to occur (ref.[1]: http://msdn.microsoft.com/en-us/library/ms366723%28v=VS.100%29.aspx)
Has anyone else seen this, or know why it is happening?
If permissions are inherited from the parent, then adding this new permission changes the file. This change in the state of the file is picked up by IIS as a change, so the dynamic recompile is triggered. IIS treats even permission changes as if it was a change to the code base.
Related
I have an ASP.NET 2.0 application under IIS 8.5 in Classic mode where a page needs to write uploaded files to a folder outside the root of the app. When I first tired this I got something like
Access to the path 'D:\events\uploads\myfile.txt' is denied.
In the Security tab of D:\events I added "IIS AppPool/MyAppPool" and activated the Write permission. Everything worked fine then - as it should.
However, after removing the MyAppPool from D:\events again the same page was still able to write files under D:\events. Scary. A few experiments showed that that the page can now write files everywhere except C:\ C:\Windows C:\Users and D:.
UPDATE: To check which user or group might give access to IIS/ASP.NET I have created a folder C:\TestIISAccess disabled permission inheritance and gradually removed users and groups. Well, there are none left now, I can not even look inside the folder as admin. But my .aspx upload page reports it can still write files there. I have stopped & restarted IIS after all users were removed, makes no difference.
Can some please explain this behaviour and tell me how to cancel the write permission?
I have one server that works (that I originally remember took me a loooong time to figure out--dont remember solution). I copy the exact same permissions to the new server, and it does not work. 'Everyone' is given total permission.
I have given permissions to _IUSR, IIS_USR, and Everyone., yet I still have errors with PHP trying to write/modify files.
Whats up?
You didn't mention IIS version you are using and what's application you are trying to run on top of it - these would be helpful to get a proper answer.
Looking at account names you mentioned you are running IIS 7.x... If you are running app which requires some fancy permissions config on its folders and files just try to temporarily grant full access to Everyone and IUSR from the top of app folder (overwriting everything below it) just to verify that this is permissions problem indeed.
I thought I knew ASP.NET well, until a couple of hours ago. I am aware an IIS can recycle an app domain due to a variety of reasons including changes to web.config/bin/App_GlobalResources etc. file/directories, or otherwise on schedule or on specific events (like reaching a specific memory threshhold).
I was very sure my code was NOT hitting any of these conditions. Basically a regular http request would trigger a small task in a background thread (ThreadPool.QueueUserWorkItem) that woould lead to writing of a pdf file inside a sub-directory of my ASP.NET app.
This sub-directory had nothing that would qualify it for causing a app recycle. It was something like:
My Site\CompanyName\Mailer\UploadFiles
Please don't suggest reasons like configuration or bin directory change, the code is changing nothing in ASP.NET folders. Its writing to a pdf file inside a non-ASP.NET directory.
I used the Application_End event to figure out the reason of recycle (using reflection as suggested here: http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx) and got this:
_shutDownMessage=Directory rename change notification for 'd:\Projects\MyProject\trunk\dev'.
dev dir change or directory rename
HostingEnvironment initiated shutdown
HostingEnvironment caused shutdown
Directory rename change notification for 'd:\Projects\MyProject\trunk\dev'.
dev dir change or directory rename
I am practically stumped. I am very sure I have written code on other projects which writes under the app's sub-direcories without causing app recycles. But not in this case.
Am I missing something? Is it expected for IIS to recycle the app domain trying to write to any sub-directory of the app from the ASP.NET app itself?
There is a thingy called FileChangesMonitor which has a list of folders to watch and will trigger an app recycle if any of these change. It seems that as soon as a resource (an html page, an image, or, in your case, a pdf) is served through an HTTP request, the folder where it is located becomes an ASP.NET folder, i.e. is added to the list and monitored for changes. And it does not matter whether the resources are located inside or outside the application root. I experienced this problem with folder deletes, but I guess the same thing would occur with renames. This is frustrating, because it makes serving volatile static resources very difficult.
According to this article (method 2, item 6) I'm supposed to add computername\IIS_IUSRS as the role allowed to read my web.config file.
I'm not sure if it's true, though, because:
I've seen other web sites on the current server that don't have that set in security tab but still are accessible
more importantly, I still get the error 500.19 related config data invalid with extension config file insufficient permissions (0x80070005).
(At this point I'm only trying to serve a static HTML page, before I'll go on and also deliver web services.)
What am I missing?
Check every part of the directory tree in your setup. Make sure that every directory, subdirectory and file that you're trying to access, in fact, has the group IIS_IUSRS defined on your local machine (or the server, in fact). I'm betting my left ear that you'll find a part that hasn't.
The error you mentioned - 0x80070005 - means precisely that.
In case you still can't find the source of the issue, remove the whole directory tree and redo the whole setup process. Maybe there's some access right that's catched, then.
I just tested it on my system and I could cause the error you're describing by removing permissions of IIS_IUSRS from a subdirectory.
I've developed an ASP.NET v4 web app which I am trying to get to write to a folder in the webroot.
For the life of me I cannot get Windows 7 to allow it to write a file, I get Access is Denied error each time.
What I have tried on the folder is
attrib -r /foldernameandpath
attrib -r -s /foldernameandpath
Removing Check from ReadOnly attribute in folder properties
Changed owner to folder to current user whom is also the admin
Changed owner to Everyone
Adding Everyone user to folder with all permissions
Changing the folder to the Public Document directory
Changing to the root of the C drive (Out of desperation)
Nothing seems to work and all I want to do is test that the write works.
Now I know the system works and writes fine cause I had this same web app on a second machine writing the PDFs to the C drive without issue. This second machine I just cannot get it to allow the write.
Oh please for the love of all things holy, put the keyboard and mouse down and stop what you are doing. Some of the actions in your list seriously frightens me.
All the things you list as your actions are most likely useless or desperately random at best.
As a web developer, you shouldn't have to start messing around changing ownership of folders, especially not the web root folder normally used by the web server. When you do, you'll end up in a dark, cold and lonely place. Lord only knows what other desperate measures you have taken. For your own sake, I'll recommend you to do a system restore or even system reinstall to make sure you are in a healthy state.
Let's go back one step and try to sort out what you are doing.
First: what is the path you are trying to write to?
Second: are you running this application directly from within Visual Studio or in IIs?
If you are doing the first option then your current user account is the account who tries to write to the path in question. Do you have write permissions there?
One thing you can try is to start Visual Studio with elevated permissions and see if that works.
If you are running in IIs, it the associated pool account that needs write permissions.
Are you doing impersonation by any chance? If so, make sure the impersonated account have proper permissions.
You should only write to a predefined folder within your app path, like ..\App_Data for example.
The easiest way to find out which account you are running with and determine what path you are trying to write to, is to fire up SysIntenals process monitor and find the entry with the access denied result. Select properties for that entry and find out which account tried to do the write action. When you have determined that, right click on the folder in question and give the proper account write permissions.