Can't mount files when using dind feature - bug or limitation?

[schrom]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Actions Runner

Discussion Details

Hi,

not sure if this is a bug, a limitation or I'm just misunderstanding the whole concept.

I'm using the selfhosted runner installed via helm version 0.13.1 and containerMode "dind", as our build pipeline wants to start containers to run tests and verify the created container image. Besides that setting and the obvious secrets nothing really special has been configured in helm.

Within this pipeline we create configfiles and secrets the shall be mounted into the container image, to run the tests with a predefined or mocked configuration. This does not work.

Here is a minimal example which replicates our test pipeline. This runs fine locally on my laptop:

$ echo hello > /tmp/secret.txt
$ docker run -it -v /tmp/secret.txt:/mnt/secret.txt alpine:3
/ # cat /mnt/secret.txt
hello
/ #

When I do the same within the Github pipeline, this is happening, the file is not found and mounted as an empty directory instead:

$ echo hello > /tmp/secret.txt
$ docker run -it -v /tmp/secret.txt:/mnt/secret.txt alpine:3
 # ls -al /mnt/
total 8
drwxr-xr-x    1 root     root          4096 Mar 24 17:16 .
drwxr-xr-x    1 root     root          4096 Mar 24 17:16 ..
drwxr-xr-x    2 root     root            40 Mar 24 17:15 secret.txt
/ # ls -al /mnt/secret.txt/
total 4
drwxr-xr-x    2 root     root            40 Mar 24 17:15 .
drwxr-xr-x    1 root     root          4096 Mar 24 17:16 ..

Same attempt with docker compose:

services:
  test:
    image: alpine:3
    secrets:
      - credentials
    command: [ "cat", "/run/secrets/credentials" ]

secrets:
  credentials:
    file: "/tmp/secret.txt"

leads to

Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /tmp/secret.txt

I found out that actually the files are mounted from the dind container itself. So when I do this in the dind sidecar:

/ # echo "hello, i am the dind container" > /tmp/secret.txt

I'm getting this result in my runner container:

$ echo hello > /tmp/secret.txt
$ docker run -it -v /tmp/secret.txt:/mnt/secret.txt alpine:3
/ # cat /mnt/secret.txt
hello, i am the dind container

Not being able to provide containers in my pipeline with predefined files or folders makes this whole dind feature useless. As mentioned above, I'm unsure whether this is a bug or a known limitation or there is some "magic" setting I haven't figured out yet. Any help is appreciated.

[Crackle2K]

You can try modifying your Helm configuration to share a volume between the runner and the DinD container, as this seems to be the common solution found between most people with this problem.

[andreas-agouridis]

Hi @schrom,

What you’re seeing is actually expected behavior with the dind (Docker-in-Docker) setup rather than a bug. Here’s why:

How dind works
When using containerMode: dind in a self-hosted GitHub Actions runner, your job container and the dind sidecar container are separate containers.
Any bind mounts you specify in your workflow are relative to the filesystem of the dind container, not the job container. That’s why your /tmp/secret.txt in the job container isn’t visible inside the dind container—the mount path effectively doesn’t exist there.
Behavior you observed
Creating the file inside the job container (echo hello > /tmp/secret.txt) doesn’t propagate to dind, so when you try to bind mount it, Docker sees a non-existent path and ends up mounting an empty directory.
Writing the file inside the dind container itself works because that’s the filesystem Docker sees for mounts.
Implications
This is a limitation of the dind feature, not a bug. It’s how Docker-in-Docker isolation works—job container files don’t automatically appear inside dind.
Any secrets, config files, or artifacts you want to mount must exist inside the dind container, or you need to use a shared volume that both containers can access.
Workarounds
Use a shared volume between the job container and dind sidecar (e.g., via volumes: in your Helm chart) to persist files.

Copy files into the dind container at runtime before running your test containers:

docker cp /tmp/secret.txt dind:/tmp/secret.txt
For secrets, consider using GitHub Actions secrets and writing them into a file inside the dind container at job start.

In short: the dind feature requires mounts and files to be visible inside the dind container itself. Mounting host files from the job container will not work unless you explicitly share them via volumes.

This is a known limitation of Docker-in-Docker setups rather than a bug in GitHub Actions.

[schrom]

After more investigations on my side (with the help of @andreas-agouridis comment), I found out this is even easier than thought. I'll leave my solution here for future people.

Actually, there is already a shared volume between the runner and the dind container, managed by the Helm chart. It's mounted as "/home/runner/_work". Anything inside that folder can be volume mounted in containers. Our mistake in the pipeline was that we "hard-coded" our generated files into /tmp/, which is outside the shared volume. By simply using $RUNNER_TEMP instead of /tmp (as recommended by the documentation), everything worked, as $RUNNER_TEMP is pointing to /home/runner/_work/_temp/ which is inside the shared volume.

Long story short: RTFM and do as told.