I am trying to create a new directory and copy files to it. So I'm using a job of "Execute batch command".
First I tried to run: robocopy source destination /e.
Then I tried: mkdir destination. In both cases I got an "Access is denied" mssage.
If I try it myself manualy I am able to create a directory and copy files to it.
The destination is a remote computer's shared folder: \computerName\sharedFolder\
Anyone knows how to get access rights with Jenkins?
To find out the user under which your jobs run, create a "scratch" job in Jenkins. Give it a single "Execute Windows Batch command" build step and enter "set" as the text of your batch command. If your affected job is running on a Windows slave, make sure this job runs on the same slave. Run the job. Your console will show a list of the environment variables known to that job, the same as if you typed "set" in a Command Prompt window on your desktop. The difference will be that near the bottom, the username shown for "USERDOMAIN" and "USERNAME" in your command window will be you (the user you are logged in as); in the console output, it will be the user account that your Jenkins job runs under.
That user may not actually have login rights. And, if Jenkins is running as a service, you can't just set up a share in your command window: Jenkins jobs run under a different Windows "session" and that session will not see the share you created in your login session.
A not-very-secure way to get you over the hump would be to add parameters to your job for the username (string parameter) and password (password parameter). Before you need access to the drive, either in the same build step or in a 'Execute Windows Batch Command' step that runs prior to that build step, run "@net use : \computername\sharename %% /USER:%% /persistent:no". (for example: "@net use p: \COMPUTER\SHARE %PASSWORD% %USER% /persistent:no"). The "@" will keep the password from showing in the log. (However, the password will be associated with the job and will be encoded in Jenkins if "Allow rebuild" is enabled.) Make sure when you are done you clean up ("net use /delete") and you may need to test and clean up the drive letter before you try to connect, in case a previous job failed without releasing the drive letter.
In this scenario you would have to enter a username and password for someone who can access the share when you run the job. You could encode hidden parameters with these values pre-filled in, but that means that user's username and password are encoded into the job definition, and the default for the hidden password parameter would not be encrypted in the Jenkins config files.
There are definitely more secure ways to get the drive share enabled in the Jenkins service session, but depending on your environment this may be 'good enough' to get you past the block you are faced with right now. I have used tricks like these in an environment where I was not a Jenkins administrator and I had very limited access rights (and no admin rights) on the Jenkins slaves.