atlantis icon indicating copy to clipboard operation
atlantis copied to clipboard

Atlantis apply fails because of git dubious ownership

Open BenoitLF opened this issue 1 year ago • 14 comments

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Overview of the Issue

Atlantis plan works but the apply does not because of a git error (similar to : this issue)

Logs

running git ls-files . --others: fatal: detected dubious ownership in repository at '/home/atlantis/.atlantis/repos/org/repo-name/10/default'
To add an exception for this directory, call:

	git config --global --add safe.directory /home/atlantis/.atlantis/repos/org/repo-name/10/default
: exit status 128
--->

Environment details

  • Atlantis version: latest
  • Deployment method: ecs, terraform-atlantis module

BenoitLF avatar Feb 16 '23 09:02 BenoitLF

Was able to fix the issue like this comment

BenoitLF avatar Feb 16 '23 10:02 BenoitLF

Thanks @BenoitLF. This would be nice to add to our troubleshooting page. We welcome PRs if you have the time

nitrocode avatar Feb 16 '23 15:02 nitrocode

@nitrocode and @BenoitLF for me it's not working, why enable_ephemeral_storage = true?

jiba21 avatar Mar 31 '23 10:03 jiba21

image

jiba21 avatar Mar 31 '23 10:03 jiba21

enable_ephemeral_storage does not work ?

BenoitLF avatar Mar 31 '23 11:03 BenoitLF

@BenoitLF
If enable_ephemeral_storage == true, the EFS config is disabled as you could see in the image: count = true = 0

I use that config

resource "aws_efs_access_point" "this" {
  file_system_id = local.file_system

  root_directory {
    path = "/${var.application}/${var.environment}"
    creation_info {
      owner_gid   = local.gid (1000)
      owner_uid   = local.uid (100)
      permissions = 0750
    }
  }

  posix_user {
    gid = local.gid (1000)
    uid = local.uid (100)
  }
}

But is failing with: detected dubious ownership in repository

jiba21 avatar Mar 31 '23 14:03 jiba21

This has broke our Atlantis as well.

We do not use access points, we provision EFS, and then allow the EFS csi to do the provisioning.

We are failing to download modules

jseiser avatar Apr 17 '23 15:04 jseiser

Perhaps this command needs to be running Atlantis on a new pr or in a pre workflow hook?

git config --global --add safe.directory '*'

https://stackoverflow.com/questions/72978485/git-submodule-update-failed-with-fatal-detected-dubious-ownership-in-repositor

nitrocode avatar Apr 18 '23 13:04 nitrocode

OK, i actually figured out whats going on, but im not sure why it just now started failed.

We have atlantis in 2 clusters, handling deployments for like 20+ repos. So both are heavily used and have went through multiple upgrades etc.

We provision EFS using the EFS CSI helm chart. The default setting for your provisioner is to use a random range for the UID/GID for the EFS mount.

So the atlantis helm chart allows you to lock the uid/gid of the user to 1000:1000 ( this matches the debian image before it was broken). But the EFS mount may be owned by say :1008:10008 . I had to re-create a new EFS provisioner just for atlantis, locking the UID/GID to 1000:1000.

The other atlantis deployment is currently working.. and the EFS mount is owned by 1009:1009 so im not sure what needs to happen to trigger it to fail.

jseiser avatar Apr 18 '23 15:04 jseiser

Encountered this issue from today so will try https://github.com/runatlantis/atlantis/issues/3139#issuecomment-1432882110 and it seems to have worked around the issue for now at least

bml1g12 avatar Apr 19 '23 13:04 bml1g12

you can do this too:

repos:
  - id: /.*/
    # allowed_overrides specifies which keys can be overridden by this repo in
    # its atlantis.yaml file.
    allowed_overrides: [apply_requirements, workflow]
    apply_requirements: [approved,mergeable]
    # allow_custom_workflows defines whether this repo can define its own
    # workflows. If false (default), the repo can only use server-side defined
    # workflows.
    allow_custom_workflows: true
    # This hook is to work around https://github.com/runatlantis/atlantis/issues/2221
    pre_workflow_hooks:
      - run: git config --global --add safe.directory '*'

jamengual avatar Apr 21 '23 20:04 jamengual

you can do this too:

repos:
  - id: /.*/
    # allowed_overrides specifies which keys can be overridden by this repo in
    # its atlantis.yaml file.
    allowed_overrides: [apply_requirements, workflow]
    apply_requirements: [approved,mergeable]
    # allow_custom_workflows defines whether this repo can define its own
    # workflows. If false (default), the repo can only use server-side defined
    # workflows.
    allow_custom_workflows: true
    # This hook is to work around https://github.com/runatlantis/atlantis/issues/2221
    pre_workflow_hooks:
      - run: git config --global --add safe.directory '*'

Using this to overcome the issue as I think persistent storage makes sense (maybe I am wrong). A not so nice side effect is that now the hook, that we use as a workaround, will show up on PR status

image

https://github.com/runatlantis/atlantis/issues/3173 would allow getting rid of this if worked on

aalvarezaph avatar May 18 '23 10:05 aalvarezaph

I'm going through it, too. But, my apply worked when with -d option.. I don't know why.. image

cjsrkd3321 avatar Jul 23 '23 10:07 cjsrkd3321

you can do this too:

repos:
  - id: /.*/
    # allowed_overrides specifies which keys can be overridden by this repo in
    # its atlantis.yaml file.
    allowed_overrides: [apply_requirements, workflow]
    apply_requirements: [approved,mergeable]
    # allow_custom_workflows defines whether this repo can define its own
    # workflows. If false (default), the repo can only use server-side defined
    # workflows.
    allow_custom_workflows: true
    # This hook is to work around https://github.com/runatlantis/atlantis/issues/2221
    pre_workflow_hooks:
      - run: git config --global --add safe.directory '*'

Using this to overcome the issue as I think persistent storage makes sense (maybe I am wrong). A not so nice side effect is that now the hook, that we use as a workaround, will show up on PR status

image #3173 would allow getting rid of this if worked on

You can just add description field that looks more appealing ;)

      pre_workflow_hooks:
        - run: |
            git config --global --add safe.directory '*'        
          description: configure-git-credentials

RafPe avatar Feb 06 '24 14:02 RafPe