Using a custom workspace located on a windows share drive on a windows slave

[Gary Bell]

Hi Everyone, posting this in case it helps someone else in the same situation as I was.

Problem:
========
I was using Jenkins to run a windows job that used to run on the task scheduler on a server 2008 machine. The executable code for that job resides on a shared drive and has a directory structure that I cannot change.

I set up the windows machine as a slave on my linux Jenkins master, set up a new project and added an "execute windows batch job" build step. I then set it to trigger on a schedule. This all worked and the job ran successfully.

I now wanted to let the Jenkins Users see the log files that were produced in the "logs" directory located on that shared drive. I modified the project to add a custom workspace, and set it to X:\jobs\foo\logs which is what it is available as on the slave. When I ran it, it failed with the error:

java.io.IOException: Failed to mkdirs: X:\jobs\foo\logs
at hudson.FilePath.mkdirs(FilePath.java:1055)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1401)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:676)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)


There was no SCM system configured, and the paths definitely existed and were available on the slave when I remoted on to it using RDP.

Solution:
=========
The problem was caused by the fact that the X:\ share was "Unavailable" to the Jenkins user service process, but available when remotely logged in using RDP or something. This is related to Windows UAC and is explained here:

https://technet.microsoft.com/de-de/library/ee844140%28v=ws.10%29.aspx

You can confirm this by temporarily adding a build step to the project that does a "net use" command and then viewing the Jenkins console output for the build. The shared drives are shown, but listed as "Unavailable". To get around this, I did the following:

1. Checked the option to "Prepare an environment for the run" in my project configuration.
2. In the "Script content" text box, I added the net use commands to map the share (even though it was already mapped), and to show me the status.
3. Ran the job and confirmed that all the drives were shown as "Available" and that the job completed successfully.

The commands I used in step 2 were:
net use X: \\<my server>\shared
net use

At this point the log files all showed up in the workspace as required.

Best Regards,
Gary.

[Ioannis Moutsatsos]

Good info. Thanks for sharing!

Were you logged into RDP using the same Jenkins user account that runs the service?

Best regards

Ioannis

[Gary Bell]

Yes, the same user. The Jenkins service is set to run as a normal domain account that I also used to RDP into the machine.

 

Gary.