OL Learn

W3001 : Error while executing plugin: W3220 : Error creating directory

I’ve searched all of the W3001 issues on the forum and found one that was similar although the error code was different so I think this warrants a new thread.

ERROR: 09:58:12.070 W3001 : Error while executing plugin: W3220 : Error creating directory: [\172.20.1.148\Invoices](file://172.20.1.148/Invoices/): Error code 161: The specified path is invalid.

ERROR: 09:58:12.070 Send To Folder: W1603 : Plugin failed - 09:58:12 (elapsed time: 00:00:00:009)

On the Planet Press server, I am able to access this folder (\\172.20.1.148\Invoices) with Windows Explorer. I am also able to manually create a text file in this directory. When I try to move a file using the Workflow, the file is grabbed with Folder Capture but is never delivered with Folder Send.

We have 2 licenses on 2 different servers that use the same user name. The one server is able to send files successfully but not the other. Since it uses the same User Name and the permissions are setup identically, is there a reason why one server cannot send a file but the other can? Our IT Department considers this a Planet Press issue rather than a folder security issue as it works for one server and not the other.

Any help on this would be appreciated as I’ve exhausted Google and this forum for a solution. Thank you in advance.

On the server where it doesn’t work…does it work if you do it in debug from Workflow?
If it does work in debug but not as a service, then it is a right issue. The only difference between Workflow debug and Workflow service is rights.

Are your 2 servers setup identically? Same OS, same version same everything?

It works in debug mode, the file moved successfully. Servers are identical in hardware. The one it is working on is version 8.8.0.12538 and the one it’s not working on is 8.7.1.12148, but I doubt that would cause the issue (right?). Also, the 8.8.0 server is a DEV server that adds a Planet Press watermark to every document.

I can go back to IT saying if it works in Debug, it is definitely a security issue. Thanks

To be clear, we’re talking about rights differences between the account you’re logged in as (running in debug uses your active Windows account) versus the Service account.

If these two accounts are the same, then the permissions allowing it to work in debug are not native to the account (for example, stored credentials in Windows) and the service account is not being granted those permissions while running in a non-interactive desktop environment (running as a service).

AlbertsN: Your response helped IT narrow down our issue… One server was using a Local Systems account while the other was using a named account. While I was logged in to the server under the named account, I had access to read & write on the restricted network. Apparently the workflow uses the service account which was not granted permission to access the folder. By running services.msc, we were able to tell that the 2 servers were not setup the same way (one was purchased a couple years after the first one).

Appreciate both of your help on this!