Docker-selenium: Receiving 'mount denied' error when trying to stand up containers with Docker Compose

Created on 12 Apr 2018  路  4Comments  路  Source: SeleniumHQ/docker-selenium

Meta - I am receiving an error when trying to create containers via docker compose. Please see below:

`位 docker-compose up
Starting dockerconfig_hub_1 ... done
Recreating 1fe18c8217be_dockerconfig_chrome_1 ... error
Recreating 5a87ecdd1d34_dockerconfig_firefox_1 ...

ERROR: for 1fe18c8217be_dockerconfig_chrome_1 Cannot create container for service chrome: b'Mount denied:\nThe source path "\\dev\\shm:/dev/shm"\nis not a valid Windows paRecreating 5a87ecdd1d34_dockerconfig_firefox_1 ... error

ERROR: for 5a87ecdd1d34_dockerconfig_firefox_1 Cannot create container for service firefox: b'Mount denied:\nThe source path "\\dev\\shm:/dev/shm"\nis not a valid Windows path'

ERROR: for chrome Cannot create container for service chrome: b'Mount denied:\nThe source path "\\dev\\shm:/dev/shm"\nis not a valid Windows path'

ERROR: for firefox Cannot create container for service firefox: b'Mount denied:\nThe source path "\\dev\\shm:/dev/shm"\nis not a valid Windows path'
ERROR: Encountered errors while bringing up the project.`

Docker-Selenium Image Version(s):
3.11.0-californium
Docker Version:
Version 18.03.0-ce-win59 (16762)
OS:
Windows 10 Pro - 1709
OS build: 16299.309

-->

Expected Behavior - When using Docker Compose to stand up Firefox and/or Chrome containers, I anticpate that running docker-compose up using the file below will stand up my docker containers

'version: '3'
services:
firefox:
image: selenium/node-firefox:3.11.0-californium
volumes:
- /dev/shm:/dev/shm
shm_size: '2gb'
depends_on:
- hub
environment:
HUB_HOST: hub

chrome:
image: selenium/node-chrome:3.11.0-californium
volumes:
- /dev/shm:/dev/shm
shm_size: '2gb'
depends_on:
- hub
environment:
HUB_HOST: hub

hub:
image: selenium/hub:3.11.0-californium
ports:
- "4444:4444"'

Actual Behavior - I am receiving the error seen above and the containers are not created.

Most helpful comment

Can you try running the $Env:COMPOSE_CONVERT_WINDOWS_PATHS=1 in powershell and see if that helps.

All 4 comments

I have the same problem

if you're running these images on windows, it's likely that you have enough resources available to not try to mount "shared memory."

you should be able to run the images without that volume just fine

Can you try running the $Env:COMPOSE_CONVERT_WINDOWS_PATHS=1 in powershell and see if that helps.

Thanks @DamolAAkinleye for the hint!

Basically, what happens is that there seems to be a bug in docker-compose that is producing this. The whole workaround can be implemented like this:

This is the docker-compose file:

version: '3'
services:
  firefox:
    image: selenium/node-firefox:3.12.0-cobalt
    volumes:
      - /dev/shm:/dev/shm
    shm_size: '2gb'
    depends_on:
      - hub
    environment:
     HUB_HOST: hub

  chrome:
    image: selenium/node-chrome:3.12.0-cobalt
    volumes:
      - /dev/shm:/dev/shm
    shm_size: '2gb'
    depends_on:
      - hub
    environment:
      HUB_HOST: hub

  hub:
    image: selenium/hub:3.12.0-cobalt
    ports:
      - "4444:4444"

So, before doing docker-compose up, set the env var set COMPOSE_CONVERT_WINDOWS_PATHS=1, and then docker-compose up.

Related issue: https://github.com/docker/for-win/issues/1829

Was this page helpful?
0 / 5 - 0 ratings