Permissions issue on runners v2.330.0

[diogotorres97]

@TingluoHuang @nikola-jokic This is a breaking change after upgrading the GitHub runner from 2.329.0 to 2.330.0. We are now seeing the error “failed to initialize build cache.” We need to revert back to 2.329.0. Could you please fix this so we don’t need separate handling on our side?.

failed to initialize build cache at /home/runner/.cache/go-build: mkdir /home/runner/.cache/go-build: permission denied
Error: Command failed: /opt/hostedtoolcache/go/1.25.1/x64/bin/go env
failed to initialize build cache at /home/runner/.cache/go-build: mkdir /home/runner/.cache/go-build: permission denied

Originally posted by @anuragstar in #4083

  ➤ YN0001: │ foobar@https://github.com/foo.git#commit=9434354e7bf8f19d229fecabbef9dedc678f5c47: Failed cloning the repository
  ➤ YN0001: │   Repository URL: https://github.com/foo.git
  ➤ YN0001: │   Error: invalid key:  core.autocrlf
  ➤ YN0001: │   Fatal Error: unable to write parameters to config file
  ➤ YN0001: │   Exit Code: 128

issues cloning private repositories

[caxu-rh]

One difference I'm seeing is in the owner uid/gid of the /home/runner directory.

• In 2.329.0: Access: (0750/drwxr-x---) Uid: ( 1001/ runner) Gid: ( 1001/ runner)
• In 2.330.0: Access: (0777/drwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)

(The access change 750 -> 777 is expected/intended after #4083.)

I think the ownership change is due to moving WORKDIR before the useradd. I don't quite understand how this ownership change is causing the observed behavior, though.

[Jojoooo1]

do you know when it will deployed ? Our pipeline has been broken for multiple days

[anuragstar]

@nikola-jokic When we are releasing this changes, currently this change is not part of 2.330.0 release

[nikola-jokic]

Hey everyone, the new image has been re-published.

[showpointer]

@nikola-jokic We’re still seeing the same permission error on v2.330.0.
Could you please confirm if the fix from #4132
is included in the re-published 2.330.0 image?
We’ve verified that our runners are still using the latest 2.330.0 tag (no 2.330.1 yet).
Just wondering if we need to pull the updated digest manually.

[CameronB15]

We're still seeing this error on GitHub hosted runners. Looks like they're running v2.329.0 though. Is there an ETA on a fix for GitHub hosted runners? Or details of a workaround?

From the "Set up job" step:

Current runner version: '2.329.0'
Runner Image Provisioner
Hosted Compute Agent
Version: 20251124.448
Commit: fda5086b43ec66ade217e5fcd18146c879571177
Build Date: 2025-11-24T21:16:26Z
Operating System
Ubuntu
24.04.3
LTS
Runner Image
Image: ubuntu-24.04
Version: 20251126.144.1
Included Software: https://github.com/actions/runner-images/blob/ubuntu24/20251126.144/images/ubuntu/Ubuntu2404-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20251126.144

And this is Yarn unable to install the private repository - note that this does work locally.

! Corepack is about to download https://repo.yarnpkg.com/4.9.4/packages/yarnpkg-cli/bin/yarn.js
➤ YN0000: · Yarn 4.9.4
➤ YN0000: ┌ Resolution step
Resolution step
➤ YN0000: └ Completed in 0s 467ms
➤ YN0000: ┌ Post-resolution validation
Post-resolution validation
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
Fetch step
➤ YN0001: │ @IoT-Database/prisma@ssh://git@github.com/connexin/IoT-Database#workspace=%40IoT-Database%2Fprisma&commit=c636c82ac3f4b0c67bec36df4b7f45a8b4132bfd: Failed cloning the repository
➤ YN0001: │ Repository URL: ssh://git@github.com/connexin/IoT-Database
➤ YN0001: │ Error: invalid key: core.autocrlf
➤ YN0001: │ Fatal Error: unable to write parameters to config file
➤ YN0001: │ Exit Code: 128
➤ YN0001: @IoT-Database/prisma@ssh://git@github.com/connexin/IoT-Database#workspace=%40IoT-Database%2Fprisma&commit=c636c82ac3f4b0c67bec36df4b7f45a8b4132bfd: Failed cloning the repository
➤ YN0001: Repository URL: ssh://git@github.com/connexin/IoT-Database
➤ YN0001: Error: invalid key: core.autocrlf
➤ YN0001: Fatal Error: unable to write parameters to config file
➤ YN0001: Exit Code: 128
➤ YN0000: └ Completed in 17s 457ms
➤ YN0000: · Failed with errors in 17s 960ms

[CameronB15]

We're still seeing this error on GitHub hosted runners. Looks like they're running v2.329.0 though. Is there an ETA on a fix for GitHub hosted runners? Or details of a workaround?

From the "Set up job" step:

Current runner version: '2.329.0'
Runner Image Provisioner
Hosted Compute Agent
Version: 20251124.448
Commit: fda5086b43ec66ade217e5fcd18146c879571177
Build Date: 2025-11-24T21:16:26Z
Operating System
Ubuntu
24.04.3
LTS
Runner Image
Image: ubuntu-24.04
Version: 20251126.144.1
Included Software: https://github.com/actions/runner-images/blob/ubuntu24/20251126.144/images/ubuntu/Ubuntu2404-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20251126.144

And this is Yarn unable to install the private repository - note that this does work locally.

! Corepack is about to download https://repo.yarnpkg.com/4.9.4/packages/yarnpkg-cli/bin/yarn.js
➤ YN0000: · Yarn 4.9.4
➤ YN0000: ┌ Resolution step
Resolution step
➤ YN0000: └ Completed in 0s 467ms
➤ YN0000: ┌ Post-resolution validation
Post-resolution validation
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
Fetch step
➤ YN0001: │ @IoT-Database/prisma@ssh://git@github.com/connexin/IoT-Database#workspace=%40IoT-Database%2Fprisma&commit=c636c82ac3f4b0c67bec36df4b7f45a8b4132bfd: Failed cloning the repository
➤ YN0001: │ Repository URL: ssh://git@github.com/connexin/IoT-Database
➤ YN0001: │ Error: invalid key: core.autocrlf
➤ YN0001: │ Fatal Error: unable to write parameters to config file
➤ YN0001: │ Exit Code: 128
➤ YN0001: @IoT-Database/prisma@ssh://git@github.com/connexin/IoT-Database#workspace=%40IoT-Database%2Fprisma&commit=c636c82ac3f4b0c67bec36df4b7f45a8b4132bfd: Failed cloning the repository
➤ YN0001: Repository URL: ssh://git@github.com/connexin/IoT-Database
➤ YN0001: Error: invalid key: core.autocrlf
➤ YN0001: Fatal Error: unable to write parameters to config file
➤ YN0001: Exit Code: 128
➤ YN0000: └ Completed in 17s 457ms
➤ YN0000: · Failed with errors in 17s 960ms

In case anyone else stumbles across this, it's actually a problem with Git/Yarn. Yarn < v4.12.0 was executing git clone "-c core.autocrlf=false" {{REPO_NAME}} {{TMP_DIR}}. Git version 2.52.0 breaks this quoting, so you have to execute git clone -c core.autocrlf=false {{REPO_NAME}} {{TMP_DIR}}.

Yarn version 4.12.0 fixes this. Run yarn set version berry to upgrade.

[nikola-jokic]

Hey @showpointer,

We just re-published the image so we can avoid rolling out a new release and people potentially using the faulty image. I know it is not a good practice to re-publish the image under the same tag, but we tried to react quickly and we wanted to avoid pushing people to quick upgrades (The runner must be 2 versions behind the latest release). Please update digests. It seamed like more appropriate solution to re-publish instead of shortening the timeline for image upgrades. The fix was introduced quickly enough so all new pulls would use the proper version of the image.

I am sorry issue this caused and I know it is annoying to clear the cache to pull the image.
We try to avoid re-publishing the image as much as possible, but re-publishing to me seams like a more appropriate action to take in this scenario (when you weigh the pros and cons).

[Gandhi11]

@nikola-jokic We are currently facing this problem on our pipeline. We are using a Github owned runner. How do we update the runner to make it run on v2.330.0?

[shinebayar-g]

Btw, after upgrading to yarn 4.12.0 we encountered an interesting bug. See yarnpkg/berry#7019

TLDR;

If you install yarn via corepack (which all of us do) and install packages from the git repository like this: yarn add foo@git+ssh://git@github.com/owner/repo.git,

then if the package you're installing has packageManager field set and uses yarn < 4.12.0, then you'll see this weird error instead of the Error: invalid key: core.autocrlf.

  ➤ YN0000: │ /tmp/xfs-ad231f63 STDOUT Internal Error: redacted@git@github.com:redacted/redacted.git#commit=d69a48a832d647965a05205cf643751de2730f97: Failed cloning the repository
  ➤ YN0000: │ /tmp/xfs-ad231f63 STDOUT     at RH (/home/runner/.cache/node/corepack/v1/yarn/4.7.0/yarn.js:529:10062)
  ➤ YN0000: │ /tmp/xfs-ad231f63 STDOUT     at async /home/runner/.cache/node/corepack/v1/yarn/4.7.0/yarn.js:529:7533

Because during the installation when yarn pack command is invoked, corepack automatically uses the target package's yarn version.