Docker Image not Working

[mohammed90]

Okay, so this is a multifaceted issue, and not limited to just the Docker image. The Docker image is how I found it.

Simple go build doesn't work because of the presence of the webdav/ directory while the module name is also webdav. The go build command will complain with go build: build output "webdav" already exists and is a directory. The go build command can be fooled into proceeding with the build by issuing go build -o webdav main.go, at which it'll (hilariously) create the binary inside the webdav directory as such webdav/command-line-arguments. Yes, the binary name is command-line-arguments. This wasn't an issue before c5f3907 because back then the main package was within a directory named webdav, so there was no name conflict.

Now Docker... the Dockerfile. So the Dockerfile copies the webdav to /webdav, which we now know is a directory and not a binary.

webdav/Dockerfile

Line 9 in ab0334f

COPY webdav /webdav

Then it tries to execute it:

webdav/Dockerfile

Line 11 in ab0334f

ENTRYPOINT [ "/webdav" ]

which causes Docker to log standard_init_linux.go:211: exec user process caused "no such file or directory". That's because it's trying to execute a directory.

[hacdias]

Will release v3 now with this fix.

[facewy]

release v3: Docker Image still not Working
docker run -d --name webdav hacdias/webdav:v3.0.0
standard_init_linux.go:211: exec user process caused "no such file or directory"

[mohammed90]

The dependecies are not added in the docker image, that is why there is "no such file or directory" error.
Need to add "libpthread.so.0", "libc.so.6", "ld-linux-x86-64.so.2" to /lib64, and the file can run.
Suggest @hacdias add that.

Not exactly. The binary was being compiled with dynamic link to libc which calls those libs. We've already resolved that by building the binary statically by disabling cgo.