Unable to connect to Access database on mapped drive

[ryDen]

Hi,

I am trying to do a intranet web application. I have already configured IIS to Integrated Windows Authentication only, and set web.config to windows auth mode. I have also added <identity impersonate="true" />. However, when I try to connect to an Access database on a shared network folder (different from the IIS server), I keep getting the error the Microsoft Jet database engine cannot open the file '...', it is already opened exclusively by another user, or you need permission to view its data. My connection string is "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\\servername\sharename\db.mdb". I have also checked the permissions, and am able to open the database directly.

Is there something I left out?

Thanks in advance.

Regards,
Russ

 

[ca8msm]

You may have already done these steps, but here's some things to check:

1) What authentication mode have you set in your web.config file?
2) Are you allowing anonymous access in IIS?
3) Have you set the relevant security permissions on the folder?
4) Have you set the relevant sharing permissions on the folder?


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[ryDen]

Hi, thanks for your reply.

1) Authentication mode is windows (<authentication mode="Windows" />)
2) Anonymous access is unchecked in IIS
3) Relevant security permissions is already given - only a certain AD groups can access the folder.
4) Shared permission is given to Everyone (Full Control).

I tried running from the IIS server and it works. However, it still doesn't work when I run the web application remotely. One thing is that I am running on different domains (but with trust properly setup), i.e., my IIS server and the server on which the database resides is on domain 1, while my user account is on domain 2. Could that have an effect? Thanks.

 

[ryDen]

Sorry, I tried on another machine with a user account also on domain 1 and it also has the permissioning problem, so, shouldn't be domain problem. Apparently, it seems that remote impersonation doesn't work...