Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. N8N
  3. "fatal: not a git repository"

"fatal: not a git repository"

Scheduled Pinned Locked Moved Solved N8N
4 Posts 3 Posters 709 Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • rosanoR Offline
    rosanoR Offline
    rosano
    wrote on last edited by
    #1

    I have been pulling an external git repository via n8n into the container's /tmp folder and have pushed changes successfully via an active workflow. At some point the workflow fails because of a fatal: not a git repository error and I'm not sure why this happens.

    When navigating to the .git folder via the container's web terminal in Cloudron, the data inside looks like this:

    total 104
    drwxr-xr-x  8 cloudron cloudron  4096 May 14 12:00 .
    drwxr-xr-x  7 cloudron cloudron  4096 May 14 12:00 ..
    -rw-r--r--  1 cloudron cloudron     5 May 14 07:08 COMMIT_EDITMSG
    -rw-r--r--  1 cloudron cloudron    92 May 14 07:08 FETCH_HEAD
    -rw-r--r--  1 cloudron cloudron    41 May 14 07:08 ORIG_HEAD
    drwxr-xr-x  2 cloudron cloudron  4096 May  3 10:17 branches
    -rw-r--r--  1 cloudron cloudron   333 May 14 07:08 config
    drwxr-xr-x  2 cloudron cloudron  4096 May 14 12:00 hooks
    -rw-r--r--  1 cloudron cloudron 56770 May 14 07:08 index
    drwxr-xr-x  2 cloudron cloudron  4096 May 14 12:00 info
    drwxr-xr-x  3 cloudron cloudron  4096 May  3 10:18 logs
    drwxr-xr-x 52 cloudron cloudron  4096 May 14 07:08 objects
    drwxr-xr-x  5 cloudron cloudron  4096 May  3 10:18 refs
    

    When cloning/pulling the repo fresh to a new folder, it looks slightly different but I'm not sure what would make it behave differently.

    total 116
    drwxr-xr-x  8 cloudron cloudron  4096 May 19 07:10 .
    drwxr-xr-x  7 cloudron cloudron  4096 May 19 07:10 ..
    -rw-r--r--  1 cloudron cloudron     5 May 19 07:10 COMMIT_EDITMSG
    -rw-r--r--  1 cloudron cloudron    92 May 19 07:10 FETCH_HEAD
    -rw-r--r--  1 cloudron cloudron    23 May 19 07:10 HEAD
    -rw-r--r--  1 cloudron cloudron    41 May 19 07:10 ORIG_HEAD
    drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 branches
    -rw-r--r--  1 cloudron cloudron   333 May 19 07:10 config
    -rw-r--r--  1 cloudron cloudron    73 May 19 07:10 description
    drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 hooks
    -rw-r--r--  1 cloudron cloudron 57218 May 19 07:10 index
    drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 info
    drwxr-xr-x  3 cloudron cloudron  4096 May 19 07:10 logs
    drwxr-xr-x 14 cloudron cloudron  4096 May 19 07:10 objects
    -rw-r--r--  1 cloudron cloudron   114 May 19 07:10 packed-refs
    drwxr-xr-x  5 cloudron cloudron  4096 May 19 07:10 refs
    

    I found one answer suggesting to copy .git/ORIG_HEAD to .git/HEAD in the broken repo, but that didn't change anything and creates another fatal: detected dubious ownership in repository at XXXXX error.

    As it functions for weeks and then suddenly stops, I wonder if it's not an n8n issue and something that happens at the Cloudron or OS level. If there are any guesses about that I would appreciate it.

    For now I just manually delete the folder and pull again, but this defeats the purpose of using an automation system; I can also delete as part of the workflow, but wanted to avoid pulling a large amount of data everytime.

    girishG 1 Reply Last reply
    0
    • nebulonN Offline
      nebulonN Offline
      nebulon
      Staff
      wrote on last edited by
      #2

      Relying on /tmp folder as persistent data is generally not a good idea. Tmp storage cleanup script might run at any time as well as if app containers are recreated the tmpfs volume is not guaranteed to stay around.

      Have you tried to use a subfolder in /app/data/ for this? This is where data is kept persistently in Cloudron.

      rosanoR 1 Reply Last reply
      0
      • nebulonN nebulon marked this topic as a question on
      • rosanoR rosano

        I have been pulling an external git repository via n8n into the container's /tmp folder and have pushed changes successfully via an active workflow. At some point the workflow fails because of a fatal: not a git repository error and I'm not sure why this happens.

        When navigating to the .git folder via the container's web terminal in Cloudron, the data inside looks like this:

        total 104
        drwxr-xr-x  8 cloudron cloudron  4096 May 14 12:00 .
        drwxr-xr-x  7 cloudron cloudron  4096 May 14 12:00 ..
        -rw-r--r--  1 cloudron cloudron     5 May 14 07:08 COMMIT_EDITMSG
        -rw-r--r--  1 cloudron cloudron    92 May 14 07:08 FETCH_HEAD
        -rw-r--r--  1 cloudron cloudron    41 May 14 07:08 ORIG_HEAD
        drwxr-xr-x  2 cloudron cloudron  4096 May  3 10:17 branches
        -rw-r--r--  1 cloudron cloudron   333 May 14 07:08 config
        drwxr-xr-x  2 cloudron cloudron  4096 May 14 12:00 hooks
        -rw-r--r--  1 cloudron cloudron 56770 May 14 07:08 index
        drwxr-xr-x  2 cloudron cloudron  4096 May 14 12:00 info
        drwxr-xr-x  3 cloudron cloudron  4096 May  3 10:18 logs
        drwxr-xr-x 52 cloudron cloudron  4096 May 14 07:08 objects
        drwxr-xr-x  5 cloudron cloudron  4096 May  3 10:18 refs
        

        When cloning/pulling the repo fresh to a new folder, it looks slightly different but I'm not sure what would make it behave differently.

        total 116
        drwxr-xr-x  8 cloudron cloudron  4096 May 19 07:10 .
        drwxr-xr-x  7 cloudron cloudron  4096 May 19 07:10 ..
        -rw-r--r--  1 cloudron cloudron     5 May 19 07:10 COMMIT_EDITMSG
        -rw-r--r--  1 cloudron cloudron    92 May 19 07:10 FETCH_HEAD
        -rw-r--r--  1 cloudron cloudron    23 May 19 07:10 HEAD
        -rw-r--r--  1 cloudron cloudron    41 May 19 07:10 ORIG_HEAD
        drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 branches
        -rw-r--r--  1 cloudron cloudron   333 May 19 07:10 config
        -rw-r--r--  1 cloudron cloudron    73 May 19 07:10 description
        drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 hooks
        -rw-r--r--  1 cloudron cloudron 57218 May 19 07:10 index
        drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 info
        drwxr-xr-x  3 cloudron cloudron  4096 May 19 07:10 logs
        drwxr-xr-x 14 cloudron cloudron  4096 May 19 07:10 objects
        -rw-r--r--  1 cloudron cloudron   114 May 19 07:10 packed-refs
        drwxr-xr-x  5 cloudron cloudron  4096 May 19 07:10 refs
        

        I found one answer suggesting to copy .git/ORIG_HEAD to .git/HEAD in the broken repo, but that didn't change anything and creates another fatal: detected dubious ownership in repository at XXXXX error.

        As it functions for weeks and then suddenly stops, I wonder if it's not an n8n issue and something that happens at the Cloudron or OS level. If there are any guesses about that I would appreciate it.

        For now I just manually delete the folder and pull again, but this defeats the purpose of using an automation system; I can also delete as part of the workflow, but wanted to avoid pulling a large amount of data everytime.

        girishG Offline
        girishG Offline
        girish
        Staff
        wrote on last edited by
        #3

        @rosano said in "fatal: not a git repository":

        At some point the workflow fails because of a fatal: not a git repository error and I'm not sure why this happens.

        The HEAD file in git can never go missing. It could be that a previous workflow or command just crashed midway for some reason. I think you have to check the git/workflow logs to figure what's going on. But the core issue is that HEAD file should never disappear in a git repo .

        1 Reply Last reply
        1
        • nebulonN nebulon

          Relying on /tmp folder as persistent data is generally not a good idea. Tmp storage cleanup script might run at any time as well as if app containers are recreated the tmpfs volume is not guaranteed to stay around.

          Have you tried to use a subfolder in /app/data/ for this? This is where data is kept persistently in Cloudron.

          rosanoR Offline
          rosanoR Offline
          rosano
          wrote on last edited by
          #4

          @nebulon said in "fatal: not a git repository":

          Have you tried to use a subfolder in /app/data/ for this? This is where data is kept persistently in Cloudron.

          Been using this folder and seems like it has had no issues for a week or two now 👍🏽 thanks for clarifying 🙏🏽

          1 Reply Last reply
          1
          • rosanoR rosano has marked this topic as solved on
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Bookmarks
          • Search