System.UnauthorizedAccessException

[dproth_trc]

We have an ASP.NET application we have developed that accesses our Vault repository using the Vault API. We occassionally get this error trying to select the repository:

Code: Select all

System.UnauthorizedAccessException: Access to the path 'Vault_CacheMember_Repository_689544213' is denied.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.Threading.Mutex.<>c__DisplayClass3.<.ctor>b__0(Object userData)
   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name, Boolean& createdNew, MutexSecurity mutexSecurity)
   at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
   at VaultLib.SystemMutex..ctor(String name)
   at VaultClientOperationsLib.CacheMember..ctor(String folder)
   at VaultClientOperationsLib.CacheMember_Repository..ctor(String folder)
   at VaultClientOperationsLib.TreeCache.Load()
   at VaultClientOperationsLib.TreeCache..ctor(Int32 repID, String username, String uniqueRepositoryID, String localStoreBasePath, ClientInstance ci)
   at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Int32 id, String username, String uniqueRepositoryID, Boolean doRefresh, Boolean updateKnownChangesAll)
   at TRC.Vault.Utilities.Login() in D:\TRSites\TherapeuticResearch.net\TRC.Vault\Utilities.vb:line 79
--- rest of our and asp.net call stack ---

Doesn't happen all the time. When it does happen, the only way to fix the problem is to perform an IISRESET on the web server running the ASP.NET application. The application is running with full Administrator rights.

Does it only create a Mutex some of the time? Otherwise, it's a complete mystery as to why this would be an intermittent problem.

We are using Fortress version 1.1.3.18336.

We had a similar problem back when we were using Vault 2.x...
http://support.sourcegear.com/viewtopic.php?f=5&t=3572

Even though that thread suggests we resolved the problem, it never fully went away until we moved the application onto it's own web server (rather than load balancing it on two web servers). However, since upgrading to the current version of Fortress, we've apparently run into this problem (or something similar) again.

Any help would be appreciated. Thanks in advanced.

David Prothero
I.T. Director
Therapeutic Research Center

[Beth]

Your latest error looks more like this thread, Access to the path 'Vault_WF_48290267' is denied, to me. Check out that user's symptoms.

It still can fall under a mutex problem though. What did you upgrade from? Was it another version of Fortress that was your recent upgrade, or was it from Vault prior to 4.x to Fortress 1.1.3?

What OS is this installed on?

[dprothero]

Reviving this thread as well, as we continue to have this issue. I don't see how the post you mentioned is related. We are not using Run As or I don't see how the MakeAdmin tool would apply here. We're running this as an ASP.NET application using the Vault API.

We upgraded from Vault, but I don't recall if it was prior to 4.x or not.

Both the Fortress server and the ASP.NET application are on (separate) Windows Server 2003 Enterprise (SP2) machines.

Thanks.

[Beth]

Does the error by any chance happen at the same time as when you are having performance problems?

[dprothero]

No, the performance problems (for those following at home, we're referring to http://support.sourcegear.com/viewtopic ... 30&t=12696) happen about once every couple of weeks. This issue happens fairly consistently. Couple times a day, probably. Once we have the problem, the only way to correct it is to run an iisreset on the web server running the ASP.NET application. Once that's done, things seem to resume normal operation.

Thanks.

David.

[Beth]

What app pool do you have that asp.net application using and what user is that app pool set to run under?

Can you look in your Event Viewer for errors related to this? Those errors might tell us more.

[dprothero]

The app pool is running as Network Service.

The IIS application folder is set to Basic Authentication, and authenticates against our Windows 2003 domain.

In web.config for the ASP.NET application, we have:

<authentication mode="Windows" />
<identity impersonate="true" />

So that the application runs as the logged in user.

If it were a permanent permissions issue, you wouldn't think this would work some times and then not work other times. So, whatever the issue is, it's transitory.

Thanks.

David

[Beth]

Are there any other errors showing up in the Event Viewer logs on either the client or the server when the application has an error?

[dprothero]

Nothing in the event logs, no.

[Beth]

Can you find in your Fortress server the file called vault.config? By default, it's in the vaultservice virtual directory. Look for the tag FileCacheEnabled. Is that set to True or False?

[dprothero]

It's currently set to False.

[Beth]

Are there any specific users that this happens under, or does everyone get the error occasionally.

Have you considered having the application run just under one specific user instead of multiple users? That might help narrow down the issue some.

Does the application not run at all if no user is logged in?

I am thinking maybe the information from the previous user is still being used by the application when the next one logs in to use it.

[dprothero]

It happens to pretty much everyone one time or another.

I think you're right about the multiple users. It usually happens when different people are using the same application.

The application itself has to run within the context of each individual user. This is how we do our security for what SQL Server objects the user should have access to.

So... we would have to figure out some way to get the Vault API calls to run within a single user context, it sounds. Does that sound right?

David

[Beth]

Is it possible that different users are using the application at the same time?

[dprothero]

Yes, it is. It'd be at most 2 users, but it does happen.