When building the MediaMTX Docker image on Windows using Docker Desktop with WSL2, the image builds successfully but fails at runtime with an error indicating that the entrypoint script cannot be found.
This happens even when:
- the repository is cloned into the WSL Linux filesystem
- the build is executed from inside WSL (Arch Linux)
The same Dockerfile behaves correctly when rebuilt under different conditions where Windows filesystem handling is not involved.
Affected Dockerfile
hack/rtsp-stream/Dockerfile
Link:
https://github.com/PlainsightAI/openfilter-pipelines-controller/blob/main/hack/rtsp-stream/Dockerfile
Environment
- Host OS: Windows 11
- Linux environment: Arch Linux (WSL2)
- Docker Desktop: WSL2 backend enabled
- Kubernetes: Docker Desktop Kubernetes (kubeadm)
- Kubernetes version: v1.34.1
Observed Behavior
docker build completes successfully.- Container startup fails.
- Runtime error indicates the entrypoint script cannot be found.
Example symptom:
exec /entrypoint.sh: no such file or directory
Expected Behavior
The MediaMTX container should start normally after a successful build, regardless of the host operating system.
Actual Behavior
- Build succeeds.
- Container fails immediately at startup due to missing entrypoint script.
Notes and Possible Causes
This appears to be related to how Docker Desktop on Windows handles files during image build.
Possible contributing factors include:
- CRLF vs LF line endings applied during file copy
- Executable bit not preserved on shell scripts
- Shebang resolution issues (
#!/bin/sh)
- Windows filesystem metadata translation, even when building from WSL
These issues typically surface as:
no such file or directory
even when the file exists inside the image.
Workaround
Rebuilding the image after ensuring:
- shell scripts use LF line endings
- scripts are explicitly marked executable
- or rebuilding the image in an environment not affected by Windows filesystem translation
allows the MediaMTX container to start normally.
This workaround allowed me to continue testing the OpenFilter streaming pipeline without blockers.
Impact
- Does not block OpenFilter usage once identified.
- May affect Windows developers using Docker Desktop + WSL2.
- Failure occurs only at runtime, which can be confusing since the image builds successfully.
Additional Context
This issue was encountered while running the OpenFilter demo in streaming mode using MediaMTX and does not affect the OpenFilter controller itself.
When building the MediaMTX Docker image on Windows using Docker Desktop with WSL2, the image builds successfully but fails at runtime with an error indicating that the entrypoint script cannot be found.
This happens even when:
The same Dockerfile behaves correctly when rebuilt under different conditions where Windows filesystem handling is not involved.
Affected Dockerfile
Link:
https://github.com/PlainsightAI/openfilter-pipelines-controller/blob/main/hack/rtsp-stream/Dockerfile
Environment
Observed Behavior
docker buildcompletes successfully.Example symptom:
Expected Behavior
The MediaMTX container should start normally after a successful build, regardless of the host operating system.
Actual Behavior
Notes and Possible Causes
This appears to be related to how Docker Desktop on Windows handles files during image build.
Possible contributing factors include:
#!/bin/sh)These issues typically surface as:
even when the file exists inside the image.
Workaround
Rebuilding the image after ensuring:
allows the MediaMTX container to start normally.
This workaround allowed me to continue testing the OpenFilter streaming pipeline without blockers.
Impact
Additional Context
This issue was encountered while running the OpenFilter demo in streaming mode using MediaMTX and does not affect the OpenFilter controller itself.