Failed to create mutex error (v. 2.0.6)

dproth_trc · Post by **dproth_trc** » Mon Apr 11, 2005 1:03 pm

We have been building an ASP.NET application that uses the Vault API to check-in/check-out content from Vault. SourceGear has been very helpful in solving a check-in problem we were having. Now we are ready to go live with our application, but have hit a major roadblock...

If we login to the ASP.NET app (it uses identity impersonation) as ourselves, everything works fine (we, the developers, are administrators). However, some of the other users (non-administrators) cannot get logged in. We get the following error:

Code: Select all

System.Web.HttpUnhandledException: Exception of type System.Web.HttpUnhandledException was thrown. ---> System.Exception: Failed to create mutex.  errno=5
   at VaultLib.SystemMutexWin32..ctor(String name)
   at VaultLib.SystemMutex.CreateSystemMutex(String name)
   at VaultClientOperationsLib.CacheMember..ctor(String folder)
   at VaultClientOperationsLib.CacheMember_Repository..ctor(String folder)
   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)

We are running Vault 2.0.6. I saw some posts talking about mutex problems and them being fixed in version 2.0.5, so apparently we have found a new problem.

Hopefully someone can help.

dan · Post by **dan** » Mon Apr 11, 2005 1:17 pm

We fixed some additional mutex issues in 3.0, so you may want to download it and test it out to see if it addresses this issue (it may or may not, but is worth a try).

dproth_trc · Post by **dproth_trc** » Mon Apr 11, 2005 1:24 pm

No other suggestions? Since it only happens for certain users, it seems to be a security issue. Is there something permissions-wise we could do?

Upgrading to 3.0 will cost us quite a bit for all our users, so unless I know that it fixes the problem, I certainly am not prepared to make that purchase.

Post by **jclausius** » Mon Apr 11, 2005 3:05 pm

Are you threading within the ASP.Net application?

If so, this might be causing the problem. Any thread created within an ASP.Net web app/web service does not necessarily get assigned the security attributes of the web app's security context. For instance with Vault, when the system has been configured to run under identity impersonation, other update / logging threads are started and then assigned a WindowsIdentity of the main process.

A couple of things that may help here.

1) You may want to see if setting the Vault ClientInstance's UseUpdateThread to false. This may prevent the mutex from being created.

OR

2) You may also want to see if adding the users to "Create global objects" in the Security Policy gives the users the rights they need to create the named mutex.

HTH

dproth_trc · Post by **dproth_trc** » Mon Apr 11, 2005 4:36 pm

I tried your #2 option first (as it was the easiest). Didn't initally appear to work. Windows (2003) must cache security rights somehow, because when I tried it on another web server (we have a cluster), it worked. Then, when I went back to the first server, it worked there, too. These are domain accounts.

Anyway, it's working now. Thanks.

Post by **jclausius** » Tue Apr 12, 2005 8:14 am

Glad we could help.

dproth_trc · Post by **dproth_trc** » Tue Apr 12, 2005 1:35 pm

It stopped working.

I'm still getting the mutex errors. I also tried UseUpdateThread to False.

Our application is not using any threading.

What's weird is I don't get the error for some users and I do get it for others. There's no rhyme or reason to which users and it changes randomly. Today, I'm getting the error on my administrative account and I'm NOT getting it on an account that was getting the error yesterday.

Post by **jclausius** » Tue Apr 12, 2005 1:44 pm

It shouldn't matter what account logs in because ASP.Net should use the process account for permissions. If you're using identity impersonation in your application, then that is the account that should be granted access - at least for anonymous authentication access.

When you say the user "logs in", what are you using to control that? Web.config? Is anonymous access still enabled on your web app?

One other thing you could try - assuming anon access is enabled, you could temporarily add the impersonated account to the administrators group, to see if that helps solve some problem.

dproth_trc · Post by **dproth_trc** » Tue Apr 12, 2005 1:48 pm

We are using basic authentication over SSL. Accounts are authenticated against an Active Directory domain. Anonymous access is DISABLED. Identity impersonation is ON. So, the ASP.NET app is running as the logged on user.

When they "log on", I'm talking about the basic authentication prompt that Internet Explorer pops up.

Post by **jclausius** » Tue Apr 12, 2005 1:55 pm

Maybe we're talking about different things.

When I say "identity impersontaion", I'm referring to the Xml element <identity impersonate="true" userName="USER" Password="PASS"/> within web.config.

When this has been enabled, an ASP.Net account will run under this account rather than the ASP.Net process account.

This takes place regardless of the authorization method used to grant access to a web resource.

dproth_trc · Post by **dproth_trc** » Tue Apr 12, 2005 1:57 pm

This is what we use in Web.config...

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

This makes it use the user's account instead of any pre-defined ASP.net account.

Post by **jclausius** » Tue Apr 12, 2005 2:02 pm

OK. I assumed you were using a named identity which uses the same identity for each request.

Post by **jclausius** » Tue Apr 12, 2005 2:05 pm

Does the IIS Server take place within a domain? If so, instead of setting the local policy for Create global objects, perhaps you could use the domain policy?

Or for that matter if you made the assignment to the Domain policy, perhaps it needs to apply to the local policy?

Post by **jclausius** » Tue Apr 12, 2005 2:16 pm

What you'll need to figure out is the permissions that allows the following snippet to run:

Code: Select all

[DllImport("kernel32",EntryPoint="CreateMutex",SetLastError=true,CharSet=CharSet.Unicode)]
private static extern uint XCreateMutex(SecurityAttributes auth, [MarshalAs(UnmanagedType.Bool)] bool initialOwner, string name);

_handle = XCreateMutex(null, false, "some_name");

Note, this was changed in Vault 3.0.x as Dan mentioned. The System.Threading.Mutex class is used instead.

dproth_trc · Post by **dproth_trc** » Tue Apr 12, 2005 4:03 pm

They are domain accounts. The IIS machine is also a member of the domain. I changed the domain wide security policy. I restarted IIS and it seems to be working for now. I'll let you know if it holds.