New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem mounting volumes for log (/dev/log) #2465

ganimp84 opened this Issue Jan 19, 2018 · 7 comments


None yet
9 participants
Copy link

ganimp84 commented Jan 19, 2018

Expected behavior

Facing problem in mounting the volume for log after upgrading to latest docker for mac version
Version 17.12.0-ce-mac47 (21805)

Following is the Yaml config used in docker-compose file for one of the service.

      - /dev/log:/dev/log

Earlier, we were able to start the containers and mount this volume without any problem. Also, able to see the logs inside the VM with the cmd tail -f /var/log/syslog inside the moby VM

Actual behavior

Now, when starting the containers docker-compose up -d, getting the following error,

The path /dev/log
is not shared from OS X and is not known to Docker.

When tried to check the path by connecting to the VM using the cmd

screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty`

The path /dev/log doesn't exist. Also, I noticed that VM used to say "Welcome to moby". But, the new VM used now is "linuxkit"


  • Full output of the diagnostics from "Diagnose & Feedback" in the menu

Docker for Mac: version: 17.12.0-ce-mac47 (72b93a017350990850ddc37cd341bd16fce3e911)
macOS: version 10.12.6 (build: 16G29)
logs: /tmp/3AD5DC18-2AAD-4D3F-8BA7-4577EC39A7DD/20180119-110821.tar.gz
[OK] db.git
[OK] vmnetd
[OK] dns
[OK] driver.amd64-linux
[OK] virtualization VT-X
[OK] app
[OK] moby
[OK] system
[OK] moby-syslog
[OK] kubernetes
[OK] env
[OK] virtualization kern.hv_support
[OK] slirp
[OK] osxfs
[OK] moby-console
[OK] logs
[OK] docker-cli
[OK] menubar
[OK] disk

Steps to reproduce the behavior

  1. create a docker-compose configuration as below (including volume mounting for logs)
    image: nginx:latest
        - "8080:80"
        - /dev/log:/dev/log
  1. Try to start the containers like this,
    docker-compose up -d

This comment has been minimized.

Copy link

elatt commented Jan 19, 2018

I just ran into this issue as well. FWIW, it seems there is a busybox variant of syslogd on the system, so I was able to launch the daemon with syslogd -O /var/log/messages which created /dev/log for me. However, presumably this will eventually fill the disk of the VM so hopefully the docker comes up with a more elegant solution.


This comment has been minimized.

Copy link

ganimp84 commented Jan 22, 2018


Thanks a lot for this. It's working for me.


This comment has been minimized.

Copy link

docker-desktop-robot commented May 9, 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale


This comment has been minimized.

Copy link

matt2000 commented Jun 29, 2018

I believe OSX has syslog at /var/run/syslog instead of /dev/log. Can you try?:

    - /var/run/syslog:/dev/log

This comment has been minimized.

Copy link

ferry commented Sep 25, 2018

executing 'syslogd -O /var/log/messages' in the xhyve/linuxkit vm is also working for me


This comment has been minimized.

Copy link

ijharulislam commented Jan 17, 2019

I am also facing the same issue. How to fix it?


This comment has been minimized.

Copy link

sprive commented Jan 27, 2019

@matt2000 On Docker for Mac, you can't directly mount /var/run/syslog because it isn't in the share list prefs. But if you try to add it to File Sharing, when you attempt restart you are notified that /var/run/syslog "overlaps" with "/private".

This feels like a documentation issue, not software.

There are some different ways to solve logging in general, or work around it. Where it gets awkward is if the user has requirements to respect: for example, they can not modify the code that gets placed into the container, so user is stuck with code that hardcoded /var/log (and this is common, since it's faster than pointing to a network address).

Below is what seems like an ideal solution, except it appears it USED to work and something changed in Docker for Mac (image, perhaps... hazy):

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment