Advice on building Docker images on Windows

Since the stable release of “Docker for Windows” in July 2016, you can work quite well with Docker on Windows. And its mostly the same workflows and user-experience as on Linux/MacOS.

However there are some things that could be improved (like sharing folders/drives between Host and Containers) and also some more not-so-obvious quirks.
One of those problems can arise when building images and the resulting container would exit immediately with

standard_init_linux.go:175: exec user process caused "no such file or directory

Read on after the jump whats causing this and how to fix it and prevent it from happening again.

The problem

Windows is using \r\n as linefeeds whereas Linux/Mac/everyone-else is using \n. Git has a nice feature/config called “autocrlf” which usually gets set to “true” on Windows. This will automagically convert \n to \r\n on checkout but wont commit it. Read more about this here https://help.github.com/articles/dealing-with-line-endings/

This is all nice and cool unless you are dealing with files that really need to preseve their line endings. Like e.g. bash files. Those are starting with a shebang #!/bin/bash and if the line-ending is changed to \r\n and you are building a docker image which has that script as entrypoint.sh , the container will die immediately and you will see the above error in “docker logs CONTAINER_ID”. The problem is that Linux thinks the \r is part of the /bin/bash filename and therefore cannot find it.

The solution

Solving this is quite easy if you know why its happening. You can either globally set git config to not touch the line-endings or on a per-repo basis. Which is better/safer imho.

You can simply create a .gitattributes (mind the period) file with content

# Auto detect text files and perform LF normalization
* text=auto

# dont touch bash scripts so it doesnt mess up the shebang #!/bin/bash
*.sh text eol=lf

After re-building your images, the resulting containers should work again.

By using a .gitattributes file the problem is solved for anyore cloning your repo no matter what config of autocrlf they might have set on their PC or not.

  1. No trackbacks yet.