Error attempting to change lock owner

Hi Folks,

I have an interesting (re-occurring) error showing up in my iwtrace.log:

Error attempting to change lock owner to tsadmin: Permission denied

What is interesting is that the

tsadmin

user has just about every conceivable permission under the sun. It is a 'master', it's in just about every group, just about has every role in every branch, etc.

However, my gut feel is that this error is caused by the

tsadmin

user being unable to obtain a lock from workflow. We are using WFT workflows and many tasks are owned by the

tsadmin

user, performing various operations.

We haven't seen too many strange symptoms in WF, so the tasks appear to be successfully fulfilling their respective purposes.

Can anyone give me any clues as to where to look elsewhere? This error doesn't reveal much info. Is there anyway of increasing the verbosity of iwtrace?

Any pointers would be appreciated.

Find more posts tagged with

Comments

Sarang

Facing the same issue, any pointers please.

How did you resolve this Robbo?

Adam Stoller

Facing the same issue, any pointers please.

How did you resolve this Robbo?

Not sure if Robbo will remember what happened over a year ago - but just looking at the error message in the original post I think the issue was mis-diagnosed. I don't think the issue was that tsadmin couldn't take the lock, but that some other user-owner process was attempting to change the lock to be owned by tsadmin - and that user probably didn't have the rights to do so.

Mind you, that's truly a guess from the limited amount of information that's here.

brizrobbo

Fish is correct. This was mis-diagnosed. The issue was as (embarrassingly) simple as the fact that the selected file was already in another workflow. Needless to say, we have checks for that sort of stuff now. :-)

Sounds silly, but check if the file is not already in a workflow?