7

I try to build istio (1.6.0+) using Jenkins and get an error:

docker: Error response from daemon: invalid mount config for type "bind":
bind mount source path does not exist: /home/jenkins/.docker

the slave contains .docker directory:

13:34:42 + ls -a /home/jenkins
13:34:42 .
13:34:42 ..
13:34:42 agent
13:34:42 .bash_logout
13:34:42 .bash_profile
13:34:42 .bashrc
13:34:42 .cache
13:34:42 .docker
13:34:42 .gitconfig
13:34:42 .jenkins
13:34:42 .m2
13:34:42 .npmrc
13:34:42 .oracle_jre_usage
13:34:42 postgresql-9.4.1212.jar
13:34:42 .ssh
13:34:42 workspace

parts of Istio script

export CONDITIONAL_HOST_MOUNTS=${CONDITIONAL_HOST_MOUNTS:-}
if [[ -d "${HOME}/.docker" ]]; then
  CONDITIONAL_HOST_MOUNTS+="--mount type=bind,source=${HOME}/.docker,destination=/config/.docker,readonly "
fi


"${CONTAINER_CLI}" run  --rm \
    -u "${UID}:${DOCKER_GID}" \
    --sig-proxy=true \
    ${DOCKER_SOCKET_MOUNT:--v /var/run/docker.sock:/var/run/docker.sock} \
    -v /etc/passwd:/etc/passwd:ro \
    -v /etc/group:/etc/group:ro \
    $CONTAINER_OPTIONS \
    --env-file <(env | grep -v ${ENV_BLOCKLIST}) \
    -e IN_BUILD_CONTAINER=1 \
    -e TZ="${TIMEZONE:-$TZ}" \
    --mount "type=bind,source=${PWD},destination=/work" \
    --mount "type=volume,source=go,destination=/go" \
    --mount "type=volume,source=gocache,destination=/gocache" \
    ${CONDITIONAL_HOST_MOUNTS} \
    -w /work "${IMG}" "$@"

... Have you tried to use -v instead of --mount, do you have any error then?

❗️ I changed --mount to -v and error disappeared

-v ${HOME}/.docker:/config/.docker
kozmo
  • 4,024
  • 3
  • 30
  • 48
  • 1
    What is your infrastructure? You use docker-swarm? Have you tried [to use](https://docs.docker.com/storage/bind-mounts/#differences-between--v-and---mount-behavior) -v instead of --mount, do you have any error then? – Jakub Apr 20 '20 at 06:57
  • Where is the docker engine (dockerd, as opposed to the docker CLI client) running, and does the directory exist there? – BMitch Apr 20 '20 at 10:38

5 Answers5

10

As I mentioned in comments, workaround here could be to use

-v

instead of

--mount

Differences between -v and --mount behavior

Because the -v and --volume flags have been a part of Docker for a long time, their behavior cannot be changed. This means that there is one behavior that is different between -v and --mount.

If you use -v or --volume to bind-mount a file or directory that does not yet exist on the Docker host, -v creates the endpoint for you. It is always created as a directory.

If you use --mount to bind-mount a file or directory that does not yet exist on the Docker host, Docker does not automatically create it for you, but generates an error.

If you use docker swarm then it's well documented here

If you bind mount a host path into your service’s containers, the path must exist on every swarm node. The Docker swarm mode scheduler can schedule containers on any machine that meets resource availability requirements and satisfies all constraints and placement preferences you specify.

Worth to check this github issue comment.

Jakub
  • 8,189
  • 1
  • 17
  • 31
2

The config in your docker-compose.yaml should be something as below:-

  volumes:
  - ~/docker-volumes/zk-single-kafka-single/zoo1/data:/data
  - ~/docker-volumes/zk-single-kafka-single/zoo1/datalog:/datalog

Now, Check the volume path which is actually present in your machine. It should be something as below:

/Users/akashverma/docker-volumes/zk-single-kafka-single

So both of them should match.

Dharman
  • 30,962
  • 25
  • 85
  • 135
Akash Verma
  • 638
  • 1
  • 11
  • 15
2

The error means that the filesystem isn't successfully shared into the docker container. For me, the fix was:

export TMPDIR=$PWD
Hatzegopteryx
  • 600
  • 6
  • 13
  • Actually this answer is a great one. This solved my issue without having to get into changing the user who is assigned to the Docker daemon. For most situations, this will prevent you from getting into the topic of running Docker as a non-root user. – Matt K Apr 06 '23 at 23:03
  • I wonder what's the solution on Windows while using docker from testcontainers. The reason matches, the solution might be different... – Charles Tempo May 16 '23 at 13:47
0

this is permission issue . using docker desktop > settings > resources > file sharing >

and add your project directory path so docker engine can access it

Neo Mn
  • 150
  • 1
  • 12
  • 1
    This was the most helpful answer for me, and it did fix my issue. On MacOS I have a symbolic link "projects -> /System/Volumes/Data/projects", and I added the "/System/..." to the File Sharing list without success. Then it occurred to me that I needed to add the value from $(pwd), so I added "/projects" ... now everything works. – nvanwyen Apr 22 '23 at 20:47
  • @nvanwyen glad that solved your issue – Neo Mn Apr 24 '23 at 14:38
0

In Linux (Ubuntu) I got this message when I had running Docker Desktop and tried to start a DDEV container.
After shutting down Docker Desktop the DDEV container started without problems.

David
  • 5,882
  • 3
  • 33
  • 44