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

Question

Question

QF 10 / failed to delete document

asked on October 19, 2016 Show version history

Hi - I have QF 10 with the latest patch, and when storing documents, I get the error "

Failed to delete document 'setup (ID 28336)'. [0213-BP1]:  Access to the path 'G:\qfLocal\eda9d6ab-0811-4658-b8a2-7ca8159008b1\6\125\20\31\00000335.doc' is denied.

Everything else works fine.

Prior to this, I changed the QF temp area to be on another drive, just in case the folder associated with the user had the wrong permissions.  I then explicitly set the permissions for both the logged in user and EVERYONE to have full control over the temp folder.   The OS is server 2012.

 

0 0

Replies

replied on October 20, 2016

If you have double checked the permissions for the temp folder and are still experiencing this issue, please open a support case. 

0 0
replied on October 21, 2016

I will do so - but just out of curiosity, what user does QF impersonate when it's creating folders?  Does it just inherit whoever is logged on, or does it use a system service?

 

I ask because it does not seem to matter if I run QF as administrator.....

 

thanks!

0 0
replied on November 10, 2016

I have a similar issue here - user running Quick Fields appears to have full permissions to the temp files and folders but they get the access denied error. We tried adding the Everyone group and granting full control and whilst that seemed to make some progress (file deleted but still errors on send) still no joy.

We've tried relocating the files to another local drive and folder but the issue persists. It seems to be a regularly occurring issue. 

Was there any progress in this case?

0 0
replied on November 10, 2016

Nigel,

I have been heads down on another project, and thus haven't had time to open a support ticket, manage the remote support, etc.  I just deleted the temp files when necessary - the "caveman" approach, but it got it done.

If I come up for air anytime soon and get this solved, I'll post the resolution here.  Please do likewise if you find a workaround - good luck!

 

1 0
replied on January 26, 2017

Hi All,

 

The customer in question found a solution to the problem as follows:-

 

Looking in the folder, that file is not searchable within Windows – at least it is not found when doing a search on the right folder.

The reason is because of:

On the files that have this issue you will see an attribute contain a “T”, which means the file is a temporary file. We have tried getting this searchable but in the end we removed the “T” by using Powershell Get-childitem | ForEach-Object -process {if (($_.attributes -band 0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}}

Once that is done Quickfields can see the file and stores and removes it successfully.

 

The access denied error seems to be a generic error message, as it is nothing to do with permissions – Quickfields cannot find the file.

Note that these files are written by Quickfields!

 

Hope this helps Laserfiche identify the cause and release a fix.

0 0
replied on January 30, 2017

Thanks for the update. We're still trying to track down the source of this issue. What scan engine was being used to capture the files that ended up with this attribute? Is it possible that some of the original files had the "T" attribute before being captured by Quick Fields?

0 0
replied on January 30, 2017

Circling back - I am now on v10.0.0.976 and I am no longer seeing this issue; no other changes were made except for updating across the board to 10.2

 

I do not remember the prior exact version, but it was a 10 variant.

 

I do appreciate you revisiting the ticket, though.

0 0
replied on January 31, 2017 Show version history

The Laserfiche capture engine is the source engine, and not sure about having a T beforehand, as Quick Fields itself creates the files.... frown

 

Edit - The customer in question here was using QF V8.3. I will see about getting them to upgrade to V10. :)

0 0
replied on January 31, 2017

Thanks. Yes, Quick Fields places these files here but in most cases it's not actually creating them from scratch - they're a copy of the scanned originals. In that case, I'm wondering the originals had the "T" attribute and then the copy retained this attribute after Quick Fields placed it in ProgramData. 

In your case, is this TIFF file created by Quick Fields by generating pages from a PDF? Or did the TIFFs already exist in Laserfiche for this document?

0 0
replied on February 1, 2017

Ah, I see what you mean. These are TIFF's created from a PDF. I will get the customer to upgrade to V10 QF and see if this resolves the issue. wink

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

Sign in to reply to this post.