Vault Synchronize Properties fails with ‘File Locked;’

[joe]

When we change the state of a file from ‘WORK IN PROGRESS’ to ‘RELEASED’ we have chosen the option to ‘Syncronize Properties using the job server’. (inside the lifecycle transition between WIP and RELEASED).

When the state change is made, the job is sent to the job processor as designed. However the job fails with a ‘File Locked;’ message.

The permissions for the RELEASED state are EVERYONE (Allow: Read, Deny:Modify/Delete) and JOBUSER (Allow:Read/Modify/Delete).  All the job processors login using this JOBUSER account.

I can process ‘Visualization attachment’ jobs with these settings successfully when the file is RELEASED, but the synchronize properties job fails every time with ‘File Locked;’.

I have only been able to fix this behaviour by removing the deny permissions from EVERYONE. This causes a problem in that it means the RELEASED state is NOT locked for the standard user.

I have serviced packed the vault and it is now on Autodesk Vault Professional 2014 Subscription Release 1 Update 1.

I think I am missing something. I would welcome advice on how this should work or a suggested fix.

Many Thanks

Joe

[Neil_Cross]

Hi Joe,

I think the problem here is that the jobuser account you've created falls under the 'everyone' classification.  So there's a conflict of rights and it's inheriting the deny which must overule the allow.

I had the exact same conundrum when building my security permissions, I think I found a couple of solutions but it was years ago I did this... I could be lying but I remember something about the order in which the permissions are listed was significant.

Ultimately I settled on placing all the 'normal' users into their own groups and applying the deny permission to those groups, with the jobuser account being given explicit allow rights.  I removed the 'everyone' group from all permission selections to avoid such conflicts.

[minkd]

If you grant everyone read, and then grant the job-user write (not sure if it needs delete), no-one other than the jobuser will have write. If you don't grant anyone delete, then no-one will have it.  You only need to explicitly deny access when you need to deny a subset of some group who has a grant.

-Dave

[p.crawford]

Thanks, Neil! I was encountering this problem and your post helped me to understand the access rights! I was unaware that the "deny" supersedes the approve.

Patrick