macOS runner: "No such file or directory @ rb_sysopen" (Ruby/gem) in CI

By Daniel Zoghalchali·Latchkey

Ruby raised Errno::ENOENT from rb_sysopen, meaning a file open failed because the path is missing. In CI this is usually a path that exists locally but not on the runner: a config, a vendored asset, or a tool a gem expects.

What this error means

A Ruby tool (Fastlane, CocoaPods, a Rake task) fails with "No such file or directory @ rb_sysopen - <path> (Errno::ENOENT)".

/Library/Ruby/Gems/.../lib/foo.rb:12:in `read': No such file or directory @ rb_sysopen -
/Users/runner/work/app/config/secret.json (Errno::ENOENT)

Diagnose it: is the job queued, or is the runner gone?

A job that never starts and a job whose runner disappeared mid-run look similar in the UI and have opposite causes. The first is a labelling or capacity problem, the second is the runner being killed, usually by memory pressure or a spot reclaim.

- name: Runner facts
  run: |
    echo "runner name: $RUNNER_NAME"
    echo "os/arch:     $RUNNER_OS/$RUNNER_ARCH"
    nproc; free -h; df -h /
    echo "labels this job asked for: ${{ toJSON(job) }}"

Common causes

A file present locally is absent in CI

An untracked config, a gitignored secret, or a generated file that is not produced in CI leaves the path missing when the gem opens it.

A relative path resolves from the wrong directory

The step runs from a different working directory than expected, so a relative open targets a path that does not exist.

How to fix it

Provide the missing file or generate it

1. Read the exact path in the rb_sysopen message.
2. Write the file from a secret, or run the step that generates it, before the failing command.
3. Re-run the Ruby tool.

mkdir -p config
printf '%s' "$SECRET_JSON" > config/secret.json

Run from the correct working directory

Set the step working directory so relative paths resolve to files that actually exist in the checkout.

defaults:
  run:
    working-directory: ./app

The failures that are not your workflow

• Exit 137 is the kernel out-of-memory killer, not an application error. Check free -h above against your peak usage.
• Disk exhaustion presents as unrelated write errors deep in a build. GitHub-hosted runners ship roughly 14 GB of free space, which a Docker-heavy job can exhaust.
• A lost connection to the server on a self-hosted runner is usually the host being reclaimed or rebooted, not a network fault in your job.
• A job that starts and immediately fails with no step output normally failed during runner setup, before your workflow ran at all.

How to prevent it

• Materialize required config and secret files before Ruby steps.
• Use absolute or workspace-rooted paths in CI scripts.
• Set the working directory so relative opens resolve correctly.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions