starred/act

Fork 0

mirror of https://github.com/nektos/act.git synced 2026-04-26 09:25:54 +03:00

[GH-ISSUE #410] Mounting volumes into docker not working #286

New issue

Closed

opened 2026-03-01 21:42:05 +03:00 by kerem · 2 comments

kerem commented

2026-03-01 21:42:05 +03:00

Owner

Originally created by @agutenkunst on GitHub (Nov 7, 2020).
Original GitHub issue: https://github.com/nektos/act/issues/410

If inside the job a volume is mounted into a docker container the mounted folder will be empty in this container.
I create a minimal example

name: CI

on: [push, pull_request]

jobs:
  my_job:
    runs-on: ubuntu-18.04
    steps:
      - run: "mkdir /tmp/folder && touch /tmp/folder/file && docker run -t -v /tmp/folder:/folder --entrypoint '' ubuntu:18.04 /bin/ls /folder"

In gh actions this works fine: See https://github.com/agutenkunst/nectos-act-docker-volume-mount-issue/runs/1368072778#step:2:20 ("file" is printed by /bin/ls)

Running locally

act -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04

does not give any output, indicating a failed mount.

[CI/my_job] 🚀  Start image=nektos/act-environments-ubuntu:18.04
[CI/my_job]   🐳  docker run image=nektos/act-environments-ubuntu:18.04 entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[]
[CI/my_job] ⭐  Run mkdir /tmp/folder && touch /tmp/folder/file && docker run -t -v /tmp/folder:/folder --entrypoint '' ubuntu:18.04 /bin/ls /folder
[CI/my_job]   ✅  Success - mkdir /tmp/folder && touch /tmp/folder/file && docker run -t -v /tmp/folder:/folder --entrypoint '' ubuntu:18.04 /bin/ls /folder

This is also what I observed in a more complex real world use case. I am not sure if the image is actually Docker-in-Docker ready. Creating docker containers seems to work fine. Just not mounting something into them.

I check also on github and it seems that the runner user itself is "docker". Sounds like something according to https://docs.docker.com/engine/install/linux-postinstall/ is missing, but I am not sure.

Originally created by @agutenkunst on GitHub (Nov 7, 2020). Original GitHub issue: https://github.com/nektos/act/issues/410 If inside the job a volume is mounted into a docker container the mounted folder will be empty in this container. I create a minimal example ``` name: CI on: [push, pull_request] jobs: my_job: runs-on: ubuntu-18.04 steps: - run: "mkdir /tmp/folder && touch /tmp/folder/file && docker run -t -v /tmp/folder:/folder --entrypoint '' ubuntu:18.04 /bin/ls /folder" ``` In gh actions this works fine: See https://github.com/agutenkunst/nectos-act-docker-volume-mount-issue/runs/1368072778#step:2:20 ("file" is printed by /bin/ls) Running locally ``` act -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04 ``` does not give any output, indicating a failed mount. ``` [CI/my_job] 🚀 Start image=nektos/act-environments-ubuntu:18.04 [CI/my_job] 🐳 docker run image=nektos/act-environments-ubuntu:18.04 entrypoint=["/usr/bin/tail" "-f" "/dev/null"] cmd=[] [CI/my_job] ⭐ Run mkdir /tmp/folder && touch /tmp/folder/file && docker run -t -v /tmp/folder:/folder --entrypoint '' ubuntu:18.04 /bin/ls /folder [CI/my_job] ✅ Success - mkdir /tmp/folder && touch /tmp/folder/file && docker run -t -v /tmp/folder:/folder --entrypoint '' ubuntu:18.04 /bin/ls /folder ``` This is also what I observed in a more complex real world use case. I am not sure if the image is actually Docker-in-Docker ready. Creating docker containers seems to work fine. Just not mounting something into them. I check also on github and it seems that the runner user itself is "docker". Sounds like something according to https://docs.docker.com/engine/install/linux-postinstall/ is missing, but I am not sure.

kerem

2026-03-01 21:42:05 +03:00

closed this issue
added the
stale
label

kerem commented

2026-03-01 21:42:05 +03:00

Author

Owner

@samfoley88 commented on GitHub (Nov 23, 2020):

I've just ran into this problem as well although slightly differently I think my workaround will work for anyone encountering it in future.

Cause
The cause is the fact Docker volume and bind commands (even when running inside an existing container) bind to the HOST file system so will ignore any pre-existing binds (like the bind of /github/workspace).
My best guess is that Github is processing the variables in the command with an awareness that the command is going to docker and so pre-processes the variables and passes the path from the host not the docker container you are already running in.

Workaround
My workaround for this is to make the paths match when running locally. So when passing in the volume to docker it matches both the variable/path in the host filesystem and the container file system.

Since the image mounts /github/workspace for the working directory inside the container if you run with your repository working directory as the folder on the host /github/workspace AND use --bind (so act binds straight to it and doesn't use a copy) then you can use ${{ github.workspace }} in Docker and get the expected outcome.

This command works for running act (note I'm using the 16GB image that matches Github exactly, you may not want to do this!)

act -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 --bind --directory /github/workspace

You can also run it without the --directory flag (but with --bind) if you are in /github/workspace

I use this one liner to make it easier, when run from the root of the repo it deletes the existing workspace (to clear out any changes/build artefacts etc) and then copies over the current directory before running act.

sudo rm -r /github/workspace/ && cp -r ./ /github/workspace && act -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 --bind --directory /github/workspace

Known Limitations
One of the biggest limitations I have found is that your repo is in /github/workspace and you can't do anything about this so if you need a working directory you need to add the directory in question inside that working folder with the repo. If you need to use additional repo's as part of your workflow it seems to work so long as the subfolder you use is in your .gitignore so it doesn't interact with the root repo.

Suggested long term fix
I would think long term Docker commands need to be identified as a special case and have the variable interpreted before it is passed to the CLI.

@samfoley88 commented on GitHub (Nov 23, 2020): I've just ran into this problem as well although slightly differently I think my workaround will work for anyone encountering it in future. **Cause** The cause is the fact Docker volume and bind commands (even when running inside an existing container) bind to the HOST file system so will ignore any pre-existing binds (like the bind of /github/workspace). My best guess is that Github is processing the variables in the command with an awareness that the command is going to docker and so pre-processes the variables and passes the path from the host not the docker container you are already running in. **Workaround** My workaround for this is to make the paths match when running locally. So when passing in the volume to docker it matches both the variable/path in the host filesystem and the container file system. Since the image mounts ```/github/workspace``` for the working directory inside the container if you run with your repository working directory as the folder on the host ```/github/workspace``` AND use ```--bind``` _(so act binds straight to it and doesn't use a copy)_ then you can use ```${{ github.workspace }}``` in Docker and get the expected outcome. This command works for running act _(note I'm using the 16GB image that matches Github exactly, you may not want to do this!_) ```bash act -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 --bind --directory /github/workspace ``` You can also run it without the --directory flag (but with --bind) if you are in /github/workspace I use this one liner to make it easier, when run from the root of the repo it deletes the existing workspace (to clear out any changes/build artefacts etc) and then copies over the current directory before running act. ```bash sudo rm -r /github/workspace/ && cp -r ./ /github/workspace && act -P ubuntu-latest=nektos/act-environments-ubuntu:18.04 --bind --directory /github/workspace ``` _**Known Limitations**_ One of the biggest limitations I have found is that your repo is in /github/workspace and you can't do anything about this so if you need a working directory you need to add the directory in question inside that working folder with the repo. If you need to use additional repo's as part of your workflow it seems to work so long as the subfolder you use is in your .gitignore so it doesn't interact with the root repo. **Suggested long term fix** I would think long term Docker commands need to be identified as a special case and have the variable interpreted before it is passed to the CLI.

kerem commented

2026-03-01 21:42:06 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jan 16, 2021):

Issue is stale and will be closed in 14 days unless there is new activity

@github-actions[bot] commented on GitHub (Jan 16, 2021): Issue is stale and will be closed in 14 days unless there is new activity

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/act#286

No description provided.

Rows
Columns