Mounts denied: \r\nThe path /a/b \r\n is not shared from OS X and is not known to Docker - docker

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?

Related

Docker Compose binding docker cli error: invalid mount config for type "bind": bind source path does not exist: /usr/local/bin/docker

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

Docker device-cgroups-rule, mknod and mount

I'm attempting to implement what is described here:
https://docs.docker.com/engine/reference/commandline/create/#dealing-with-dynamically-created-devices---device-cgroup-rule
Similar to the page I am creating (and then starting) a container as follows:
docker create --device-cgroup-rule='b 8:* rmw' -name my-container my-image
Quoting from the above page
Then, a user could ask udev to execute a script that would docker exec
my-container mknod newDevX c 42 the required device when it is
added.
Within the container (docker exec -it my-container sh) I then mknod a device:
mknod /dev/sdc1 b 8 33
The device was reported as above by lsblk:
sdc 8:32 1 500M 0 disk
└─sdc1 8:33 1 500M 0 part
mknod succeeds but mounting /dev/sdc1 gives an error:
$ mount /dev/sdc1 /mnt
mount: /mnt: permission denied.
I also tried various other things like
mknod with -m
docker start with --cap-add=CAP_MKNOD
EDIT:
I also tried starting with --privileged but without the /dev/sdc1 precreated and it worked. It must have something to do with Capabilities or other differences between privileged and non-privileged mode. I tried with --cap-add=CAP_MKNOD and CAP_SYS_ADMIN but it now reports a difference message:
$ mount /dev/sdc1 /mnt
mount: /mnt: cannot mount /dev/sdc1 read-only.

Why is File Mounted on Container via docker-compose not Accessible?

In my docker-compose file, I try to mount a file from the host into the docker container.
The docker-compose file I have something like this:
version "2"
services:
myservice:
image: images/previmage:1.0.0
volumes:
- /opt/files/aaa.conf:/aaa.conf
After the service is started, I look at the contents at the root of the container using docker from the host:
sudo docker container exec myservice_1 ls /
The result of that ls command for the aaa.conf entry shows that it looks like it is there, but permissions are not what I expect:
drwxr-xr-x. 2 root root 6 Apr 11 2018 opt
-?????????? ? ? ? ? ? aaa.conf
ls: cannot access /aaa.conf: Permission denied
Similarly, if I try other commands like 'cat aaa.conf', I get Permission denied.
I understand that permissions for the file need to be set on the host side.
On the host I made permissions both 755 and then 777, but I still get Permission denied.
Is this the expected behavior?
Edit [running on AWS/EC2]
sudo docker container exec myservice_1 cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
sudo docker container exec myservice_1 id -u
33016
I had same problem, It's for SELinux (Check this post)
Disable SELinux for a specific container
You can disable SELinux for a specific container by adding --security-opt label:disable to your docker run command:
docker container run --security-opt label:disable myservice_1
Adding SELinux Rule (Recommended)
According to this post, You can also use this command to enable access to the files
chcon -Rt svirt_sandbox_file_t /path/to/volume
Completely disable SELinux!
Not recommended, but also works:
su -c "setenforce 0"

How do you mount the docker socket on Windows?

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).

Permission issues in nexus3 docker container

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.

Resources