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

Question

Question

Electronic files disappearing when replicating documents between repositories

asked on December 2, 2015

I have added a Replicate function in one of my workflows, that *should* take all of the folders it finds, as well as all of their contents, and move it to another repository.  Although the documents have moved over, and the meta data still applies to all files, the electronic file appears to be missing.

Can anyone think of any reason this might be happening?  I've chosen to maintain the folder structure when copying items over, and I have also said to bring over any electronic files.  Could this possibly have to do with Windows permissions on the actual file system itself (associated with that repository) restricting this?

Any help on this would be greatly appreciated!

Marty Gaffney - Network Technician

Town of Okotoks

0 0

Answer

SELECTED ANSWER
replied on December 3, 2015

No, Windows security has nothing to do with it. The LF Server is writing files to disk during briefcase import. So only the LF Server's service user would need rights to the actual volume folders on disk.

The LF user, however, needs to have rights to create documents in the repository, rights to create templates if there are templates in the briefcase that don't already exist in the repo and so on.

0 0

Replies

replied on December 2, 2015

Check the Copy Settings in the Replicate Entries activity and make sure you are including electronic documents. Does the activity succeed or does it have any warnings? If you log in as the same user specified in the connection profile and import a briefcase with electronic documents, does the same thing happen?

The Laserfiche Server is the one writing files to disk, so you'd see this issue for any user trying to import into that volume if Windows permissions were an issue.

0 0
replied on December 3, 2015 Show version history

I'm beginning to see a pattern here...

I tried doing an export to a briefcase, and then I did an import to the destination repository (not sure why I hadn't tried that, lol).  When I did, I got an Access Denied message, as expected.  

Now, the account I'm using for moving data between repositories is a Laserfiche Named User, not a Windows Named User.  I have given the AD security group set up for access to Laserfiche with read/write/modify access (along with full access to Domain Admins and local server Admins) - should I be extending this to the local server's Users as well?  I also set this permission up to the repository folder, but I've turned off the ability for these users to browse to this folder - could that be part of what's causing problems as well?

(I hadn't thought this had been the issue previously, as we'd been using Laserfiche for quite some time, after these changes, with no issues until now.)  Thanks again for your assistance!

Marty Gaffney

0 0
SELECTED ANSWER
replied on December 3, 2015

No, Windows security has nothing to do with it. The LF Server is writing files to disk during briefcase import. So only the LF Server's service user would need rights to the actual volume folders on disk.

The LF user, however, needs to have rights to create documents in the repository, rights to create templates if there are templates in the briefcase that don't already exist in the repo and so on.

0 0
replied on December 3, 2015 Show version history

THAT'S what it was!

I had a look at the Server service permissions, and I had associated it with a Windows domain account on our Production server, but the Local Service account on our Test server (which I had since locked out).  I just did an import into one of the repositories after changing the user associated with the Laserfiche Server service on my Test server, and the import appeared to work fine.

I think that did it, although I'll verify elsewhere - thanks much!

Marty

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

Sign in to reply to this post.