moby: Docker for Mac: standard_init_linux.go:175: exec user process caused "exec format error"

I was able to resolve this error for my docker container by adding a Sha-Bang on top of the shell script that I was trying to run as CMD in dockerfile

#!/bin/bash

@tompscanlan I ran into this and realized I was building the go executable on my Mac and then trying to run it in an Ubuntu container. Updating the build command to the following fixed the issue.

env GOOS=linux GOARCH=386 go build

Had this issue. Was the result of a noob space at the beginning of my entrypoint script #!/bin/bash

You need to issue a shell command. Like bash at the end of the statement.

I’m seeing the same symptom from packaging a go application

Besides OS X this also happens on Linux Mint 17.3 while running a static compiled Go binary in a Docker scratch container:

Client:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 22:00:36 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 22:00:36 2016
 OS/Arch:      linux/amd64

Yes we are planning to make it fully transparent in future. On 12 Jul 2016 00:05, “Marcello de Sales” notifications@github.com wrote:

@thaJeztah https://github.com/thaJeztah @StefanScherer https://github.com/StefanScherer I would be glad to have those suggestions… This should be transparent for Mac users having that Docker can run anything anywhere 😃

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/docker/docker/issues/23865#issuecomment-231891699, or mute the thread https://github.com/notifications/unsubscribe/AAdcPCL5eqh1gY1Y37YYVGNoaGSBlhgVks5qUswigaJpZM4I8Dmq .

Docker for Mac is able to run Raspberry Pi images (and others) if the image contains the qemu binary. The rpi-whoami is supposed to be a very small image lacking other binaries, so this does not work out of the box with Docker for Mac.

But try one of the resin/rpi-raspbian based images, these will work. Eg. docker run --rm -it resin/rpi-raspbian uname -a

Maybe Docker for Mac magically mounts the qemu binary in the future into the container so that every image just works 😃

What will be the W/A for now? I’m running on 1.12 rc4-beta20 for MAC. See same symptoms.

@archyufa @perrohunter build from an image that supports qemu binary, such as the resin/rpi-raspbian based images mentioned above.

Just encountered this issue as well. Ended up being a layer that wasn’t pulled properly. Running docker system prune --all and re-pulling the image fixed the issue.

Why is this issue closed, it seems like folks are still hitting it.
Can someone clarify what the problem is?

I’m also hitting this on a Mac when building a go static binary and adding it FROM scratch to a docker container.

One of the reasons why this error could happen is line endings

If you are on Windows, make sure that your custom entrypoint file uses LF (Unix style) line endings, not CRLF (Windows style line endings).

It could happen if you created entrypoint file on Windows, or checked out it from Git repository on Windows (it converts line endings LF to CRLF by default on Windows).

Same here…

docker version
Client:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:        Sat Jul  2 14:58:48 2016
 OS/Arch:      linux/arm

Server:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:        Sat Jul  2 14:58:48 2016
 OS/Arch:      linux/arm

docker info
Containers: 4
 Running: 0
 Paused: 0
 Stopped: 4
Images: 52
Server Version: 1.12.0-rc3
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host overlay
Swarm: active
 NodeID: bwi2ypaaeoucvmzzpww0aynhe
 IsManager: Yes
 Managers: 1
 Nodes: 3
 CACertHash: sha256:2e89359de883dc71c6ea52ea218de6f820c9e899be76b68a726abffada835ada
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 4.4.15-hypriotos-v7+
Operating System: Raspbian GNU/Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 862 MiB
Name: pi1
ID: W2S2:C4RD:QPXV:OAKE:BDGW:X7ZG:TVZC:ANU7:SH4K:UXY2:ERCR:JSAV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No cpuset support
Insecure Registries:
 127.0.0.0/8

Errors:

docker-compose up
Starting dockertree_storage_1
Starting dockertree_agent_1
Attaching to dockertree_storage_1, dockertree_agent_1
storage_1  | standard_init_linux.go:175: exec user process caused "exec format error"
agent_1    | standard_init_linux.go:175: exec user process caused "exec format error"
dockertree_storage_1 exited with code 1
dockertree_agent_1 exited with code 1

Besides OS X this also happens on Linux Mint 17.3 while running a static compiled Go binary in a Docker scratch container:

How did you compile the binary? If you compiled the binary on OS X, it may still be an invalid binary to run on Linux. What happens if you add that binary to a non-scratch image (e.g. alpine or ubuntu), and run the binary from an interactive shell?

@thaJeztah @StefanScherer I would be glad to have those suggestions… This should be transparent for Mac users having that Docker can run anything anywhere 😃