macos-15-arm64 - permission denied errors, only after 2026-01-21

[mpilgrem]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Actions Runner

Discussion Details

rio is a Haskell package and it uses GitHub Actions for CI on various operating systems. One of its unit tests is withBinaryFileDurable, which worked fine on GitHub-hosted runner macos-15-arm64 up to 2026-01-21 and still works fine on a local macOS 26.2/M1 machine. However, after that date (first noticed on or about 2026-01-26), the test (without changes to the code) has failed (on the macOS runner only) with:

rio        >   1) RIO.File.withBinaryFileDurable, happy path, works the same as withFile
rio        >        uncaught exception: IOException of type PermissionDenied
rio        >        /Users/runner/work/_temp/rio5336/with_file_durable: withBinaryFile: permission denied (Permission denied)

ChatGPT (which can hallucinate) says that the GitHub Actions file system is set up in such a way that certain file operations that are valid on local macOS machines are prohibited, but that is not documented. Is that correct? Did something change after 2026-01-21?

If it helps, the working CI had:

Runner Image Provisioner
  Hosted Compute Agent
  Version: 20260115.477
  Commit: 4b342d620503cbe250a3154040964899ea7c9b00
  Build Date: 2026-01-15T22:32:41Z
  Worker ID: {5f03b497-c83d-45ea-a757-b72c5d9f4063}
  Azure Region: westus

and the failing CI had:

Runner Image Provisioner
  Hosted Compute Agent
  Version: 20260123.484
  Commit: 6bd6555ca37d84114959e1c76d2c01448ff61c5d
  Build Date: 2026-01-23T19:41:17Z
  Worker ID: {4e791ad1-f366-43fd-bc11-9831105a0a79}
  Azure Region: westus

(the Current runner version, Operating System, Runner Imager in each case are identical).

[Manoj7ar]

Hi,

this doesn’t look like an undocumented “GitHub forbids certain filesystem operations” rule.

A PermissionDenied (EACCES) at /Users/runner/work/_temp/... on a GitHub-hosted macOS runner is almost always plain POSIX permissions / ownership / ACLs (or umask / mount option drift). GitHub’s own docs explicitly warn that the runner temp directory is cleared between jobs but files won’t be removed if the runner user lacks permission — which strongly suggests that “permission mismatches in temp” are a real, supported failure mode. :contentReference[oaicite:0]{index=0}

Given your timeline (works up to 2026-01-21; fails first noticed ~2026-01-26) and that only the Runner Image Provisioner / Hosted Compute Agent version changed, this smells like either:

• a provisioner/agent regression affecting permissions/ACLs under _temp, or
• permission contamination earlier in the workflow (e.g. a sudo step creates/chmods something under $RUNNER_TEMP, then later steps run as runner and can’t write).

There have been runner-side permission regressions before that surfaced as EACCES in otherwise normal steps. :contentReference[oaicite:1]{index=1}

---

Quick probe to confirm what’s happening

If you can add one diagnostic step immediately before the failing test step (on macos-15-arm64), it should tell us in a single run whether _temp (and the specific failing directory) is writable at failure time:

set -euxo pipefail

echo "whoami=$(whoami)"
id
umask
echo "RUNNER_TEMP=$RUNNER_TEMP"
echo "TMPDIR=${TMPDIR:-"(unset)"}"

# Show perms + ACLs on the temp area (macOS: -e shows ACLs)
ls -ldOe@ /Users/runner/work/_temp || true
ls -ldOe@ "$RUNNER_TEMP" || true

# If the failing directory exists, dump its perms too
ls -ldOe@ /Users/runner/work/_temp/rio* || true

# Repro: create + write in a fresh subdir
d="$(mktemp -d "$RUNNER_TEMP/rio-probe.XXXXXX")"
ls -ldOe@ "$d"
touch "$d/can_write"
ls -lOe@ "$d/can_write"

[mpilgrem]

@Manoj7ar, thanks for your prompt input. I'll investigate ...

[Manoj7ar]

No worries! sounds intersting, keep me in the loop!

[mpilgrem]

The result of my investigation is below:

  set -euxo pipefail
  
  echo "whoami=$(whoami)"
  id
  umask
  echo "RUNNER_TEMP=$RUNNER_TEMP"
  echo "TMPDIR=${TMPDIR:-"(unset)"}"
  
  # Show perms + ACLs on the temp area (macOS: -e shows ACLs)
  ls -ldOe@ /Users/runner/work/_temp || true
  ls -ldOe@ "$RUNNER_TEMP" || true
  
  # If the failing directory exists, dump its perms too
  ls -ldOe@ /Users/runner/work/_temp/rio* || true
  
  # Repro: create + write in a fresh subdir
  d="$(mktemp -d "$RUNNER_TEMP/rio-probe.XXXXXX")"
  ls -ldOe@ "$d"
  touch "$d/can_write"
  ls -lOe@ "$d/can_write"
  shell: /bin/bash -e {0}
  env:
    TMPDIR: /Users/runner/work/_temp
++ whoami
+ echo whoami=runner
+ id
whoami=runner
uid=501(runner) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),264(_webdeveloper),701(com.apple.sharepoint.group.1),33(_appstore),98(_lpadmin),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae)
+ umask
+ echo RUNNER_TEMP=/Users/runner/work/_temp
+ echo TMPDIR=/Users/runner/work/_temp
+ ls -ldOe@ /Users/runner/work/_temp
0022
RUNNER_TEMP=/Users/runner/work/_temp
TMPDIR=/Users/runner/work/_temp
drwxr-xr-x  7 runner  staff  - 224 Feb  7 22:07 /Users/runner/work/_temp
+ ls -ldOe@ /Users/runner/work/_temp
drwxr-xr-x  7 runner  staff  - 224 Feb  7 22:07 /Users/runner/work/_temp
+ ls -ldOe@ '/Users/runner/work/_temp/rio*'
ls: /Users/runner/work/_temp/rio*: No such file or directory
+ true
++ mktemp -d /Users/runner/work/_temp/rio-probe.XXXXXX
+ d=/Users/runner/work/_temp/rio-probe.qRMBEu
+ ls -ldOe@ /Users/runner/work/_temp/rio-probe.qRMBEu
drwx------  2 runner  staff  - 64 Feb  7 22:07 /Users/runner/work/_temp/rio-probe.qRMBEu
+ touch /Users/runner/work/_temp/rio-probe.qRMBEu/can_write
+ ls -lOe@ /Users/runner/work/_temp/rio-probe.qRMBEu/can_write
-rw-r--r--  1 runner  staff  - 0 Feb  7 22:07 /Users/runner/work/_temp/rio-probe.qRMBEu/can_write

ChatGPT was offering up this sort of output (which I do not follow):

Durability operations are exactly the kind of thing CI runners don’t want.

*Strongest hypothesis (90%+)*
`withBinaryFileDurable` is doing at least one of the following:
* opening with `O_SYNC` / `O_DSYNC`
* calling `fsync` on:
    * the file descriptor
    * or the directory
* using `rename` for atomic replace
* opening via `openFd` instead of `openBinaryFile`

And one of those syscalls is rejected in `_temp` on CI macOS, but allowed on your local machine.

*Why this fails on GitHub macOS CI*
* macOS allows `openat()` on normal volumes for `O_WRONLY | O_CREAT | O_NOCTTY`
* CI runner volume is ephemeral / VM-backed / APFS
* Certain combinations like `openat + O_CREAT` on a scratch VM volume are rejected
* The kernel returns `EACCES`, even though the directory is writable
✅ This matches exactly your symptom:
`withBinaryFile: permission denied`
The file isn’t created — open fails immediately.

[Manoj7ar]

Thanks for running the probe, that output is super useful, and it actually rules out the “_temp is generally unwritable / CI forbids normal file creation” theory.

What your probe does tell us:

• _temp is owned by runner:staff and is writable: drwxr-xr-x … runner staff … /Users/runner/work/_temp
• No ACLs are shown (ls -ldOe@ prints -), and umask is normal (0022)
• Creating a fresh temp directory and writing a file works fine:
  • mktemp -d $RUNNER_TEMP/... --- is correct!
  • touch .../can_write ---is correct!

So this is not a blanket “GitHub runner blocks create/open in _temp” situation.

Why the “durability syscalls are rejected” hypothesis doesn’t fit the observed error

Your exception is:

withBinaryFile: permission denied

That typically means the failure occurs during the initial open/create (i.e., open()), before you’d reach the “durability” parts (fsync, directory fsync, rename, etc.). If something like fsync/rename were being rejected, you’d usually see the error attributed to that step (or at least after the file exists).

Also, since touch succeeds in the exact same parent directory, it’s very hard to reconcile that with “openat + O_CREAT is rejected on this volume”.

Where I’d look next (very likely causes)

At this point the failure is probably specific to the exact path used by the test at runtime, e.g.:

• The parent directory (.../_temp/rio5336) exists but is not writable at that moment (wrong owner/perms/ACL).
• A prior step (or a concurrent test) created the directory/file using sudo / different user, leaving it owned by root or with restrictive perms.
• There’s a race between tests using the same directory name (less likely, but worth ruling out).
• The target path already exists with non-writable permissions (rare on a fresh runner, but possible within a job if tests reuse paths).

Suggested next diagnostic (target the actual failing path)

Since the directory name is dynamic (rio5336), the easiest way is to log/inspect it right before the failing open.

If you can change the test temporarily, wrap the call so that on failure it prints the filesystem metadata for:

• the parent directory
• the target file (if it exists)

For example (shell-side, if you can print the chosen temp dir path from the test):

# assuming you can get $DIR and $FILE from the test output
ls -ldOe@ "$DIR" || true
ls -lOe@ "$FILE" || true
stat -f '%Sp %u %g %N' "$DIR" || true
stat -f '%Sp %u %g %N' "$FILE" || true

If you can’t easily print the path, another quick approach is to force a deterministic directory for one run (e.g. rio-debug) so you can inspect it reliably when it fails.

Quick isolation test (workaround + signal)

Try running the same test with temp redirected into the workspace:

export TMPDIR="$GITHUB_WORKSPACE/.tmp"
mkdir -p "$TMPDIR"
chmod 700 "$TMPDIR"

• If it starts passing consistently, that strongly suggests something about $RUNNER_TEMP within the job (ownership drift, cleanup, a prior step touching it), not “durability syscalls”.

Also worth checking: any sudo in the workflow

Even one step that writes into $RUNNER_TEMP as root can create exactly this kind of symptom later. If you share the workflow snippet around setup steps, it’s usually quick to spot the typical culprits.

Net: your probe shows _temp itself is healthy and writable. The next step is to capture permissions/ownership on the exact rio#### directory and with_file_durable path right at failure time, that will almost certainly explain the EACCES.

::contentReference[oaicite:0]{index=0}

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬