You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
#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:
Attach an external hard disk to Mac
Provision a runner as per GitHub documentation
Start the runner runsvc.sh and you should see the permission error
Give the node binary coming with the runner Full Disk Access in System Preferences->Security & Privacy->Full Disk Access
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.
The text was updated successfully, but these errors were encountered:
extract the node binary coming with the package to a path, say $fixed_node
create a copy of runsvc.sh, e.g. runsvc_custom.sh
update runsvc_custom.sh, change the node binary to $fixed_node
update the plist file, use runsvc_custom.sh instead
this setup would survive auto-update as long as
no major node version update was required, e.g. node 16 to node 20
no breaking change was made to runsvc.sh
Admittedly it is not robust. However a permanent fix could be implemented in the same vein:
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.
Describe the bug
![Image](https://private-user-images.githubusercontent.com/86941588/409025296-61c2dac2-1d22-4224-97e7-bfcf3c2271a9.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg3ODMwNzgsIm5iZiI6MTczODc4Mjc3OCwicGF0aCI6Ii84Njk0MTU4OC80MDkwMjUyOTYtNjFjMmRhYzItMWQyMi00MjI0LTk3ZTctYmZjZjNjMjI3MWE5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA1VDE5MTI1OFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTA0MDlmYjA5ZmY3NmIyN2UyMjI4ZWFhMjE4YzI1OWVhNDdmOTYxYmFhN2Q1NGI4ZDI1YjIzMDE2YTJhYjBjY2UmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.1FhT6VlT-IjF_0Y6ajrkyft7HBzvARDyIhhBj-ZkXKE)
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.#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:
runsvc.sh
and you should see the permission errorFull Disk Access
in System Preferences->Security & Privacy->Full Disk AccessI 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 withRunner_
and the worker logs are prefixed withWorker_
. Each job run correlates to a worker log. All sensitive information should already be masked out, but please double-check before pasting here.The text was updated successfully, but these errors were encountered: