When using a self-hosted github runner, and you use an instance which does not clean itself completely between runs, you can get permission errors on subsequent runs when running a checkout and a clean action:
Deleting the contents of '/runner/_work/abc'
Error: File was unable to be removed Error: EACCES: permission denied, rmdir '/runner/_work/abc/.tenv/Terraform'
This is due to an underlying permission issue from the old run:
/runner/_work/abc/.tenv:
total 4
drwxr-xr-x. 3 root root 23 Mar 3 01:29 .
drwxr-xr-x. 19 runner runner 4096 Mar 3 01:37 ..
drwxr-xr-x. 3 root root 20 Mar 3 01:29 Terraform
/runner/_work/abc/.tenv/Terraform:
total 0
drwxr-xr-x. 3 root root 20 Mar 3 01:29 .
drwxr-xr-x. 3 root root 23 Mar 3 01:29 ..
drwxr-xr-x. 2 root root 23 Mar 3 01:29 1.14.5
/runner/_work/abc/.tenv/Terraform/1.14.5:
total 98200
drwxr-xr-x. 2 root root 23 Mar 3 01:29 .
drwxr-xr-x. 3 root root 20 Mar 3 01:29 ..
-rwxr-xr-x. 1 root root 100552888 Mar 3 01:29 terraform
These file are owned by root so they can't be deleted by the github checkout action running with a regular user permissions.
I believe, although I'm not sure, that this is because the action is running with a docker container as root. So, when the install command runs, it's done as the root user and the permissions are set this way, despite it being in the runner's home directory.
The solution may be to pass a user ID to the docker container to run under, or perhaps an optional chown command.
When using a self-hosted github runner, and you use an instance which does not clean itself completely between runs, you can get permission errors on subsequent runs when running a checkout and a clean action:
This is due to an underlying permission issue from the old run:
These file are owned by
rootso they can't be deleted by the github checkout action running with a regular user permissions.I believe, although I'm not sure, that this is because the action is running with a docker container as root. So, when the install command runs, it's done as the root user and the permissions are set this way, despite it being in the runner's home directory.
The solution may be to pass a user ID to the docker container to run under, or perhaps an optional
chowncommand.