You are viewing limited content. For full access, please sign in.

Question

Question

Error Code: 9013

asked on April 14, 2016

I've a few users who are getting an Access Denied. [9013] error code when trying to change a field and then save a document. This doesn't happen to all users, just a few so far. I've confirmed that the users have the proper rights on the Field, Template, Document, Folder and Volume. I had one of the users do a test. He was able to link a document to the affected document, add his signature stamp and then save the document. When he tried saving the document after changing the selection in the drop down field, he received the following error message:

 

Error Code: 9013

Error Message: Permission denied.

Access denied. [9013]

 

------------ Technical Details: ------------

 

LFSO:

    Additional Details:

        HRESULT: 0xc0042335 (LFSession::ProcessResponse, LFSession.cpp:3748)

         (LFSO/9.0.2.660)

LFMetadata90.ocx (9.0.2.727):

    Call Stack: (Current)

        CLFMetadataCtrl::SaveData

    Additional Details:

        Exception: 0xc0042335 [9013] (Permission denied.) (CLFMetadataCtrl::SaveData at LFMetadataCtrl.cpp:1222)

    Call History:

          CPageTemplate::GetFieldValueAsVariant

          CPageTemplate::GetFieldValueAsVariant

          CPageTemplate::GetFieldValueAsVariant

          CPageTemplate::GetFieldValueAsVariant

          CPageTemplate::GetFieldValueAsVariant

          CPageTemplate::GetFieldValueAsVariant

          CPageTemplate::GetFieldValueAsVariant

        CLFMetadataCtrl::SaveData

 

   All users receive the same access rights through being members in a particular AD security group. When I moved the document itself into another folder in which the user had specific rights for, he was then able to change the field and save the document. Any suggestions as to what might be the cause?

 

Thanks,

Michael

 

0 0

Replies

replied on June 19, 2018

There was a resolution. If memory serves, I ended up having to remove their accounts from Laserfiche entirely, and then re-add them. I ended up doing that as a last resort as nothing else seemed to resolve it.

 

Thanks,

Michael

2 0
replied on June 19, 2018

Thank you Michael. By any chance do you remember if this happened after an upgrade from 8.x or did it just randomly started happening?

0 0
replied on June 19, 2018

You're welcome, Edgar. I believe that it was more of a random occurrence, though we had upgraded from 9.x to 10 about a month previous.

1 0
replied on May 3, 2017

Was there ever a solution to this issue?

1 0
replied on April 14, 2016

Check the access rights for Annotate, which is the rights to add stamps/annotations to a document.

0 0
replied on April 14, 2016

Well if moving the doc made it function properly then it almost has to be folder security, and since you were able to add annotations properly, then the only entry access right to check is the "write metadata" right.  Maybe check to make sure the user has this right, as well as check and make sure there aren't any other rights set at a group level that could be setting write metadata to Deny.  Denies can cause all sorts of havoc if not properly assigned and should be scarcely used.

0 0
replied on April 14, 2016

The rights seem to be correct. I've even viewed the effective rights for the users on that folder and associated documents. We try not to use Deny due to the problems it can cause. All of the Deny fields are blank. It's just really odd. 

0 0
replied on June 15, 2018

Hi,

Was there a solution for this issue?

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.