Self-hosted runner update permission failure

A self-hosted runner tried to update itself or adjust worker process settings, but the environment denied access to the runner filesystem or proc entries.

runner-update-permission-denied high confidence ci github-actions

Matched signals

  • Downloading runner update fails
  • An error occurred: Access to the path is denied
  • Access to the path '/proc/
  • Failed to update oom_score_adj
  • Runner update in progress, do not shutdown runner
  • UnauthorizedAccessException

Self-hosted runner update permission failure

What this failure means

A self-hosted runner tried to update itself or adjust worker process settings, but the environment denied access to the runner filesystem or proc entries.

Symptoms

Faultline looks for one or more of these log fragments:

Downloading runner update fails
An error occurred: Access to the path is denied
Access to the path '/proc/
Failed to update oom_score_adj
Runner update in progress, do not shutdown runner
UnauthorizedAccessException

Diagnosis

A self-hosted runner tried to update itself or adjust worker process settings, but the environment denied access to the runner filesystem or proc entries.

This usually happens when the runner is containerized with overly strict ownership or when the job environment blocks access to _work or /proc/*/oom_score_adj.

Fix steps

  1. Check the ownership and permissions on the runner root, work directory, and proc mount that the runner is trying to touch.
  2. If the runner is containerized, ensure the container runs with the user and group expected by the runner image.
  3. Confirm the runner can write to its working directory and update its own binaries or configuration.
  4. If the failure only appears after an autoscaling or container-mode change, compare the pod or container security context with a known-good runner deployment.

Validation

  • The runner starts without Access to the path is denied.
  • The update step completes and the job proceeds past runner startup.

Why it matters

Runner update and startup failures block every job on that runner. If the runner cannot update or adjust its own process state, it can fail before it ever reaches the user workflow.

Prevention

  • Bake the expected runner permissions into the image or deployment manifest.
  • Keep autoscaling runner security contexts consistent across environments.
  • Verify _work and runner root ownership after image or Helm chart changes.

Try it locally

id
ls -la /runner
id

How Faultline detects it

Use faultline explain runner-update-permission-denied to see the full playbook.

faultline analyze build.log
faultline explain runner-update-permission-denied

Generated from playbooks/bundled/log/ci/runner-update-permission-denied.yaml. Do not edit directly.

Try it on your own failed log

$ faultline analyze failed.log
Want this across every CI run? Faultline Teams tracks recurring failures across all your repos and surfaces patterns in a shared dashboard.