v2.332.0: Container jobs fail with permission denied on GITHUB_ENV and workspace after upgrade from v2.330.0

Description

After upgrading ARC (Actions Runner Controller) runners from v2.330.0 to v2.332.0, container jobs fail in multiple ways due to UID/ownership mismatches between the runner and job containers.

Environment

• Runner version: v2.332.0 (upgraded from v2.330.0)
• Platform: ARC on Kubernetes (EKS)
• Container hooks: v0.8.1 (bundled with v2.332.0)

Problems

1. $GITHUB_ENV / $GITHUB_OUTPUT permission denied in container: jobs

Workflows using the native container: directive with a non-root user fail when any step writes to $GITHUB_ENV or $GITHUB_OUTPUT:

/__w/_temp/36e38446.sh: 5: cannot create /__w/_temp/_runner_file_commands/set_env_7bb88aaa: Permission denied

The runner file command directories under /__w/_temp/_runner_file_commands/ are owned by a UID that doesn't match the container user.

Workflow example:

jobs:
  test:
    runs-on: self-hosted
    container:
      image: my-image:latest
      options: --user 1000
    steps:
      - run: echo "FOO=bar" >> $GITHUB_ENV  # Permission denied

2. Git "dubious ownership" in job containers

Containers launched by job steps get git ownership errors because the container user doesn't match the workspace volume owner:

fatal: detected dubious ownership in repository at '/workspace'

The Ubuntu 24.04 base image (introduced in v2.331.0) ships git 2.43+ which has stricter safe.directory enforcement than the previous Ubuntu 22.04 base.

3. Workspace not writable by non-root container users

Non-root users inside job containers cannot write to the mounted workspace volume:

/workspace/vendor does not exist and could not be created

Root cause

The v2.330.0 → v2.332.0 upgrade introduced several compounding changes:

1. v2.331.0: Base image changed from Ubuntu 22.04 to Ubuntu 24.04 (PR #4018), shipping git 2.43+ with stricter safe.directory checks
2. v2.332.0: Container hooks bumped to v0.8.1 (PR #4222), which changes workspace ownership handling but only for the runner container — not for job containers

The container hooks v0.8.1 fix (PRs #264, #283) correctly sets workspace permissions for the runner pod itself, but downstream job containers still see UID mismatches because the runner file command directories and mounted volumes are owned by the runner UID.

Expected behavior

Container jobs using non-root users should work the same way they did before the upgrade. The runner should ensure that /__w/_temp/_runner_file_commands/ and workspace volumes are accessible by the container user specified in container.options.

Related issues

• #4131 — Permissions issue on runners v2.330.0 (/home/runner ownership regression)
• #4251 — TempDirectoryManager fails to clean temp directory (permission denied on v2.331.0)
• actions/runner-container-hooks#282 — Permissions denied on workingDir

Reproduce the supplied non-root container workflow on ARC/EKS and trace container hooks v0.8.1 handling of the workspace and /__w/_temp/_runner_file_commands/ directories. Compare behavior with v2.330.0 and inspect the related issues and container-hooks issue for context. Done means non-root container jobs can write GITHUB_ENV and GITHUB_OUTPUT, use git, and modify the workspace without permission errors.