Amazon web services – Jenkins Git SCM error 128 with good credentials on jenkins deployed in AWS ecs fargate

I set up a jenkins on aws ecs (using official jenkins docker image) with agents also working in aws ecs and it’s workigng great.
But when I tried to edit a pipeline to used git and pull a script from a github repository it didnt worked

I’m facing an error 128.

The credentials to join github are correct (I tested on https and SSH). But each time it fail with and error 128.

Started by user user-admin
Checking out git https://github.com/project/project-jenkins.git/ into /var/jenkins_home/workspace/trigger-gitlab-deploy@script/42b7b18e861df0b75ee35873b425e5868cf680207c5d0c9a900960ef6bc6fcb9 to read jobs/trigger-gitlab-deploy/Jenkinsfile
Selected Git installation does not exist. Using Default
The recommended git tool is: NONE
using credential toto-ci-github
Cloning the remote Git repository
Cloning repository https://github.com/totonow/toto-jenkins.git/
 > git init /var/jenkins_home/workspace/trigger-gitlab-deploy@script/42b7b18e861df0b75ee35873b425e5868cf680207c5d0c9a900960ef6bc6fcb9 # timeout=10
Fetching upstream changes from https://github.com/totonow/toto-jenkins.git/
 > git --version # timeout=10
 > git --version # 'git version 2.30.2'
using GIT_ASKPASS to set credentials Credentials use to pull jenkinsfile from github
 > git fetch --tags --force --progress -- https://github.com/totonow/toto-jenkins.git/ +refs/heads/*:refs/remotes/origin/* # timeout=10
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --tags --force --progress -- https://github.com/totonow/toto-jenkins.git/ +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: detected dubious ownership in repository at '/var/jenkins_home/workspace/trigger-gitlab-deploy@script/42b7b18e861df0b75ee35873b425e5868cf680207c5d0c9a900960ef6bc6fcb9'
To add an exception for this directory, call:

    git config --global --add safe.directory /var/jenkins_home/workspace/trigger-gitlab-deploy@script/42b7b18e861df0b75ee35873b425e5868cf680207c5d0c9a900960ef6bc6fcb9

    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2842)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2185)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:635)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:871)
    at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1222)
    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1305)
    at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:129)
    at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:159)
    at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:70)
    at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:312)
    at hudson.model.ResourceController.execute(ResourceController.java:101)
    at hudson.model.Executor.run(Executor.java:442)
ERROR: Error cloning remote repo 'origin'
ERROR: Maximum checkout retry attempts reached, aborting
Finished: FAILURE

I tried the option git config --global --add safe.directory '*' but I still have a 128 error.

The strange part is, when I connect to the container in ecs (using ecs exec) and when i tried to clone the repository, in the workspace directory of the container, it works.

So that’s not a network issue.

I noticed that when I run a pipeline from Jenkins, it create in the workspace directory of the jenkins master a directory, with the name of the jenkins jobstrigger-gitlab-deploy@script (the name is "trigger-gitlab-deploy" in jenkins).

With inside another directory (probably an ID ?) 42b7b18e861df0b75ee35873b425e5868cf680207c5d0c9a900960ef6bc6fcb9, where there is inside a .git folder, but where the "config" file is not configured.

So it seems that Jenkins tried to clone the repository but failed, however I don’t know why because git clone commands works directly from the container with the same credentials.

Is somebody has an idea of what could be the issue ?
I tried to update the log level of jenkins but it didnt help me.

I already set up this kind of jenkins with on demand agents but it was on a kubernetes cluster and it was working ..