Stderr: fatal: not in a git directory

Using Jenkins
,
1

Hi team,

I have upgraded my Jenkins from version [Jenkins 2.332.3] to Jenkins 2.401.1. After the upgrade multi branch pipelines are giving below error.

stderr: fatal: not in a git directory

I’m using Linux machine and running as container.
The Git version is Git pluginVersion5.2.1

2

Hi there,

Command line git included in recent container images and recent operating system releases includes a fix for a security issue. Command line git now refuses to perform operations in repositories when the directory is not owned by the current user.

JENKINS-70540 includes a set of steps that show how to duplicate the issue. In that issue report, I noted:

Command line git has decided that it is dangerous to perform git operations in a directory owned by a different user. I may consider a way to better detect it and better alert the administrator that there is a problem, but ultimately it is a mistake to perform git operations in a directory owned by a different user without intentionally configuring the safe.directory to allow it.

The preferred alternative is to fix the permissions on the directories so that they are owned by the user that is calling command line git.

A description of command line git CVE-2022-24765 is available in a GitHub blog post. The Red Hat description is also quite helpful, as is the Debian description.

1 Like
3

Hi Mark,

Thank you so much for the response. I removed .git in the Jenkins pipeline configuration in the for the project repository. After that it’s start working fine. Could you please explain what was the issue. I will check the your references.

I have attached the screenshot working and non-working. Please check.

Non-working-after-the-upgrade
Non-working-after-the-upgrade1321×322 14 KB

Working-after-the-upgrade
Working-after-the-upgrade1332×209 11 KB

5

Hi Mark,

Thank you so much for the response. I removed .git in the Jenkins pipeline configuration in the for the project repository. After that it’s start working fine. Could you please explain what was the issue. I will check the your references.

I have attached the screenshot working and non-working. Please check.

Non-working-after-the-upgrade
Non-working-after-the-upgrade1321×322 14 KB

Working-after-the-upgrade
Working-after-the-upgrade1332×209 11 KB

6

Command line git now refuses to perform operations in repositories when the directory is not owned by the current user. One or more directories inside your container image were not owned by the user that runs the Jenkins process in the container. You’ll need to fix whatever problem was causing those directories to be owned by the wrong user.

That problem could be that you’re mounting a volume inside your Jenkins container and the ownership on the directories in the volume is incorrect. A process or a job inside the container could be changing the ownership of the directories. There are many ways that type of damage could happen. You’ll need to find the cause of the damage and fix it.

7

Hi Mark,

Thank you so much for the response. I have verified permissions for working project and non-working project in the server level. The permissions are same and still not working, getting same error.

Could you please help possible issues?

8

You use the word “permissions” and the issue is not related to permissions but to ownership. You’ll need to check more carefully.

9

Hi Mark,

Sorry for the mistake. I checked ownership only and both the projects ownership is with root user only.
And I configured new job which was not present and getting same error.
Could you please explain how this will be the ownership issue, the for the new Job how permission issue?

10

That is the problem. The Jenkins process does not run as the root user and it should not run as the root user. If the folders are owned by the root user, then they are owned by the wrong user. They need to be owned by the user jenkins.

1 Like
11

Hi Mark,

We are having issue for few Jobs only and most of the Jobs are working fine even though they are owned by root user. How it’s working for other Jobs.

12

Maybe those jobs were cloned before the restriction was applied. Maybe some other condition. You’re best suited to answer that question yourself by performing local experiments.

Some questions you might ask yourself while exploring:

  • Is the problem solved when fix the ownership of the directories and the files in those directories is fixed?
    • If not, are you certain that you’ve found the correct directory to fix the ownership?
  • Are there any other files or directories in the Jenkins home directory that are not owned by the jenkins user?
    • Why were those files or directories created with incorrect ownership?
    • What will you change to prevent new files and new directories from being created with incorrect ownership?
13

Hi Mark,

Thank you so much for the response.
We are running Jenkins as Container and don’t have Jenkins user user in the server. It’s was working from long back without any issue. We have upgraded the Jenkins two days back and started the issue.

14

Yes, though I would say it differently. There has been something wrong with your container configuration for a very long time. The security fix for command line git has exposed that problem in your container configuration.

You can either find and fix the error in your container configuration or you can apply a workaround that hides the configuration error. The workaround is described in the command line git CVE and in other locations. It involves creating a configuration file that tells command line git to not apply the security fix. Refer to a blog post as one example of the workaround.