Solved! – Cannot start a container. System error: not a directory – Docker Compose


After spending some time using Docker in my development projects one day, without warning, everything started to go wrong.

When trying to run several containers with docker-compose up the execution stopped with a strange error: Cannot start container XXXXX: System error: not a directory.


After the initial shock I began to investigate what could be the root cause in a system that did not give any problems before. I dismissed Docker engines upgrades. The development system remained the same.

Analyzing the file docker-compose.yml I came to the conclusion that the problem occurred in the containers that wanted to mount files from inside the volumes section:


Searching solutions in Internet most people say that apparently docker-compose doesn’t allow mounting files the same way as directories. This reason was very weird.

My first solution was commenting out the lines that tried to mount files, run docker-compose up to create the containers, stop them and the remove the comments and start them again.

After that the containers run without problems and the files appeared in their right locations.

It doesn’t make sense. I decided to inspect the failing container with docker inspect <containername>.


Everything seemed fine. But I had another place to check.

My development environment run inside a Mac OSX. That means I have to run a Docker Machine via VirtualBox to be able to run a Docker Daemon.

I log in and look the volumes that the docker-machine had available.



Then I saw the problem. It is assumed that on Mac when docker-machine is installed inside a VirtualBox machine, this machine has assigned a shared folder. This shared folder give permissions to the directory /Users to this virtual machine so it can access and manage data inside it.

In the above list this shared folder does not appear. I create this folder with VirtualBox UI.


I powered off the virtual machine and then power up it again with docker-machine and checked the results.


Now an input /Users appeared in the mount listing.

I closed the session at docker-machine and tried to run the containers again. This time everything went back to normal and the containers were powered up without problems.


Apparently, docker-machine did not have access to resources because it did not had available the shared folder in /Users. All was due to a previous test I did with the docker-osx-dev. This is a system that uses rsync to synchronize host directories with the ones inside the container.

It is used to replace the shared folders managed by VirtualBox, which are slower. The rsync method is better than shared folders. But the first step performed by docker-osx-dev to achive that is to remove VirtualBox shared folder because it conflicts with rsync method.

Once discovered the problem, it finally makes sense and once solved I can reuse Docker without more problems.

Leave a Reply

Your email address will not be published. Required fields are marked *