Writing a local file to Windows Standalone VCO server -

[SamWolf]

Hello,

I am attempting to write a file locally to the windows server hosting my 5.5 VCO application via the FileWriter() method but have been running into various issues around write permissions.

I have created a C:\temp folder i wish to write to and have opened that up to both the system account and VCO user account.

I have also made changes to .C:\Program Files\VMware\Orchestrator\app-server\conf\VMO properties file adding com.vmware.js.allow-local-process=true.

In regards to creating a js-io-rights.conf the documentation references a folder that does not exist so I do not know if this is the missing link, however when I made the VMO change that error stopped coming up.

Could someone please let me know how to get passed this permission error.

thanks,

Sam

[SamWolf]

The original error

[tschoergez]

You need the js-io-rights.conf file, it usually get created the first time you try to access a local file, in the vRO configuration folder.

Also check http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=203982...

In the file you the specify e.g.

+rwx c:/temp

Be aware that the backslash is a special character in javascript, so you have to escape it with another one

(e.g. new File("mypath\\myFile.txt") ). however forward slash / should also work, even on windows.

Joerg

[SamWolf]

Thanks for the quick reply Joerg,

So here is what the contents of my js-io-rights.conf looks like:

+rwx C:\

+rwx C:\Temp

+rwx C:/orchestrator

+rx ../../configuration/jetty/logs/

+rx ../server/vmo/log/

+rx ../bin/

+rx ./boot.properties

+rx ../server/vmo/conf/

+rx ../server/vmo/conf/plugins

+rx ../server/vmo/deploy/vmo-server/vmo-ds.xml

+rx ../../apps/

+r ../../version.txt

Now it is located in  C:\Program Files\VMware\Orchestrator\app-server\conf

I can't seem to find any docs in which the specific path is specified for the windows application, could you please provide me with the proper path.

Thanks,

[tschoergez]

I haven't used a windows based vCO since quite a while... But the file and location looks good.

Can you check that the filesystem permissions allow the user the vRO service runs with to read/write (check in windows services to get the service user). But usually for C:/Temp that shouldn't be an issue.

Also make sure to restart the service after each change in the js-io-rights.conf file.

Can you try to run XML examples in the Library, to see if they work?

We have to figure out if the problem is related to the vRO configuration, or if it's an error within the workflow (like "rendering" the filenames incorrectly or so)

Joerg

[SamWolf]

Hi Joerg,

Ran into the same issue with the XML file creation.

Thanks,

[SamWolf]

moved the ball forward a little.

The new error when executing the Create XML workflow is

Unable to initialize default FileHandlerAccessRights, reason : The filename, directory name, or volume label syntax is incorrect (Workflow:Create a simple XML document / Create Simple Document

[iiliev]

Could you post the exact string value you are passing as input when you start 'Create a simple XML document' workflow?

Also, the error message you posted seems incomplete/truncated to me. Could you post the whole message (should be available in the vCO log files)?

[SamWolf]

Hi,

I have tried a variety of string inputs they are as follows

C:\

C:\Temp

'C:\Temp'

"C:\Temp"

C:\\Temp

"C:\\Temp"

2015-06-18 16:53:20.285-0400 [WorkflowExecutorPool-Thread-3] INFO  {Create a simple XML document:51808080808080808080808080808080A180808001175587494510271f02ffa1f:2c9942094e07537e014e08728665001c} [SCRIPTING_LOG] Unable to initialize default FileHandlerAccessRights, reason : The filename, directory name, or volume label syntax is incorrect (Workflow:Create a simple XML document / Create Simple Document (item0)#20)

Thanks,

[iiliev]

The input argument of this workflow is not a directory where to create the result XML file, but the file name itself.

So, instead of using

    C:\Temp

try with something like

    C:\Temp\sample.xml

[SamWolf]

Unfortunately got the same result.

[SamWolf]

2015-06-18 16:53:20.096-0400 [http-bio-0.0.0.0-8281-exec-83] INFO  {} [Execution] Executing workflow 'Create a simple XML document'

2015-06-18 16:53:20.113-0400 [org.springframework.jms.listener.DefaultMessageListenerContainer#0-2] INFO  {} [Execution] Invoking workflow handler.2c9942094e07537e014e08728665001c

2015-06-18 16:53:20.227-0400 [WorkflowExecutorPool-Thread-3] ERROR {:Create a simple XML document:51808080808080808080808080808080A180808001175587494510271f02ffa1f:2c9942094e07537e014e08728665001c} [FileHandlerAccessRightsFactory] Cannot initialize Javascript File access rights

java.io.IOException: The filename, directory name, or volume label syntax is incorrect

  at java.io.WinNTFileSystem.canonicalize0(Native Method)

  at java.io.Win32FileSystem.canonicalize(Unknown Source)

  at java.io.File.getCanonicalPath(Unknown Source)

  at java.io.File.getCanonicalFile(Unknown Source)

  at ch.dunes.util.security.FileHandlerAccessRights$AccessRightItem.getAbsoluteOrCanonicalFile(FileHandlerAccessRights.java:190)

  at ch.dunes.util.security.FileHandlerAccessRights$AccessRightItem.<init>(FileHandlerAccessRights.java:173)

  at ch.dunes.util.security.FileHandlerAccessRights.parseNewLine(FileHandlerAccessRights.java:111)

  at ch.dunes.util.security.FileHandlerAccessRights.initWithStringContent(FileHandlerAccessRights.java:71)

  at ch.dunes.util.security.FileHandlerAccessRights.initWithInputStream(FileHandlerAccessRights.java:56)

  at ch.dunes.util.security.FileHandlerAccessRights.initWithFile(FileHandlerAccessRights.java:43)

  at ch.dunes.util.security.FileHandlerAccessRightsFactory.getDefaultFileHandlerAccessRights(FileHandlerAccessRightsFactory.java:45)

  at ch.dunes.xml.sdk.XMLManager.saveDocumentWithEncoding(XMLManager.java:134)

  at ch.dunes.xml.sdk.XMLManager.saveDocument(XMLManager.java:124)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

  at java.lang.reflect.Method.invoke(Unknown Source)

  at ch.dunes.vso.sdk.WrappedJavaMethod.call(WrappedJavaMethod.java:142)

  at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1473)

  at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:815)

  at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:109)

  at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:394)

  at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3091)

  at org.mozilla.javascript.InterpretedFunction.exec(InterpretedFunction.java:120)

  at ch.dunes.scripting.server.script.MainScriptingObject.executeScript(MainScriptingObject.java:237)

  at ch.dunes.scripting.server.script.MainScriptingObject.executeScript(MainScriptingObject.java:223)

  at ch.dunes.workflow.engine.mbean.WorkflowScriptRunner.execute(WorkflowScriptRunner.java:192)

  at ch.dunes.workflow.engine.mbean.runner.WorkflowItemTaskRunner.execute(WorkflowItemTaskRunner.java:43)

  at ch.dunes.workflow.engine.mbean.runner.WorkflowItemTaskRunner.execute(WorkflowItemTaskRunner.java:24)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.executeItem(WorkflowHandler.java:937)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.requestElementExecution(WorkflowHandler.java:901)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.handleWorkflowTokenNextStep(WorkflowHandler.java:618)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.executeToken(WorkflowHandler.java:505)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.handleTokenExecution(WorkflowHandler.java:444)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.access$100(WorkflowHandler.java:102)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler$1.execute(WorkflowHandler.java:354)

  at ch.dunes.model.ar.AccessRightsTemplate.executeWithAccessRights(AccessRightsTemplate.java:16)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.doExecute(WorkflowHandler.java:350)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.run(WorkflowHandler.java:236)

  at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

  at java.util.concurrent.FutureTask.run(Unknown Source)

  at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

  at java.lang.Thread.run(Unknown Source)

2015-06-18 16:53:20.285-0400 [WorkflowExecutorPool-Thread-3] INFO  {:Create a simple XML document:51808080808080808080808080808080A180808001175587494510271f02ffa1f:2c9942094e07537e014e08728665001c} [SCRIPTING_LOG] Unable to initialize default FileHandlerAccessRights, reason : The filename, directory name, or volume label syntax is incorrect (Workflow:Create a simple XML document / Create Simple Document (item0)#20)

2015-06-18 16:53:20.285-0400 [WorkflowExecutorPool-Thread-3] WARN  {.ode:Create a simple XML document:51808080808080808080808080808080A180808001175587494510271f02ffa1f:2c9942094e07537e014e08728665001c} [WorkflowItemTaskRunner] Script execution error on workflow : Create a simple XML document / 'Create Simple Document'(item0) : Unable to initialize default FileHandlerAccessRights, reason : The filename, directory name, or volume label syntax is incorrect (Workflow:Create a simple XML document / Create Simple Document (item0)#20)

[qc4vmware]

I wonder if you are hitting an issue with user permissions?  You've given java permission to write to that path but does the user have rights within the file system?  What user is the vRO service running as?  If you can't login to the local host as that user and write a file then vRO will also fail.

[SamWolf]

So VCO is running under local system - see attached image.

I have also made the directory available to the "Everyone" group locally and to attached to domains.

One thing I have noticed is when I un select the read only property of the folder properties it instantly reapplies when properties is reopened.

[qc4vmware]

Yeah if the filesystem is read only that would be an issue.  Did you try creating a new file or just look at the permissions?  Maybe if you can verify an account that you know can manipulate the filesystem then reconfigure the service to run as that user and then re-run the things and see if you still get the error.

Also, I am gonna assume you have been restarting services, but If you haven't you definitely need to restart them after messing with permissions.  Just bounce the whole box to be safe (if you can).

[SamWolf]

So the folder permissions are correct the small square box doesn't mean the the folder is restricted.

As for the service restarts i have been running these regularly after changes.

[qc4vmware]

Did you try modifying your js-io-rights file to use all forward slashes in the paths?  I think somewhere in the thread that was mentioned but in your sample file I see the first two lines using back slashes.  I checked my files and they all use forward slashes.  I looked at all of my code that does  anything with the filesystems and I always use forward slashes there as well.

In your testing have you ever tried reconfiguring the service to run as a user instead of local system?  I know I suggested this but I didn't see anywhere in the thread where you had tested that just your screen shot with it running as system.  All of my systems are running with the Orchestrator server service configured with a domain user service account.

Is this server also joined to a domain?  In your environment is there any 3rd party software or configuration management that is used to further lock down the operating system or file system?

[SamWolf]

Hey everyone,

thanks for the responses I have resolved the issue. It was io conf file syntax

thanks,

[qc4vmware]

Was it the slashes?