I've been binding the host docker socket and cli so that I can run docker and compose commands from within running containers for over a year without issue but since updating to docker version 20.10.7 and compose version 1.29.2 I can't get my containerised environment to launch without the following error:
invalid mount config for type "bind": bind source path does not exist: /usr/local/bin/docker
Nothing has changed other than I updated Docker Desktop.
The location of the docker binary (symlink) on the host is still present:
0 lrwxr-xr-x 1 aadams-mbp staff 54 3 Aug 2018 /usr/local/bin/docker -> /Applications/Docker.app/Contents/Resources/bin/docker
The target of the symlink permissions look like this:
133608 -rwxr-xr-x 1 root admin 68405888 7 Jul 17:59 /Applications/Docker.app/Contents/Resources/bin/docker
This snippet is from my docker-compose.yaml file:
volumes:
# Bind docker CLI so can run docker commands
# from inside the container. Double check the
# location of the source binary on hosts that
# are not Mac OS. Docker might be in /usr/bin/docker,
# but on Mac OS it is at /usr/local/bin/docker.
- type: bind
source: /var/run/docker.sock
target: /var/run/docker.sock
- type: bind
source: ${DOCKER_BIN_SRC}
target: /usr/bin/docker
The ${DOCKER_BIN_SRC} is pulled in from a .env file (snippet):
##
# Docker bind
#
DOCKER_BIN_SRC=/usr/local/bin/docker
I am running on Mac OS Mojave version 10.14.6
Related
I'm running into an issue with MacOS Ventura where by all bind volumes - where I link a directory on my host machine to one on the container - created with docker-compose are empty. I've tested the same scripts on MacOS 12.4 and 12.6 and they work as expected giving me the same directory contents on the container as on the host, so it seems v13 changed some permission.
The docker-compose.yml file:
version: "3"
services:
bash:
image: ubuntu:latest
stdin_open: true
tty: true
volumes:
- ./:/app
command: "/bin/bash"
So this should be creating a directory on the container called /app and linking that to the host directory the compose file is in.
But when I start the container:
❯ docker-compose up --build
[+] Running 1/0
⠿ Container ruby-docker-bash-1 Created 0.0s
Attaching to ruby-docker-bash-1
And login, the /app directory is empty:
❯ docker exec -it ruby-docker-bash-1 /bin/bash
root#9644de175d48:/# cd app/
root#9644de175d48:/app# ls -la
total 4
drwxr-xr-x 2 root root 40 Feb 1 09:59 .
drwxr-xr-x 1 root root 4096 Feb 1 09:39 ..
The total 4 is really weird here as there are 4 files supposed to be there, but not accessible:
root#9644de175d48:/app# cat Gemfile
cat: Gemfile: No such file or directory
This is the directory contents on the host are:
❯ ls -la
.rw-r--r-- 2.7k paul 1 Feb 09:31 Dockerfile
.rw-r--r-- 3.9k paul 1 Feb 09:32 Gemfile
.rw-r--r-- 27k paul 1 Feb 09:32 Gemfile.lock
.rw-r--r-- 149 paul 1 Feb 10:00 docker-compose.yml
If anyone has any experience with what might be going wrong or how I can get past this absolute time-sink of an issue, I'd really appreciate it.
Thank you!
I figured it out. I use Colima on MacOS, as there is no MacOS VM by docker.
Then I found this comment on a Colima repo issue, https://github.com/abiosoft/colima/issues/500#issuecomment-1343103477, where a user had mentioned they weren't able to sync directories.
To fix volumes on MacOS, using Colima, I did the folowing:
colima delete # reset
colima start --mount-type 9p
This doesn't seem to be documented anywhere. I’ve been through the site, the readme.
But I did find this line of code inside of the Colima repo:
validMountTypes := map[string]bool{"9p": true, "sshfs": true}
if util.MacOS13OrNewer() {
validMountTypes["virtiofs"] = true
}
I’m in MacOS 13, so it seems like there are issues with virtiofs and not in the older 9p mount type.
On mac, /a/b is with below permissions:
$ ls -l /a/b
total 0
drwxrwxrwx 2 root wheel 64 13 Jan 08:50 b
$ whoami
user1
$
Below is the docker-compose file to mount /a/b from docker container:
version: '2'
services:
someapp:
build:
context: .
args:
DOCKER_GID: ${DOCKER_GID}
DOCKER_VERSION: ${DOCKER_VERSION}
DOCKER_COMPOSE: ${DOCKER_COMPOSE}
volumes:
- /a/b:/var/some_mount
- /var/run/docker.sock:/var/run/docker.sock
ports:
- "8080:8080"
On running docker-compose up -d someapp, I see below error:
ERROR: for docker-folder_someapp_1 Cannot start service someapp: b'Mounts denied: \r\nThe path /a/b\r\n is not shared from OS X and is not known to Docker.\r\nYou can configure shared paths from Docker -> Preferences... -> File Sharing.\r\nSee https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.\r\n.'
ERROR: for someapp Cannot start service someapp: b'Mounts denied: \r\nThe path /a/b\r\nis not shared from OS X and is not known to Docker.\r\nYou can configure shared paths from Docker -> Preferences... -> File Sharing.\r\nSee https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.\r\n.'
ERROR: Encountered errors while bringing up the project.
Following the instructions when I add /a/b using File sharing option to existing list:
I get another error popup: The export path /Users/user1/Documents/:a/:a:b overlaps with the export /Users
Another observation is, installing docker on MacOS, using VMWare to run docker, unlike ubuntu :
$ ps -eaf | grep docker
0 11100 1 0 9:02am ?? 0:00.07 /Library/PrivilegedHelperTools/com.docker.vmnetd
1873530912 11108 11038 0 9:02am ?? 0:01.45 /Applications/Docker.app/Contents/MacOS/com.docker.supervisor -watchdog fd:0
I do not see such mount deny issues, running docker daemon in Ubuntu.
1)
How to mount path(/a/b) of docker host to docker container's(/var/some_mount) ? in macos
2)
Is the explicit file sharing needed from docker host, because, docker installation on MacOS makes docker host run on VMWare and docker client run on MacOS?
I'm trying to make an application work on Windows that's been developed only on Unices. It's all dockerized and it uses the traefik load balancer. The volumes for the docker for running traefik looks like this:
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro,delegated
- ${PWD}/load_balancer/traefik.toml:/etc/traefik/traefik.toml:ro,delegated
The first volume works fine on Mac or Linux, but does it on Windows? The application is failing (the load balancer is giving a 404) and it might be related to that volume. When I start the image, the socket looks like a socket:
/ # ls -laF /var/run/docker.sock
srw-rw---- 1 root root 0 Sep 2 11:04 /var/run/docker.sock=
Is this working? Any way to test it? What's the correct way of doing this?
Trying to figure this out, I tried replacing it with this:
volumes:
- //./pipe/docker_engine:/var/run/docker.sock
based on various articles and bug reports I found online. The docker image starts but it fails in the same way and now in the docker container it looks like a directory:
/ # ls -laF /var/run/docker.sock
total 4
drwxr-xr-x 2 root root 40 Sep 3 14:52 ./
drwxr-xr-x 1 root root 4096 Sep 3 14:57 ../
Following Marc ABOUCHACRA's answers, I tried:
volumes:
- type: npipe
source: ////./pipe/docker_engine
target: /var/run/docker.sock
consistency: delegated
but that also looks like a directory:
/ # ls -laF /var/run/docker.sock
total 4
drwxr-xr-x 2 root root 40 Sep 3 14:52 ./
drwxr-xr-x 1 root root 4096 Sep 3 14:57 ../
I also tried this:
volumes:
- npipe:////./pipe/docker_engine:/var/run/docker.sock:ro,delegated
but that fails with this error:
ERROR: Volume npipe:////./pipe/docker_engine:/var/run/docker.sock:ro,delegated has incorrect format, should be external:internal[:mode]
The whole docker-compose.yml section looks like this:
lb:
image: load-balancer
build: ${WORKSPACE}/go-home/load_balancer
ports:
- 80:80
- 443:443
links:
- wifi-ui-dev
- wifi-ui-prod
- portal
- wifi-api
env_file:
- .env
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro,delegated
- ${PWD}/load_balancer/traefik.toml:/etc/traefik/traefik.toml:ro,delegated
My question is specifically about running this docker image, which is a Linux, on a Windows host, running Docker for Windows. I understand that I can run it on a Linux host by installing Linux on another machine or a VM on the Windows machine, it's equivalent. Running Windows guests is not what I'm after either in case there's a way of exposing sockets from Windows to Windows only.
If you cannot nor want use network sockets, then you can use named pipes.
The syntax depends whether you run Linux or Windows containers and on the shell you use.
Linux containers
If you run Linux containers on a Windows machine, this seems to work using Powershell or bash:
docker run --rm -it -v "//var/run/docker.sock://var/run/docker.sock" image_with_docker docker version
Please note the extra / in front of /var/run/docker.sock, both for the source and destination volumes.
Windows containers
If you run Windows containers on a Windows machine, this seems to work using Powershell or bash:
docker run -v "//./pipe/docker_engine://./pipe/docker_engine" --rm -it image-with-docker docker version
Note that this works only in Powershell:
docker run -v "\\.\pipe\docker_engine:\\.\pipe\docker_engine" --rm -it image-with-docker docker version
Therefore, it's better to use the version with /.
Extra - docker-compose.yml
If you use a docker-compose.yaml file, this works with Windows containers.
version: '3.7'
services:
docker:
image: image-with-docker
command:
- docker
- version
volumes:
- type: npipe
source: \\.\pipe\docker_engine
target: \\.\pipe\docker_engine
With Linux containers, you can use the shortened form:
docker:
image: image-with-docker
command:
- docker
- version
volumes:
- //var/run/docker.sock://var/run/docker.sock
Extra - Kubernetes
If you are running Windows containers on a Windows node in Kubernetes, this seems to work:
apiVersion: v1
kind: Pod
spec:
containers:
- name: docker
image: image-with-docker
command:
- powershell
args:
- Start-Sleep
- "999999"
volumeMounts:
- mountPath: \\.\pipe\docker_engine
name: dockersock
volumes:
- name: dockersock
hostPath:
path: \\.\pipe\docker_engine
type: null
nodeSelector:
kubernetes.io/os: windows
In this case, beside using the \, please note the type: null in the definition of the dockersock volume: if you don't set it, it will not work.
Notes
Everything was tested on docker 19.03 and on Kubernetes 1.18.
Client:
Version: 19.03.3
API version: 1.40
Go version: go1.12.10
Git commit: 2355349d-
Built: 10/14/2019 16:41:26
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.8
API version: 1.40 (minimum version 1.24)
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:37:20 2020
OS/Arch: windows/amd64
Experimental: false
If you encounter the following error on windows:
cannot create container for service portainer: Unrecognised volume spec: file '\.\pipe\docker_engine' cannot be mapped. Only directories can be mapped on this platform
ERROR: Encountered errors while bringing up the project.
Try adding an extra slash to it, resulting in following volumes section:
volumes:
- source: \\.\pipe\docker_engine\
target: \\.\pipe\docker_engine\
type: npipe
Tested with compose 3.7 and docker CE 19.03.12
Using short syntax with the type of the bind mount is not possible : npipe:////./pipe/docker_engine:/var/run/docker.sock:ro,delegated
You need to use the long syntax in your compose file :
volumes:
- type: npipe
source: ////./pipe/docker_engine
target: /var/run/docker.sock
consistency: delegated
You can find some documentation about the long syntax in the official documentation. This syntaxe is from v3.2
Also keep in mind what #lucas-ramage said about using windows container only when using npipe.
In 2022, on Windows 11, what worked for me is below volume configuration (Note the doube slash (//) on the host side of configruation. Not sure why docker_enginer variant does not work for me.
-v "//var/run/docker.sock:/var/run/docker.sock"
Per the Docker for Windows FAQ,
On Docker Desktop for Windows, clients can connect to the Docker Engine through a named pipe: npipe:////./pipe/docker_engine
See also this issue on GitHub,
The windows version of docker doesn't use unix socket (/var/run/docker.sock) but npipe (npipe:////./pipe/docker_engine). So you have either
to switch to linux container which runs docker in a full virtualized linux with unix socket
to pass the npipe instead of the unix socket to the container (windows container only)
to use a network socket (should work with linux and windows container)
However, since this is a Linux container, your options are either A) Run docker in a virtual machine (first choice above), or B) Use a network socket (the third choice).
When I start nexus3 in a docker container I get the following error messages.
$ docker run --rm sonatype/nexus3:3.8.0
Warning: Cannot open log file: ../sonatype-work/nexus3/log/jvm.log
Warning: Forcing option -XX:LogFile=/tmp/jvm.log
Java HotSpot(TM) 64-Bit Server VM warning: Cannot open file ../sonatype-work/nexus3/log/jvm.log due to Permission denied
Unable to update instance pid: Unable to create directory /nexus-data/instances
/nexus-data/log/karaf.log (Permission denied)
Unable to update instance pid: Unable to create directory /nexus-data/instances
It indicates that there is a file permission issue.
I am using Red Hat Enterprise Linux 7.5 as host machine and the most recent docker version.
On another machine (ubuntu) it works fine.
The issue occurs in the persistent volume (/nexus-data). However, I do not mount a specific volume and let docker use a anonymous one.
If I compare the volumes on both machines I can see the following permissions:
For Red Hat, where it is not working is belongs to root.
$ docker run --rm sonatype/nexus3:3.8.0 ls -l /nexus-data
total 0
drwxr-xr-x. 2 root root 6 Mar 1 00:07 etc
drwxr-xr-x. 2 root root 6 Mar 1 00:07 log
drwxr-xr-x. 2 root root 6 Mar 1 00:07 tmp
On ubuntu, where it is working it belongs to nexus. Nexus is also the default user in the container.
$ docker run --rm sonatype/nexus3:3.8.0 ls -l /nexus-data
total 12
drwxr-xr-x 2 nexus nexus 4096 Mar 1 00:07 etc
drwxr-xr-x 2 nexus nexus 4096 Mar 1 00:07 log
drwxr-xr-x 2 nexus nexus 4096 Mar 1 00:07 tmp
Changing the user with the options -u is not an option.
I could solve it by deleting all local docker images: docker image prune -a
Afterwards it downloaded the image again and it worked.
This is strange because I also compared the fingerprints of the images and they were identical.
An example of docker-compose for Nexus :
version: "3"
services:
#Nexus
nexus:
image: sonatype/nexus3:3.39.0
expose:
- "8081"
- "8082"
- "8083"
ports:
# UI
- "8081:8081"
# repositories http
- "8082:8082"
- "8083:8083"
# repositories https
#- "8182:8182"
#- "8183:8183"
environment:
- VIRTUAL_PORT=8081
volumes:
- "./nexus/data/nexus-data:/nexus-data"
Setup the volume :
mkdir -p ./nexus/data/nexus-data
sudo chown -R 200 nexus/ # 200 because it's the UID of the nexus user inside the container
Start Nexus
sudo docker-compose up -d
hf
You should attribute correct right to the folder where the persistent volume is located.
chmod u+wxr -R <folder of /nexus-data volumes>
Be carefull, if you execute previous command, it would give write, read and execution right to all users. If you want to give more restricted right, you should modify the command.
How to use the docker mount option to share a local folder in Docker Container? Currently, I am using this command but I am not being successful.
docker run --mount source='c:\temp',target='c:\temp' -i newname:latest
I get this error -
C:\Program Files\Docker\docker.exe: Error response from daemon: invalid mount config for type "volume": invalid volume name.
My environment:
Host: Windows Server, version 1709
Docker Container: Windows Server Core, v1709
You need to use bind mount. Example below maps your host directory c:\users\public\ to the one which is inside container c:\users\public and then outputs content of that directory.
PS C:\Users\gsuvalia> docker run --rm --mount type=bind,source=c:\users\public\,destination=c:\users\public\ microsoft/nanoserver powershell get-childitem c:\users\public
Directory: C:\users\public
Mode LastWriteTime Length Name
---- ------------- ------ ----
d-r--- 12/1/2017 10:16 PM Documents
d-r--- 7/16/2016 6:47 AM Downloads
d-r--- 7/16/2016 6:47 AM Music
d-r--- 12/1/2017 10:16 PM Pictures
d----- 8/22/2017 10:26 PM Roaming
d-r--- 7/16/2016 6:47 AM Videos