gsymons How were you able to make the workspace writable for the shell command? Even with 777 permissions on the workspace I have the same issue. If I run the same docker command I see in the jenkins console log with "bash" instead of "cat" I can touch files in the workspace directory without a problem.

UPDATE 11/16/2015:
In my case I was able to get sh commands working inside the container by adding a user to the docker image with the uid/gid that was bieng specified on the docker run command executed by the plugin (the local jenkins userid and group).

In my case, I was running Jenkins in a container, and had mounted the host's Docker socket in the container. Since /var/jenkins_home was a data volume for the container, it didn't exist on the host, and so the workspace didn't exist either. I fixed it by running a second Docker process inside the container alongside Jenkins.

Not sure if mine is related to this issue. I experience the same symptoms when I try to run containers that have entry point defined. The thing tries to run 'cat' in the container before doing anything else. But the entry point program considers cat to be an argument and exits right away. Jenkins doesn't notice that and tries to continue with workflow and launch things on killed container which never runs and the whole thing hangs forever until it's manually killed.

Here is relevant log:

58d775c792e6: Pull complete
9ba627a43b4f: Pull complete
Digest: sha256:ea5101ed616f7a0bc59ac1bd7034c706e60b46d422d161b774f7b0b2ad547ed9
Status: Downloaded newer image for sequenceiq/packer:v0.7.5.dev
[Workflow] Run build steps inside a Docker container : Start
$ docker run -t -d -u 500:500 -w /home/ec2-user/workspace/Boxes/boxes -v /home/ec2-user/workspace/Boxes/boxes:/home/ec2-user/workspace/Boxes/boxes:rw -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** sequenceiq/packer:v0.7.5.dev cat
[Workflow] withDockerContainer {
[Workflow] sh
[boxes] Running shell script
Aborted by Vlad Korolev
Aborted by Vlad Korolev
Forcibly terminate running steps
Terminating sh

vkorolev sounds like a distinct issue, file separately with steps to reproduce.

kmusard I have tried configuring the build node (with the mapped docker socket) to have a jenkins user with the same uid:gid as used by the plugin i(1000:1001) to no avail. What do you mean by:

In my case I was able to get sh commands working inside the container by adding a user to the docker image with the uid/gid that was bieng specified on the docker run command executed by the plugin (the local jenkins userid and group).

kmadel In my setup I had a Docker server that was also running jenkins. Once I setup a jenkins user inside the container with matching uid:gid to the server running jenkins, the sh commands no longer hung.

Stopped the progress since jglick didn't like https://github.com/jenkinsci/docker-workflow-plugin/pull/7 . I have not implemented anything else

I was able to work around this without modifying the container by explicitly specifying the uid to match the mounted filesystem (uid: 1000, gid: 50).

Like this:

docker.image('maven:3.3.3-jdk-8').inside('-u 1000:50') {
  git '...'
  sh 'mvn -B clean install'
}

Less than ideal, as the uid is specified twice in the command line...

Seems there are various things being mixed together here.

First is the robustness issue: if the control directory cannot be created, we had better report that properly, and fail. JENKINS-28400 covers this.

Then there is an issue reported with DinD, which is perhaps best avoided by using bind-mounts of the Docker socket; PR 31 purports to address this.

Then there was a comment about containers with an entry point. If reproducible, clearly a distinct bug.

Then there is some discussion of UID mismatches, which PR 25 might address, though there is no information given there about how to reproduce.

Closing given the confused set of issues here. For any particular bug which causes the workspace to not be writable (or not mounted, etc.), please file a distinct report with steps to reproduce.