none
It is already opened exclusively by It is already opened exclusively by another user, or you need permission to view its data.

    Question

  • Hello,

     

    What are the correct permissions for a folder that contains a database that will be updated by an aspx page?  If I use the

    <identity impersonate="true" - In the web.config file the table updates.

     

    I'm unable to get my aspx page to update access database.  On my local machine the pages work.  On the live server the above error message comes up. 

    On the IISServer the IUSER has read/write/modify to the folder that contains the database.  And that doesn't work.  And the database is not open.

     

    Thanks

    Monday, February 04, 2008 6:52 PM

All replies

  • Impersonate true is not valid if you are using Windows authentication, granting only IUSER permissions is not enough because in Win2003 IIS6 Asp.net uses Network service account.  I am assuming you know Asp.net is also a member of the default everybody group so you leave that group alone in all folders.  Here are the permissions you need because IIS 6 comes locked down.

     

    http://msdn2.microsoft.com/en-us/library/kwzs111e.aspx

     

    http://support.microsoft.com/kb/812614

     

    Monday, February 04, 2008 7:14 PM
  • In which folder do you keep database? If you put it into App_Data application's folder, then I believe application will have
    appropriate permissions to access your file, but it will not be visible to outside users.

     

    Tuesday, February 05, 2008 12:07 AM
  • I've moved the database to the App_Data folder and the error is still the same.  System account ASP.Net does have read/write/modify to the App_Data folder and the Database folder.  But still the same error.

    Tuesday, February 05, 2008 8:21 PM
  • This is an IIS issue not a .net framework data access issue.

     

    I had the same frustration until I finally ended up using a fixed location SQL Server instead of an attached db.

     

    I know this doesn't help, but if you have access to a fixed location database on the server, you'd might as well as build the tables there.

     

    There are IIS support issues with attached db's.

     

    Adam

     

    Tuesday, February 05, 2008 8:31 PM
  •  Anonymous580822 wrote:

    I've moved the database to the App_Data folder and the error is still the same.  System account ASP.Net does have read/write/modify to the App_Data folder and the Database folder.  But still the same error.

     

    Here are the fixes for Access database from Microsoft support.

     

     

    http://support.microsoft.com/default.aspx?scid=kb;en-us;Q316675

     

    http://support.microsoft.com/default.aspx?scid=kb;en-us;Q317012

    Tuesday, February 05, 2008 8:37 PM
  • There are several factors that will determine whether your web application will be able to update the Access database. First, you need to determine which level of authentication your application is configured for (Anonymous, Basic, Integrated NT). Second, if impersonation is not enabled the account under which the application thread executes will either be the local ASPNET or NetworkService account, depending upon which Windows OS you are using. If impersonation is enabled then the account used will depend upon the authentication your web app has been configured for.

     

    In any event, the account under which your web application executes must have full permissions to the folder where the Access database is located. You can remove delete permissions for the .mdb file. Since it appears that your database is on the same machine as the web server then you won't need to be concerned with a delegation scenario.

     

    So the simplest (and least secure method) would be if your web application is not configured for impersonation and you're running under Windows 2003 Server, then the NetworkService account would require full permissions to the folder where the database is located in order to perform updates. If your web server is running under XP or 2000 then the ASPNET account would require these permissions.

     

    Wednesday, February 06, 2008 1:40 PM
  • I tried with the impersonation and it works if I put my name in, in an email format jslist@company.com and my password.  The network guy set up another account - supposed to be exactly like mine - and I tried with that but the same problem comes up.  I am working with an Access Database - I downloaded the Building Secure ASP.Net Applications book -

     

     

    Wednesday, February 06, 2008 4:13 PM
  • What level of authentication (Anonymous? Basic? Integrated NT?) is your application configured for?

    Wednesday, February 06, 2008 6:56 PM
  • If you are using Windows authentication impersonation true is not good practice because in IIS 6 the anonymous user is not a member of the default everybody group. In IIS 6 every thing is locked down you have to give correct permissions to network service account and create an authorization section for all your users in all folders. I am assuming you have run aspnet_regiis if you have not done that then do it could be the reason because it is not practical to deploy Asp.net application in IIS 6 without running it because if you did not click on details most features needed to run Asp.net is not added.

     

    So run aspnet_regiis and give correct permission in all the folders in my first post.

    Wednesday, February 06, 2008 7:50 PM
  • The authentication is Integrated NT.

    Friday, February 08, 2008 2:48 PM
  • Ok, so if Integrated NT is the only option selected (Anonymous is disabled) then setting the <identity impersonate> option to "true" in the web.config file will cause the web application thread to execute under the authenticated users account. If the authenticated users account has had been provided full access to the folder where the Access database is located then you should be able to open the database and perform updates from the web app.
    Friday, February 08, 2008 3:12 PM
  • Impersonate does work - if I load my credentials in:

    <identity impersonate="true" userName="myname@company.com" password="myPass" />

     

    If I use the account that was set up for this :

    <identity impersonate="true" userName="alterdata" password="myPass" />

    doesn't work.  And alterData has read/write/modify  to rights the app_data folder and the page still fails - what other rights

    does it need?
    Friday, February 08, 2008 3:35 PM
  • What happens if you omit the userName and password? This will allow the process thread to run under the authenticated user ID. I'm assuming that you're working with domain user accounts?

     

     

    Friday, February 08, 2008 4:15 PM
  • The standard error comes up

     

    The Microsoft Jet database engine cannot open the file '\\servername\folder\Track.mdb'.  It is already opened exclusively by another user, or you need permission to view its data.
    Friday, February 08, 2008 6:03 PM
  • I thought that the file you were attempting to open was on the web server. Is it actually on a remote computer on the network?

    Friday, February 08, 2008 6:09 PM
  • One can get that "exclusive" error if the service is unable to create the MS Access .lck file.  Mkae sure that your account in question has the correct ability to create the lock file in the directory with the mdb,

     

    Friday, February 08, 2008 8:43 PM
  • Use Server.MapPath()
    Wednesday, June 01, 2011 9:00 AM