Boot error inside a Docker for Windows container

I am having a strange issue when attempting to launch an Erlang application. My development environment is as follows:

  • Windows 10 Pro, version 10.0.18363,
  • Docker for Windows, version (43472) stable,
  • Base image: Ubuntu 18.04,
  • Erlang version installed on the image via asdf: OTP-19.3.

When I run a container based on the image described above, I mount (type=bind) a Windows folder to /workspace. This folder contains an Erlang application called email that I need to access through a symbolic link called email-0.0.1.

However, trying to start it with erl -pa email-0.0.1/ebin results in the following error:

(no error logger present) error: <0.16.0>

and it blocks there, not allowing me to type anything.


  • If I don’t use the symbolic link, e.g. erl -pa email/ebin this works fine.
  • If I move the application out of the shared folder, let’s say /private, then erl -pa /private/email-0.0.1/ebin also work as expected.

Does anyone have already encountered this issue?

Or more likely, how could I get the real error instead of just process id?

Many thanks in advance.


Just try to avoid bind mounting your application. Will probably cause much more trouble than only this…

Besides of this, I’m not sure if the layer of windows -> Linux VM -> docker container are all capable of understanding how the “link” you says you use would work…

To clarify: the link I am talking about is a regular Linux symbolic link that is only understood by my Docker container (and not by the Windows host).

Of course I would really like to get rid of those symbolic links, but I have no control of that.

Any other suggestions?


As this symbolic link lives on your bind mount which is NTFS/FATx, I would not rely on it surviving this…

Aside of this… Does it work with the link in a clean Linux environment?

What is the link? Does it point to an executable? A folder? Something else? Is there some minimal project that you can share for our windows users to reproduce?

The symbolic link is pointing to a folder that contains a bunch of Beam files.

Luckilly for me, this was a Docker for Windows issue that just got fixed a few hours ago.


@NobbZ thank you for your time.