15

New to docker.

Installed docker from software management tool in mint 17.

When I run docker run hello-world I receive:

FATA[0000] Error response from daemon: Cannot start container a6bcc1ede2c38cb6b020cf5ab35ebd51b64535af57fa44f5966c37bdf89c8781: [8] System error: mountpoint for devices not found

When I look at the service logs (/var/log/upstart/docker.log) I see:

ERRO[0617] Couldn't run auplink before unmount: exec: "auplink": executable file not found in $PATH ERRO[0617] Couldn't run auplink before unmount: exec: "auplink": executable file not found in $PATH

: docker version

Client version: 1.6.2 Client API version: 1.18 Go version (client): go1.2.1 Git commit (client): 7c8fca2 OS/Arch (client): linux/amd64 Server version: 1.6.2 Server API version: 1.18 Go version (server): go1.2.1 Git commit (server): 7c8fca2 OS/Arch (server): linux/amd64

: docker info

Containers: 2 Images: 1 Storage Driver: aufs Root Dir: /var/lib/docker/aufs Backing Filesystem: extfs Dirs: 5 Dirperm1 Supported: false Execution Driver: native-0.2 Kernel Version: 3.13.0-24-generic Operating System: Ubuntu 14.04.3 LTS CPUs: 8 Total Memory: 15.6 GiB Name: DWDEV-HOME-HBABAI ID: K4GX:DTV6:547V:U3BO:YEOA:WVNU:NZEZ:L3GG:4W7U:IXNS:X3QK:5PVR WARNING: No memory limit support WARNING: No swap limit support

Update:

Installed sudo apt-get install aufs-tools, restarted docker service. I no longer see the following error:

ERRO[0617] Couldn't run auplink before unmount: exec: "auplink": executable file not found in $PATH

However, in the logs I see that when docker is starting it is warning me about memory mount point:

INFO[0000] -job init_networkdriver() = OK (0) /var/run/docker.sock is up WARN[0000] mountpoint for memory not found INFO[0000] Loading containers: start.

I have a feeling it has to do with cgroup...but i don't know anything about that technology (yet)...

Improve this question
2
  • It looks like your question fell on the floor and broke into pieces.  Please put it together for us. Commented Dec 15, 2015 at 9:09
  • @Scott - sorry...hope it is better now...thanks for pointing it out Commented Dec 15, 2015 at 15:54

2 Answers 2

Reset to default
26

It turned out that I needed to install cgroup-lite. It was a shot in the dark but I followed this answer

Improve this answer
2
  • You know, I had at some point found that out on my own, then forgot it. Now found your question when I ran into it again and remembered (and upvoted). Commented Jun 7, 2016 at 6:19
  • 1
    In Debian, the corresponding package is called cgroupfs-mount Commented Nov 7, 2017 at 14:29
3

I will add another answer here for app-people seeing this in 2020 on Debian, as my resolution to this problem was not present in any of the search hits found when googling the error string "mountpoint for devices not found".

Background:

  • Debian 8.11 running on Google Cloud Platform
  • Had a working Docker install 5 weeks ago with two containers running

Suddenly realised something had made the containers crash. The only remotely probable cause I could come up with was that I had deleted a parent folder on the host of which a subfolder was mapped as a volume. Another reason could be the mounting of an additional physical device.

The end result in any case was that trying to start any docker container resulted in the error message seen in the question ("mountpoint for devices not found") and no reboot (and hence upgrade of the kernel) had taken place.

The steps I took to debug the issue was

  1. Inspect the logs: journalctl -xn | less. Didn't really contain too much additional info
  2. Stop the Docker daemon (/etc/init.d/docker stop).
  3. Add a file /etc/docker/daemon.json where the sole content was {"debug": true}
  4. Try restarting the docker daemon only to see it fail
  5. Inspect the logs, which would now be filled with a lot more info

These cgroup related errors were the ones that led to the answer:

Jan 13 20:17:15 dev-acme-org dockerd[9022]: time="2020-01-13T20:17:15.964631675Z" level=warning msg="Your kernel does not support cgroup memory limit" Jan 13 20:17:15 dev-acme-org dockerd[9022]: time="2020-01-13T20:17:15.964654637Z" level=warning msg="Unable to find cpu cgroup in mounts" Jan 13 20:17:15 dev-acme-org dockerd[9022]: time="2020-01-13T20:17:15.964667575Z" level=warning msg="Unable to find blkio cgroup in mounts" Jan 13 20:17:15 dev-acme-org dockerd[9022]: time="2020-01-13T20:17:15.964680057Z" level=warning msg="Unable to find cpuset cgroup in mounts" Jan 13 20:17:15 dev-acme-org dockerd[9022]: time="2020-01-13T20:17:15.964750643Z" level=warning msg="mountpoint for pids not found" Jan 13 20:17:15 dev-acme-org dockerd[9022]: time="2020-01-13T20:17:15.980250151Z" level=debug msg="Cleaning up old mountid : start." Jan 13 20:17:15 dev-acme-org dockerd[9022]: Error starting daemon: Devices cgroup isn't mounted

OK, something about cgroups and mounting. That led me to a workaround for a different cgroups issue that could be applied in this case, of which the the only commands that seemed to have an effect were

  1. /etc/init.d/docker stop
  2. cgroupfs-mount
  3. /etc/init.d/docker start

Now, upon starting Docker again, the logs still contained a few lines of cgroup related errors:

Jan 13 20:24:42 dev-acme-org dockerd[9775]: time="2020-01-13T20:24:42.258571633Z" level=warning msg="Your kernel does not support cgroup memory limit" Jan 13 20:24:42 dev-acme-org dockerd[9775]: time="2020-01-13T20:24:42.258591020Z" level=warning msg="Unable to find cpu cgroup in mounts" Jan 13 20:24:42 dev-acme-org dockerd[9775]: time="2020-01-13T20:24:42.258937091Z" level=warning msg="mountpoint for pids not found"

But half of them (blkio, cpuset) were gone, and more importantly, the next line read:

Jan 13 20:24:42 dev-acme-org dockerd[9775]: time="2020-01-13T20:24:42.259420798Z" level=info msg="Loading containers: start."

And finally

Unit docker.socket has finished starting up.

So, basically, remounting the cgroup stuff fixed the issue. No need to reboot.

Improve this answer
2
  • 2
    I had accidentally done a umount -a and come to this issue as new containers wont start up. A simple reboot does all the mounts from /etc/fstab and your good to go. Commented Jul 11, 2020 at 12:22
  • me too @MichaelP it was the solution sadly, thanks! Commented Dec 16, 2021 at 14:09

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.