Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Operation not permitted" when running on external volume under Mac OS #3695

Open
yanghua-ola opened this issue Feb 3, 2025 · 1 comment
Labels
bug Something isn't working

Comments

@yanghua-ola
Copy link

yanghua-ola commented Feb 3, 2025

Describe the bug
I installed the runner on an external volume. When I tried to start it with launchctl (underlying command: /Volumes/WD/github-runner-00.studio.internal/runsvc.sh), I got an "operation not permitted" error.
Image

#1958 suggested giving full disk access to /bin/bash and /bin/sh. In my case it wasn't enough. I had to give full disk access to node binary too, e.g. /Volumes/WD/github-runner-00.studio.internal/externals/node20/bin/node to make it work. This problem also happens when any build step accesses an external volume, for example, putting go build cache on external volume.

It works great until the auto update kicks in. Each runner update comes with a new node binary, e.g. /Volumes/WD/github-runner-00.studio.internal/externals.2.322.0/node20/bin/node. The runner won't start until I give the new node binary full disk access.

I'd really prefer not having to deal with this for 10 runners each time after an update. I am running the Mac headless, and don't always have access to the GUI.

To Reproduce

Steps to reproduce the behavior:

  1. Attach an external hard disk to Mac
  2. Provision a runner as per GitHub documentation
  3. Start the runner runsvc.sh and you should see the permission error
  4. Give the node binary coming with the runner Full Disk Access in System Preferences->Security & Privacy->Full Disk Access
  5. Start the runner again, it should work this time.

I don't know how to trigger a runner software update; but problem caused by the update should be easy to perceive if above behavior is reproducible.

Expected behavior
After a runner was provisioned on an external volume and Full Disk Access permission was given, the runner should continue to work after auto update.

Runner Version and Platform

Version of your runner?
2.322.0

OS of the machine running the runner?
OSX Sonoma 14.6.1

What's not working?

Please include error messages and screenshots.

Job Log Output

If applicable, include the relevant part of the job / step log output here. All sensitive information should already be masked out, but please double-check before pasting here.

Runner and Worker's Diagnostic Logs

If applicable, add relevant diagnostic log information. Logs are located in the runner's _diag folder. The runner logs are prefixed with Runner_ and the worker logs are prefixed with Worker_. Each job run correlates to a worker log. All sensitive information should already be masked out, but please double-check before pasting here.

@yanghua-ola yanghua-ola added the bug Something isn't working label Feb 3, 2025
@yanghua-ola
Copy link
Author

yanghua-ola commented Feb 4, 2025

I implemented a workaround:

  1. extract the node binary coming with the package to a path, say $fixed_node
  2. create a copy of runsvc.sh, e.g. runsvc_custom.sh
  3. update runsvc_custom.sh, change the node binary to $fixed_node
  4. update the plist file, use runsvc_custom.sh instead
  5. this setup would survive auto-update as long as
    1. no major node version update was required, e.g. node 16 to node 20
    2. no breaking change was made to runsvc.sh

Admittedly it is not robust. However a permanent fix could be implemented in the same vein:

  1. during auto-update, instead of converting externals folder to a symlink to the current version, let the current version take that name. That way path to the active node binary remains the same; and 'Full Disk Access' privacy setting remains effective.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant