[GH-ISSUE #398] Write files as user, not root

kerem commented

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

Owner

Originally created by @arifer612 on GitHub (Oct 21, 2020).
Original GitHub issue: https://github.com/nektos/act/issues/398

Hi there, first of all, I'd really love to thank you for this wonderful project. It's been a wonderful aid for my personal projects.

I would like to suggest a feature to add to this project. When new files are created (e.g. documentations / MAKE files), the owner of the file is root and not user, even with the --bind flag turned on. I feel it would make more sense for the files to be owned by user and not root, especially since the container is supposed to be 'bound' to the working directory.

I have tried to change the ownership by explicitly including chown user, but being a containerised environment, user does not exist and returns the error message chown: invalid user: user

Originally created by @arifer612 on GitHub (Oct 21, 2020). Original GitHub issue: https://github.com/nektos/act/issues/398 Hi there, first of all, I'd really love to thank you for this wonderful project. It's been a wonderful aid for my personal projects. I would like to suggest a feature to add to this project. When new files are created (e.g. documentations / MAKE files), the owner of the file is `root` and not _user_, even with the `--bind` flag turned on. I feel it would make more sense for the files to be owned by _user_ and not `root`, especially since the container is supposed to be 'bound' to the working directory. I have tried to change the ownership by explicitly including `chown ` _user_, but being a containerised environment, _user_ does not exist and returns the error message `chown: invalid user:` _user_

kerem

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

closed this issue
added the
needs-work

stale-exempt
labels

kerem commented

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

Author

Owner

@torbjornvatn commented on GitHub (Nov 12, 2020):

@arifer612 Have you check how this works "live" on Github?
Are the user or root set as owner of files there?

@torbjornvatn commented on GitHub (Nov 12, 2020): @arifer612 Have you check how this works "live" on Github? Are the user or root set as owner of files there?

kerem commented

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

Author

Owner

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

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

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

kerem commented

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

Author

Owner

@catthehacker commented on GitHub (Jan 12, 2021):

act currently doesn't support non-root users.

@catthehacker commented on GitHub (Jan 12, 2021): `act` currently doesn't support non-root users.

kerem commented

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

Author

Owner

@github-actions[bot] commented on GitHub (Feb 19, 2021):

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

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

kerem commented

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

Author

Owner

@Totktonada commented on GitHub (Apr 19, 2021):

The act tool stitch two worlds: GitHub Actions runners in clouds that are far away from us and the make experience that is under our fingers.

My opinion is that here we should pay more attention to the second aspect rather than how GitHub Actions works per se.

I use --bind as workaround for #193 and here I would like to share another recipe from the packpack tool. It uses so called userwrapper.sh script as an entrypoint to create a user inside the container with uid and gid equal to ones of a user that that runs the tool. It works like a charm (seriously, I can just forget about all those su -c 'chown -R <...> .' after each build).

The only problem we (tarantool team) see with this approach is when the tool is run under a system user (it was a user for GitLab Runner) and a system user with the same ID exists in a particular image. It is quite rare situation, though, and there are possible ways to mitigate it. See details here. (To be honest, we worked it around by changing uid on our machines and didn't implement some general solution yet.)

@Totktonada commented on GitHub (Apr 19, 2021): The act tool stitch two worlds: GitHub Actions runners in clouds that are far away from us and the make experience that is under our fingers. My opinion is that here we should pay more attention to the second aspect rather than how GitHub Actions works per se. I use --bind as workaround for #193 and here I would like to share another recipe from the packpack tool. It uses so called [userwrapper.sh](https://github.com/packpack/packpack/blob/0154f5e5af03126744e3ff35648de7264a011fcd/packpack#L116-L145) script as an entrypoint to create a user inside the container with uid and gid equal to ones of a user that that runs the tool. It works like a charm (seriously, I can just forget about all those `su -c 'chown -R <...> .'` after each build). The only problem we (tarantool team) see with this approach is when the tool is run under a system user (it was a user for GitLab Runner) and a system user with the same ID exists in a particular image. It is quite rare situation, though, and there are possible ways to mitigate it. See details [here](https://github.com/packpack/packpack/issues/127). (To be honest, we worked it around by changing uid on our machines and didn't implement some general solution yet.)

kerem commented

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

Author

Owner

@aytey commented on GitHub (Oct 30, 2021):

act currently doesn't support non-root users.

Does this mean we should be running act under sudo?

@aytey commented on GitHub (Oct 30, 2021): > `act` currently doesn't support non-root users. > Does this mean we should be running `act` under `sudo`?

kerem commented

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

Author

Owner

@catthehacker commented on GitHub (Oct 30, 2021):

no, Docker image should use root account

@catthehacker commented on GitHub (Oct 30, 2021): no, Docker image should use root account

kerem commented

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

Author

Owner

@aytey commented on GitHub (Oct 30, 2021):

So if not using bind, and you want to create files inside of the repo you're checking out, what's the recommended workflow? My experience here is that whoever is the default user that is running the actions cannot write to cwd.

@aytey commented on GitHub (Oct 30, 2021): So if *not* using `bind`, and you want to create files *inside* of the repo you're checking out, what's the recommended workflow? My experience here is that whoever is the default user that is running the actions *cannot* write to cwd.

kerem commented

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

Author

Owner

@joeyparrish commented on GitHub (Dec 20, 2021):

I think this can be fixed by running chmod -R runner.runner /path/to/workingdir inside the container act, right after copying files to it. I'll try to put together a PR.

@joeyparrish commented on GitHub (Dec 20, 2021): I think this can be fixed by running `chmod -R runner.runner /path/to/workingdir` inside the container act, right after copying files to it. I'll try to put together a PR.

kerem commented

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

Author

Owner

@joeyparrish commented on GitHub (Dec 20, 2021):

My fix is working for me locally in my own workflows, and the change was pretty small. It recursively changes ownership of the copied files to runner. This change in behavior will also make act more consistent with GitHub Actions. There, checkouts are done as the runner user by default, leaving all files owned by that user.

@joeyparrish commented on GitHub (Dec 20, 2021): My fix is working for me locally in my own workflows, and the change was pretty small. It recursively changes ownership of the copied files to `runner`. This change in behavior will also make `act` more consistent with GitHub Actions. There, checkouts are done as the `runner` user by default, leaving all files owned by that user.

kerem commented

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

Author

Owner

@catthehacker commented on GitHub (Dec 20, 2021):

I think this can be fixed by running chmod -R runner.runner /path/to/workingdir inside the container act, right after copying files to it. I'll try to put together a PR.

No because not every image has runner user and not every image has runner user with same ID of host user running act

@catthehacker commented on GitHub (Dec 20, 2021): > I think this can be fixed by running `chmod -R runner.runner /path/to/workingdir` inside the container act, right after copying files to it. I'll try to put together a PR. No because not every image has `runner` user and not every image has `runner` user with same ID of host user running `act`

kerem commented

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

Author

Owner

@joeyparrish commented on GitHub (Dec 20, 2021):

No because not every image has runner user and not every image has runner user with same ID of host user running act

That would be correct for --bind. My change will fix the situation where you aren't using --bind. In that situation with the latest act, some files copied from the working directory are owned by root, which can break workflows that work perfectly well in GitHub's environment.

@joeyparrish commented on GitHub (Dec 20, 2021): > No because not every image has `runner` user and not every image has `runner` user with same ID of host user running `act` That would be correct for `--bind`. My change will fix the situation where you **aren't** using `--bind`. In that situation with the latest `act`, some files copied from the working directory are owned by `root`, which can break workflows that work perfectly well in GitHub's environment.

kerem commented

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

Author

Owner

@joeyparrish commented on GitHub (Dec 20, 2021):

In fact, I'd like to attempt a fix for --bind, as well. I think the user ID of runner in the container can be modified to match the local user, just before the rest of the container setup runs. But I'll save that for a follow-up PR once the easier fix (without --bind) is complete.

@joeyparrish commented on GitHub (Dec 20, 2021): In fact, I'd like to attempt a fix for `--bind`, as well. I think the user ID of `runner` in the container can be modified to match the local user, just before the rest of the container setup runs. But I'll save that for a follow-up PR once the easier fix (without `--bind`) is complete.

kerem commented

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

Author

Owner

@catthehacker commented on GitHub (Dec 20, 2021):

I haven't pushed PR yet but I added option to run as custom user some time ago
github.com/catthehacker/act-fork@a4dd723dd1

@catthehacker commented on GitHub (Dec 20, 2021): I haven't pushed PR yet but I added option to run as custom user some time ago https://github.com/catthehacker/act-fork/commit/a4dd723dd182201a99db24a86a590d28749661ce

kerem commented

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

Author

Owner

@joeyparrish commented on GitHub (Dec 20, 2021):

@catthehacker, I cherry-picked the change you mentioned, and tried it out. Mine is in slight conflict in that "runner.runner" in my change should be replaced with rc.Config.ContainerUser when that exists.

Your also has a small bug as far as I can tell. The directory /home/runner/work/ also needs to be owned by the container user. Otherwise some of the actions in my workflow fail with EACCES.

Would it be helpful if I integrated your work into mine and tested everything with --bind?

@joeyparrish commented on GitHub (Dec 20, 2021): @catthehacker, I cherry-picked the change you mentioned, and tried it out. Mine is in slight conflict in that `"runner.runner"` in my change should be replaced with `rc.Config.ContainerUser` when that exists. Your also has a small bug as far as I can tell. The directory `/home/runner/work/` also needs to be owned by the container user. Otherwise some of the actions in my workflow fail with `EACCES`. Would it be helpful if I integrated your work into mine and tested everything with `--bind`?

kerem commented

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

Author

Owner

@catthehacker commented on GitHub (Dec 20, 2021):

The directory /home/runner/work/ also needs to be owned by the container user. Otherwise some of the actions in my workflow fail with EACCES.

Why? We don't use that path at all and actions should not hardcode paths

@catthehacker commented on GitHub (Dec 20, 2021): > The directory `/home/runner/work/` also needs to be owned by the container user. Otherwise some of the actions in my workflow fail with `EACCES`. Why? We don't use that path at all and actions should not hardcode paths

kerem commented

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

Author

Owner

@catthehacker commented on GitHub (Dec 20, 2021):

Would it be helpful if I integrated your work into mine and tested everything with --bind?

I haven't tested it but feel free to use it however you like, as long as the commit has preserved authorship.

@catthehacker commented on GitHub (Dec 20, 2021): > Would it be helpful if I integrated your work into mine and tested everything with `--bind`? I haven't tested it but feel free to use it however you like, as long as the commit has preserved authorship.

kerem commented

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

Author

Owner

@joeyparrish commented on GitHub (Dec 20, 2021):

The directory /home/runner/work/ also needs to be owned by the container user. Otherwise some of the actions in my workflow fail with EACCES.

Why? We don't use that path at all and actions should not hardcode paths

I don't know. I'm not that familiar with how actions work internally. I can show you the logs, though. The docs workflow in https://github.com/Valheim-Modding/Jotunn is what I'm playing with at the moment. It's the nuget/setup-nuget@v1 action that fails, with:

[Create Documentation Pages/Builds documentation and publishes to GitHub Pages] ⭐  Run Install NuGet
INFO[0001]   ☁  git clone 'https://github.com/nuget/setup-nuget' # ref=v1 
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   🐳  docker cp src=/home/joey/.cache/act/nuget-setup-nuget@v1/ dst=/var/run/act/actions/nuget-setup-nuget@v1/
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   🐳  docker exec cmd=[mkdir -m 0777 -p /var/run/act/actions/nuget-setup-nuget@v1/] user=1000 workdir=
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   🐳  docker exec cmd=[node /var/run/act/actions/nuget-setup-nuget@v1/dist/index.js] user= workdir=
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   💬  ::debug::Found NuGet version: 6.0.0
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   💬  ::debug::isExplicit: 6.0.0
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   💬  ::debug::explicit? true
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   💬  ::debug::checking cache: /opt/hostedtoolcache/nuget.exe/6.0.0/x64
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   💬  ::debug::not found
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   💬  ::debug::Downloading https://dist.nuget.org/win-x86-commandline/v6.0.0/nuget.exe
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   💬  ::debug::Destination /home/runner/work/_temp/d837bd0e-bc7b-421c-b96d-e19eca299b5f
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   💬  ::debug::download failed
| EACCES: permission denied, open '/home/runner/work/_temp/d837bd0e-bc7b-421c-b96d-e19eca299b5f'
| Waiting 18 seconds before trying again
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   💬  ::debug::download failed
| EACCES: permission denied, open '/home/runner/work/_temp/d837bd0e-bc7b-421c-b96d-e19eca299b5f'
| Waiting 15 seconds before trying again
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   💬  ::debug::download failed
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   ❗  ::error::EACCES: permission denied, open '/home/runner/work/_temp/d837bd0e-bc7b-421c-b96d-e19eca299b5f'
[Create Documentation Pages/Builds documentation and publishes to GitHub Pages]   ❌  Failure - Install NuGet

I thought this was due to ownership, but I might have been wrong. It seems to only happen with --container-user 1000 --bind. (Where 1000 is my local UID.)

I'll investigate a bit more this time before I declare that I know what the problem is. :-)

@joeyparrish commented on GitHub (Dec 20, 2021): > > The directory /home/runner/work/ also needs to be owned by the container user. Otherwise some of the actions in my workflow fail with EACCES. > Why? We don't use that path at all and actions should not hardcode paths I don't know. I'm not that familiar with how actions work internally. I can show you the logs, though. The docs workflow in https://github.com/Valheim-Modding/Jotunn is what I'm playing with at the moment. It's the `nuget/setup-nuget@v1` action that fails, with: ``` [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] ⭐ Run Install NuGet INFO[0001] ☁ git clone 'https://github.com/nuget/setup-nuget' # ref=v1 [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 🐳 docker cp src=/home/joey/.cache/act/nuget-setup-nuget@v1/ dst=/var/run/act/actions/nuget-setup-nuget@v1/ [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 🐳 docker exec cmd=[mkdir -m 0777 -p /var/run/act/actions/nuget-setup-nuget@v1/] user=1000 workdir= [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 🐳 docker exec cmd=[node /var/run/act/actions/nuget-setup-nuget@v1/dist/index.js] user= workdir= [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 💬 ::debug::Found NuGet version: 6.0.0 [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 💬 ::debug::isExplicit: 6.0.0 [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 💬 ::debug::explicit? true [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 💬 ::debug::checking cache: /opt/hostedtoolcache/nuget.exe/6.0.0/x64 [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 💬 ::debug::not found [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 💬 ::debug::Downloading https://dist.nuget.org/win-x86-commandline/v6.0.0/nuget.exe [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 💬 ::debug::Destination /home/runner/work/_temp/d837bd0e-bc7b-421c-b96d-e19eca299b5f [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 💬 ::debug::download failed | EACCES: permission denied, open '/home/runner/work/_temp/d837bd0e-bc7b-421c-b96d-e19eca299b5f' | Waiting 18 seconds before trying again [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 💬 ::debug::download failed | EACCES: permission denied, open '/home/runner/work/_temp/d837bd0e-bc7b-421c-b96d-e19eca299b5f' | Waiting 15 seconds before trying again [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] 💬 ::debug::download failed [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] ❗ ::error::EACCES: permission denied, open '/home/runner/work/_temp/d837bd0e-bc7b-421c-b96d-e19eca299b5f' [Create Documentation Pages/Builds documentation and publishes to GitHub Pages] ❌ Failure - Install NuGet ``` I thought this was due to ownership, but I might have been wrong. It seems to only happen with `--container-user 1000 --bind`. (Where 1000 is my local UID.) I'll investigate a bit more this time before I declare that I know what the problem is. :-)

kerem commented

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

Author

Owner

@catthehacker commented on GitHub (Dec 20, 2021):

It would be good to know what Docker image are you using
For me it works ok (not counting missing mono)

@catthehacker commented on GitHub (Dec 20, 2021): It would be good to know what Docker image are you using For me it works ok (not counting missing `mono`) ![image](https://user-images.githubusercontent.com/31106839/146840854-39f71d6d-b467-4a21-862f-ff0b29354f10.png)

kerem commented

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

Author

Owner

@joeyparrish commented on GitHub (Dec 20, 2021):

My ~/.actrc is:

-P ubuntu-latest=ghcr.io/catthehacker/ubuntu:full-latest

And my instinct was right: it was ownership after all. But I had a bug in my additional chown command for /home/runner. I accidentally made it conditional on copyWorkspace, like the first chown I added. With that bug fixed, I now have something working with --bind and --container-user, as well as with neither.

Here are the changes I'm testing:

github.com/joeyparrish/act@14ef5ab452
github.com/catthehacker/act-fork@a4dd723dd1
Fixing merge conflicts
Changed default --container-user to "runner", since a blank string doesn't work so well in constructed chown commands
Changed chown in my previous PR from "runner.runner" to rc.Config.ContainerUser
Added another, unconditional chown to rc.Config.ContainerUser on /home/runner

I've pushed all that to my fork, and you can decide how you'd like to proceed. If we can agree on those changes, though, I think all my use-cases would be taken care of. Everything is in PR #934 now, including your commit (with merge conflicts fixed, commit message and authorship unaltered).

Thanks for your time!

@joeyparrish commented on GitHub (Dec 20, 2021): My `~/.actrc` is: ``` -P ubuntu-latest=ghcr.io/catthehacker/ubuntu:full-latest ``` And my instinct was right: it was ownership after all. But I had a bug in my additional `chown` command for `/home/runner`. I accidentally made it conditional on `copyWorkspace`, like the first `chown` I added. With that bug fixed, I now have something working with `--bind` and `--container-user`, as well as with neither. Here are the changes I'm testing: 1. https://github.com/joeyparrish/act/commit/14ef5ab452dfd97c3ce664022d8aa28a7d5d4ad4 2. https://github.com/catthehacker/act-fork/commit/a4dd723dd182201a99db24a86a590d28749661ce 3. Fixing merge conflicts 4. Changed default `--container-user` to `"runner"`, since a blank string doesn't work so well in constructed `chown` commands 5. Changed chown in my previous PR from `"runner.runner"` to `rc.Config.ContainerUser` 6. Added another, unconditional chown to `rc.Config.ContainerUser` on `/home/runner` I've pushed all that to my fork, and you can decide how you'd like to proceed. If we can agree on those changes, though, I think all my use-cases would be taken care of. Everything is in PR #934 now, including your commit (with merge conflicts fixed, commit message and authorship unaltered). Thanks for your time!

kerem commented

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

Author

Owner

@stovmascript commented on GitHub (May 25, 2022):

How is this looking? I would really welcome the --container-user option. Or at least aligning the user across the existing images.

Act will reach my workflow jobs on the medium image, but not on the full image, as it fails setting up the repo because of owner issues. I need to use the full image because I'm using the GitHub CLI (gh) in my workflow, which is not available on the medium image.

@stovmascript commented on GitHub (May 25, 2022): How is this looking? I would really welcome the `--container-user` option. Or at least aligning the user across the existing images. Act will reach my workflow jobs on the medium image, but not on the full image, as it fails setting up the repo because of owner issues. I need to use the full image because I'm using the GitHub CLI (`gh`) in my workflow, which is not available on the medium image.

kerem commented

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

Author

Owner

@LuisAlejandro commented on GitHub (Sep 1, 2022):

So, functionality was added in #1202, but how do we use it? I don't seem to find instructions anywhere

@LuisAlejandro commented on GitHub (Sep 1, 2022): So, functionality was added in #1202, but how do we use it? I don't seem to find instructions anywhere

kerem commented

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

Author

Owner

@ChristopherHX commented on GitHub (Sep 2, 2022):

So, functionality was added in https://github.com/nektos/act/pull/1202, but how do we use it? I don't seem to find instructions anywhere

You need a non root user docker image and act will extract the uid and gid to create files in the container. Therefore the only thing needed is a -P <runs-on-label>=<custom image> flag pointing to a custom image with a non root user.

If you use non root user container e.g an image created by a dockerfile with USER now files are created with the docker image user instead of root

FROM ubuntu:latest
RUN useradd -u 5000 app
USER app

If you use --bind, an unsafe flag:

Make shure to use a custom image with an user matching your operating system.
Or https://docs.docker.com/engine/security/userns-remap/ then even root container write files as user instead of root in bind mounts, but you loose access to all existing container / images and have to pull them again.

@ChristopherHX commented on GitHub (Sep 2, 2022): > So, functionality was added in https://github.com/nektos/act/pull/1202, but how do we use it? I don't seem to find instructions anywhere You need a non root user docker image and act will extract the uid and gid to create files in the container. Therefore the only thing needed is a `-P <runs-on-label>=<custom image>` flag pointing to a custom image with a non root user. If you use non root user container e.g an image created by a dockerfile with `USER` now files are created with the docker image user instead of root ``` FROM ubuntu:latest RUN useradd -u 5000 app USER app ``` If you use `--bind`, an unsafe flag: - Make shure to use a custom image with an user matching your operating system. - Or https://docs.docker.com/engine/security/userns-remap/ then even root container write files as user instead of root in bind mounts, but you loose access to all existing container / images and have to pull them again.

kerem commented

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

Author

Owner

@LuisAlejandro commented on GitHub (Sep 2, 2022):

Thank you very much for your explanation!

@LuisAlejandro commented on GitHub (Sep 2, 2022): Thank you very much for your explanation!

kerem commented

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

Author

Owner

@airtonix commented on GitHub (Nov 20, 2023):

Is this ticket related to the fact that whenever i run act, all the files get chown'd to root?

after each run, i have to run

sudo chown $(whoami):$(whoami) ./ -R

.actrc is

--bind
--artifact-server-path=./artifacts
-P ubuntu-22.04=catthehacker/ubuntu:full-20.04

@airtonix commented on GitHub (Nov 20, 2023): Is this ticket related to the fact that whenever i run act, all the files get chown'd to root? after each run, i have to run ```shell sudo chown $(whoami):$(whoami) ./ -R ``` `.actrc` is ``` --bind --artifact-server-path=./artifacts -P ubuntu-22.04=catthehacker/ubuntu:full-20.04 ```

Rows
Columns

[GH-ISSUE #398] Write files as user, not root #281