checkout: `fatal: unsafe repository (REPO is owned by someone else)` with ubuntu 20.04 container

I think it is related to this: https://github.blog/2022-04-12-git-security-vulnerability-announced/

Thanks for the report, our team is working on a fix

Running git config --global --add safe.directory /github/workspace doesnt fix the issue for me, nor does export GIT_CEILING_DIRECTORIES=/__w :

fatal: unsafe repository ('/github/workspace' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace

Can anybody explain why, if the container is using a version of git < 2.35.2, we see the issue and an error message:

  To add an exception for this directory, call:
  
  	git config --global --add safe.directory /__w/spack/spack
  Error: The process '/usr/bin/git' failed with exit code 128

referencing an option that is introduced in v2.35.2 ? (If it matters in my case it’s git v2.25.1 and Ubuntu 20.04)

EDIT: Leaving the reply here for the record. Ubuntu patched git on Apr 8th, so we get a breaking behavior and a security fix without any version bump.

I worked around this issue in my repo by adding the following step before the actions/checkout step:

      - name: work around permission issue
        run: git config --global --add safe.directory /__w/quick-lint-js/quick-lint-js

(My repo is named quick-lint-js.)

Our team is hoping to bring a targeted patch to the checkout action today, and bump the major versions v2 and v3. You should automatically get those fixes if you are tied to the major version tag.

This fix will cover the mainline scenarios of checking out git repositories. However, if you use git in your workflow, either inside a container or on a self hosted runner where the workspace folder is not owned by the runner user, you may continue to see issues. You will want to keep a step where you set the safe.directory to ensure your workflow works as intended.

We are also looking what other changes we need to make to the ecosystem to help non actions/checkout users, and checkout users who use git outside of checkout in their workflows.

Looks like with git 2.35.3, git config --global --add safe.directory * will work to opt-out of the safe directory check.

https://github.com/git/git/commit/1ac7422e39b0043250b026f9988d0da24cb2cb58#diff-c62827315018c95283562ab55db59c26e544debaad579b77a7f96ffed09c45c2R18

This issue seems only happens for workflows based on docker container, workflows directly running on runners is not affected.

git config --global --add safe.directory /__w/REPO/REPO workaround is only available with git v2.35.2, for older git, define the GIT_CEILING_DIRECTORIES to __w instead (but this won’t work on v2.35.2).

So as a workaround for git before v2.35.2, add this step before checkout:

     - name: Trust My Directory
       run: export GIT_CEILING_DIRECTORIES=/__w # only work before git v2.35.2

My trial-and-errors are at Locietta/github-action-playground.

Same issue with the Windows runners, and it is indeed because of the security fix for CVE-2022-24765.

The quick fix is to add a step before the checkout action to run git config --global --add safe.directory <path>. The better fix will be for the runners / containers / &c. to set this automatically; on the GitHub runners, at least, because they’re not shared, I don’t believe there’s any risk of actually hitting this vulnerability.

1. Update your git version as 2.35.3
2. sudo git config --global --add safe.directory /your/directory/path/here Remove the slash at the end of your directory path.

Note: Although the command I used did not give an error when typing the working directory, ending with ‘/’ or not using sudo, it did not solve the problem. This is for the server-side.

The actions/checkout@v2 tag has been updated to reflect the newest major version v2.4.1 which fixes this issue 🎉

Commit: f25a3a9f25bd5f4c5d77189cab02ff357b5aedeb.

A fix for v3 will come shortly. Please let me know if you see any issues! Thank you for your patience while we address this issue

Not related to this repository, but I recently upgraded my Git CLI on an Ubuntu 20.04 machine and got this error when attempting to run git commands as root in a user’s home directory.

git version 2.25.1

The fix for me was adding sudo before git config --global --add Like, sudo git config --global --add …

Can I set it globally instead of setting it for each repo?

Hello!

This started happening recently; I see it both with v2.4.0 and v.3.0.0:

Syncing repository: wez/wezterm
Getting Git version info
Deleting the contents of '/__w/wezterm/wezterm'
Initializing the repository
  /usr/bin/git init /__w/wezterm/wezterm
  Initialized empty Git repository in /__w/wezterm/wezterm/.git/
  /usr/bin/git remote add origin https://github.com/wez/wezterm
  Error: fatal: unsafe repository ('/__w/wezterm/wezterm' is owned by someone else)
  To add an exception for this directory, call:
  
  	git config --global --add safe.directory /__w/wezterm/wezterm
  Error: The process '/usr/bin/git' failed with exit code 128

Is there a way to configure/advise the action how to handle this? Is this really a problem elsewhere in the GH actions environment?

I recently updated git and saw this error too.

I did what @strager said and it worked just fine; moved to the parent directory where .git is stored and did git config --global --add safe.directory /myProject

Hi everyone,

I encountered this error when I run the ubuntu server. First update git version on ubuntu server. After updating you can check with git --version

Next, the git repo address that is the problem should be marked as a safe file. You can use the following command for this. sudo git config --global --add safe.directory /your/directory/path/here

Note: Although the command I used did not give an error when typing the working directory, ending with ‘/’ or not using sudo, it did not solve the problem.

This issue has been closed out because the root issue that prevents checkout from running has been fixed. However, as some of you are observing, if you have other steps in your workflow that run git commands, you will see the same error message. I’ve filed https://github.com/actions/checkout/issues/766 to track that, please post any feedback you have there. It also contains a workaround to help alleviate the pain you are feeling.

Our team is looking into Actions Ecosystem solutions for this problem

Is there any reason why the checkout workflow avoids changing the global git config? I see that it’s setting a temporary home to be able to add the safe.directory flag and clone the repo, can this safe.directory option persist? That would make the fix transparent to most users, it can just have safe.directory = <whatever-GITHUB-WORKSPACE-IS> by default.

We don’t want to set the global git config on a user’s machine to disable a security feature. So we use a temporary git global config for the purposes of the checkout function.

We could try to persist this temporary global configuration for the duration of your job, but there are few problems with that:

1. If you run checkout on the root machine, and you have a container action with git commands, you are still going to fail unless you set the config in that container, which checkout can’t do for another step
2. Overwriting the git global config and not persisting any changes back to the original global config may break some user expectations on self hosted runners.
3. It only really addresses this issue for checkout users, but this is more of an actions ecosystem problem

I feel that this is better solved at an actions ecosystem level, rather than solving it in the checkout action. That way, users not using checkout and users using container actions can take advantage of that solution. This is something our team is actively working on now, but we are sorry for the inconvenience it has caused you. You can set the github workspace as a safe directory as a workaround in the mean time.

Note that this issue suddenly started appearing for the workflows using a recently built (after 8 April 2022) Ubuntu 20.04-based images because the top-level directory owner check patch has been backported:

git (1:2.25.1-1ubuntu3.3) focal-security; urgency=medium

  * SECURITY UPDATE: Run commands in diff users
    - debian/patches/CVE-2022-24765-*.patch: fix GIT_CEILING_DIRECTORIES; add
      an owner check for the top-level-directory; add a function to
      determine whether a path is owned by the current user in patch.c,
      t/t0060-path-utils.sh, setup.c, compat/mingw.c, compat/mingw.h,
      git-compat-util.h.
    - CVE-2022-24765

 -- Leonidas Da Silva Barbosa <leo.barbosa@canonical.com>  Fri, 08 Apr 2022 09:57:16 -0300

See http://changelogs.ubuntu.com/changelogs/pool/main/g/git/git_2.25.1-1ubuntu3.3/changelog

Running git config --global --add safe.directory /github/workspace doesnt fix the issue for me, nor does export GIT_CEILING_DIRECTORIES=/__w :

fatal: unsafe repository ('/github/workspace' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace

Were you able to solve it already? The workaround doesn’t work for us as well.

No, I will wait for a proper fix. The workaround isn’t an elegant one and not easy to implement on multiple repositories.

Other solution is just to make sure your container runs as the same user as actions-runner-controller. In my case this was uid 1000.

For references, adding this before doing the Git stuff worked for our repo:

          git config --global --add safe.directory "$GITHUB_WORKSPACE"

long list of trial and error attempts documented here: https://github.com/geocompr/py/issues/43

Hope my painful experience can be of use to others and thanks everyone sharing know-how on this!

Since all my Git repositories reside within D:\htdocs directory, some unusual folder ownership was causing this issue. For the case of Windows 11, I have done the below to solve this issue of ownership:

• From explorer, I have opened D:\htdocs
• Right-click and select Properties
• Go to the Security tab and click the Advanced button at the bottom. You can now see the real owner with <name>, but for inside git repo, that was different.
• No worries, check the Replace all child object permission entries with inheritable permission entries from this object and click Apply to proceed. Later click OK!
• Hakuna Matata, the git repo where you were facing those issues should now be resolved!

For the people who are still having issues with this, you could be running your container or action as another user without realizing, doing sudo git config --global <foo> which will store the configuration in a different home path, making it unavailable to the current user running the git command.

git config --global safe.directory "$GITHUB_WORKSPACE" git config --global safe.directory /github/workspace

could be the only commands you need to get this working, I would recommend trying the first one before trying the second one, if this doesn’t work try doing whoami and checking if you’re running as the same user that’s executing git later on.

On my server I did this to mark all projects as safe for every people to work on:

for file in /home/<path>/*/; do sudo git config --system --add safe.directory $file; done

this will add all the sub-folders from the directory to the system-wide config of git. This way I don’t have to set it for each project, for each user.

Running git config --global --add safe.directory /github/workspace doesnt fix the issue for me, nor does export GIT_CEILING_DIRECTORIES=/__w :

fatal: unsafe repository ('/github/workspace' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace

Were you able to solve it already? The workaround doesn’t work for us as well.

The workaround is better than nothing.

However for an entire folder of projects on a server, it’s a pain having to add each project to the safe directories in the global gitconfig. There needs to be a way to whitelist an entire network drive or folder

If you want to bypass the issue:

cat <<EOF >> /etc/gitconfig
[safe]
        directory = *
EOF

@TingluoHuang I can’t share the link since it’s all inside a private organization, but I’ve solved the issue by adding this before running any git other command:

git config --global --add safe.directory "$GITHUB_WORKSPACE"

For the people who have a workflow failing because of this, you can just use that command to get it working again.

Just here to confirm that I’ve only been able to recreate this issue for jobs running inside a docker container. Workflows that execute directly on a runner seem unaffected.

faced with the same issue on several projects, waiting for the fix

I can confirm that adding the command: git config --global --add safe.directory /github/workspace Indeed works

Two things to note:

1. Since this issue is for actions that runs on a docker container - this command needs to be executed from INSIDE the container!
2. Only works for version older than 2.35.2

Hello!

This started happening recently; I see it both with v2.4.0 and v.3.0.0:

Syncing repository: wez/wezterm
Getting Git version info
Deleting the contents of '/__w/wezterm/wezterm'
Initializing the repository
  /usr/bin/git init /__w/wezterm/wezterm
  Initialized empty Git repository in /__w/wezterm/wezterm/.git/
  /usr/bin/git remote add origin https://github.com/wez/wezterm
  Error: fatal: unsafe repository ('/__w/wezterm/wezterm' is owned by someone else)
  To add an exception for this directory, call:
  
  	git config --global --add safe.directory /__w/wezterm/wezterm
  Error: The process '/usr/bin/git' failed with exit code 128

Is there a way to configure/advise the action how to handle this? Is this really a problem elsewhere in the GH actions environment?

To Fix this you only need to change the owner of the HDD in his propierties/advanced options and then change the owner

The fix for me was adding sudo before git config --global --add Like, sudo git config --global --add …

This worked!!!1

Getting this error if running git pull as sudo, without privilege everything pulls ok

I’ve been getting this error, but I had fixed by doing the safe.directory command. I’m on Ubuntu 20.04 and tried to use Git CLI with “sudo” permission, and for my surprise I was able to use all Git commands I needed. Not really sure if it’s my drive’s filesystem or something related to the recent update.

I had found that VS Code is unable to manage the project repository if the directory is not in safe.directory configs too. It can create the .git, but does not recognize as a Git Repo. Not really sure if this is going to be fixed, but I found that’s really annoying.

EDIT1: I’m not using any Docker container in my project. EDIT2: GitLens extension also does not work in projects directories without safe.directory command.

hi team,

is this fix or not, tried everything mentioned above, but not working.

please resolve this.

Same^

I used PPA. And run ‘sudo git config --global --add safe.directory /var/www/myproject’ After that, I used this command: git pull origin master. It shows same error. ‘fatal: unsafe repository (’/var/www/myproject’ is owned by someone else) To add an exception for this directory, call: git config --global --add safe.directory /var/www/myproject’

I really can not know what is the issue.

On my DigitalOcean Server Instance (Ubuntu), I got this issue and had to use ‘sudo’.

‘git config --global --add safe.directory /path/to/project’ -> Executed without issue, But did not work

‘sudo git config --global --add safe.directory /path/to/project’ -> Worked

This should be a no brainer for any system administrator / command line user, but thought I’d mention this explicitly because this solved this issue for me and I haven’t seen this answer from anyone else.

It appears that the command:

git config --global --add safe.directory ‘C:/Data/Foo Bar’

gives a syntax error in git for Windows–probably because of the space? That is the command that is recommended by git. However, double quotes do seem to work.

None of these workarounds worked for us, this CVE fix seems to have broken https://github.com/ad-m/github-push-action that we used to publish to GitHub pages:

      - name: Deploy to GitHub Pages
        run: |
          git init
          git config --global --add safe.directory "$GITHUB_WORKSPACE"
          git config --local user.email "action@github.com"
          git config --local user.name "GitHub Action"
          git add -A
          git commit -m 'deploy'2
      - name: Force push to destination branch
        uses: ad-m/github-push-action@v0.5.0
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          branch: gh-pages
          force: true
          directory: ./docs/.vitepress/dist

In the end we had to abandon the action for the more purpose-specific https://github.com/peaceiris/actions-gh-pages

      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./docs/.vitepress/dist
          user_name: 'GitHub Action'
          user_email: 'action@github.com'

Which now lets us publish docs again. Hope this helps others having the same issue.

Is there any reason why the checkout workflow avoids changing the global git config? I see that it’s setting a temporary home to be able to add the safe.directory flag and clone the repo, can this safe.directory option persist? That would make the fix transparent to most users, it can just have safe.directory = <whatever-GITHUB-WORKSPACE-IS> by default.

@EduardoRT can you provide a link to your workflow if its open source, or a snippet from it otherwise?

@thboop, is this fixed yet?

Hi Guys, I am facing same issue. But here is quick fix for me. my .git folder have owner www-data and only /var/www/html folder have sftp owner. I just changed /var/www/html owner to www-data and it is fixed.

Like @etwinomujuni, for me the workaround only worked once I:

• Specified the git folder path explicitly (no using ~ in place of /home/.../)
• Use “sudo”

So the command was sudo git config --global --add safe.directory /home/<user>/.../<repo_name>

After this sudo git fetch no longer gave the error fatal: unsafe repository ('<repo_path>' is owned by someone else)

Ditto!

The suggested command git config --global --add safe.directory <path> worked for me