K
Ken Kolda
I'm using IIS 6.0 to try to run an ASP.NET application the files for which
live on a shared folder on a machine which also happens to be on a different
domain. I setup the system as follows:
* The network share grants read permission and the ACLs on the files are set
so Everyone has full control.
* In the "Connect As" options for the virtual root, I've left the checkbox
checked that says "Use the authenticated users credentials...".
* I've disable Windows Auth on the virtual root so onlt only anonymous
access is permitted. It's using the default IUSR_MACHINENAME account.
* The web app runs in the DefaultAppPool, which is configured to run under
the Network Service account.
Under this configuration, I get the following error:
Exception Details: System.UnauthorizedAccessException: Access to the path
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET
Files\aspnet2\bf425c49\629f372a" is denied.
What I've found is that if I change the IIS anonymous user in the virtual
root to be a user in the IIS_WPG group (or anyone who can write to the
Temporary ASP.NET Files folder), then I get past the above error and can
verify the web app's folder is created. It's almost as if it's trying to use
the anonymous user's credentials when creating the shadow copy folder, which
I don't understand and seems inconsistent. If I run the exact same web app
off a local drive it's able to create the temporary folder even using the
default anonymous user.
That said, let's say I use a different user account and get the temporary
ASP.NET folder created. The next error I get is:
Could not load type 'APIProject.Global'.
(This is the class that provides codebehind for global.asax). What's
interesting is that it can clearly read this file from the network share
(which I would expect since the app's running as the Network Service user).
If I look in the Temporary ASP.NET folder I can see that the assembly has
been copied to it. So now the question is why can't it load it? There's no
indication this is a permission problem, e.g. due to the assembly coming
from a network resource, but I can think of no other explanation.
If anyone has any suggestions/ideas, I'd greatly appreciate them.
Thanks -
Ken
live on a shared folder on a machine which also happens to be on a different
domain. I setup the system as follows:
* The network share grants read permission and the ACLs on the files are set
so Everyone has full control.
* In the "Connect As" options for the virtual root, I've left the checkbox
checked that says "Use the authenticated users credentials...".
* I've disable Windows Auth on the virtual root so onlt only anonymous
access is permitted. It's using the default IUSR_MACHINENAME account.
* The web app runs in the DefaultAppPool, which is configured to run under
the Network Service account.
Under this configuration, I get the following error:
Exception Details: System.UnauthorizedAccessException: Access to the path
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET
Files\aspnet2\bf425c49\629f372a" is denied.
What I've found is that if I change the IIS anonymous user in the virtual
root to be a user in the IIS_WPG group (or anyone who can write to the
Temporary ASP.NET Files folder), then I get past the above error and can
verify the web app's folder is created. It's almost as if it's trying to use
the anonymous user's credentials when creating the shadow copy folder, which
I don't understand and seems inconsistent. If I run the exact same web app
off a local drive it's able to create the temporary folder even using the
default anonymous user.
That said, let's say I use a different user account and get the temporary
ASP.NET folder created. The next error I get is:
Could not load type 'APIProject.Global'.
(This is the class that provides codebehind for global.asax). What's
interesting is that it can clearly read this file from the network share
(which I would expect since the app's running as the Network Service user).
If I look in the Temporary ASP.NET folder I can see that the assembly has
been copied to it. So now the question is why can't it load it? There's no
indication this is a permission problem, e.g. due to the assembly coming
from a network resource, but I can think of no other explanation.
If anyone has any suggestions/ideas, I'd greatly appreciate them.
Thanks -
Ken