Error: EACCES: permission denied, open '/__w/_temp/_runner_file_commands/save_state_2b00fafd-10c3-4255-90f8-57582bc4e694'

[oilrich25]

  ubuntu-latest:
    runs-on: ubuntu-latest
    container: christopherhx/runner-images:ubuntu20-runner-medium-hostedtoolcache-20231126.1.0
    steps:
      - uses: actions/checkout@v4
      - run: uname -a

I seem to have some problems using ChristopherHX/runner-image-blobs. It will prompt the following error:

##[group]Run actions/checkout@v4
with:
  repository: oilrich25/simple-go-action
  token: ***
  ssh-strict: true
  persist-credentials: true
  clean: true
  sparse-checkout-cone-mode: true
  fetch-depth: 1
  fetch-tags: false
  show-progress: true
  lfs: false
  submodules: false
  set-safe-directory: true
env:
  CACHE_EPOCH: 1
  CCACHE_MAXFILES: 0
  CCACHE_MAXSIZE: 200M
  GOCACHE: /root/gocache
  SCCACHE_CACHE_SIZE: 200M
  XDC_CACHE_HOME: /root/gocache
##[endgroup]
##[command]/snap/bin/docker exec  458ab520d039e302c1e783b7adc96bc7bab166394a7a9c1a89370467ed40316b sh -c "cat /etc/*release | grep ^ID"
node:internal/fs/sync:78
  return binding.openSync(
                 ^
Error: EACCES: permission denied, open '/__w/_temp/_runner_file_commands/save_state_2b00fafd-10c3-4255-90f8-57582bc4e694'
    at Object.open (node:internal/fs/sync:78:18)
    at Object.openSync (node:fs:565:17)
    at Object.writeFileSync (node:fs:2288:35)
    at Object.appendFileSync (node:fs:2350:6)
    at Object.issueFileCommand (/__w/_actions/actions/checkout/v4/dist/index.js:2967:8)
    at Object.saveState (/__w/_actions/actions/checkout/v4/dist/index.js:2884:31)
    at 8647 (/__w/_actions/actions/checkout/v4/dist/index.js:2343:10)
    at __nccwpck_require__ (/__w/_actions/actions/checkout/v4/dist/index.js:18273:43)
    at 2565 (/__w/_actions/actions/checkout/v4/dist/index.js:146:34)
    at __nccwpck_require__ (/__w/_actions/actions/checkout/v4/dist/index.js:18273:43) {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: '/__w/_temp/_runner_file_commands/save_state_2b00fafd-10c3-4255-90f8-57582bc4e694'
}
Node.js v20.8.1

[ChristopherHX]

the problem is that I added a non root user as the default one into my image generation (Rust couldn't find it's files)

If you force the user back to root aka uid 0 then it should work in most cases.

  ubuntu-latest:
    runs-on: ubuntu-latest
    container:
      image: christopherhx/runner-images:ubuntu20-runner-medium-hostedtoolcache-20231126.1.0 # No ghcr.io/ prefix?
      options: --user 0 # run a non root container as root to be compatible
    steps:
      - uses: actions/checkout@v4
      - run: uname -a

Don't you need a ghcr.io/ prefix? Or is your default registry a mirror and contains a copy, that would really make sense to improve speed / reliability

[oilrich25]

the problem is that I added a non root user as the default one into my image generation (Rust couldn't find it's files)

If you force the user back to root aka uid 0 then it should work in most cases.

  ubuntu-latest:
    runs-on: ubuntu-latest
    container:
      image: christopherhx/runner-images:ubuntu20-runner-medium-hostedtoolcache-20231126.1.0 # No ghcr.io/ prefix?
      options: --user 0 # run a non root container as root to be compatible
    steps:
      - uses: actions/checkout@v4
      - run: uname -a

Don't you need a ghcr.io/ prefix? Or is your default registry a mirror and contains a copy, that would really make sense to improve speed / reliability

Yes, I put christopherhx/runner-images:ubuntu20-runner-medium-hostedtoolcache-20231126.1.0 in my registry a mirror

[oilrich25]

Set it up as you did and it's working fine now. I very much agree that github action uses container to set up different images, which can ensure the isolation of the build environment. Currently, Windows containers and macos containers are still lacking. I have a bold idea, simply transplant the call tart to runner.server, so that it can be taken into consideration whether it is Linux, Windows or macos.

[ChristopherHX]

simply transplant the call tart to runner.server, so that it can be taken into consideration whether it is Linux, Windows or macos.

I'm not shure what your idea is here.

The server part of my runner.server Project basically replaces Gitea Actions and works with Gitea 1.17+ (before they added Gitea Actions), but is still incomplete in aspect of security and secret management.

The client part of my runner.server Project is interesting due to the integrated windows container management.

It's indeed possible to create a script

• which starts a tart vm (without stdin access)
• place the actions/runner into the vm via mount / copy etc.
• if you cannot reach the prefilled ip
  • read the job message from stdin (see python / pwsh script)
  • replace the ip in the job request message with the ip of your tart host system
  • otherwise we would need to tell gitea-actions-runner to provide the different api ip in all urls
• run Runner.Worker process inside tart VM
• forward the message to Runner.Worker inside the tart VM
• job status, outputs, logs are sent over http/websockets

How exactly that script need to look like needs trial and error on a m-series mac.