Diagnosing a git error -- fatal: adding files failed

user_7681106 0
Viewed 72
xxxxx@LAPTOP-xxxxxxxx /somepath/xxxxxxxxxx$ git status                                                                                 
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   .devcontainer/Dockerfile
        modified:   xxxxxxxxxxxxxxxxxxxxxxxxxxx/xxxxxxxxxxx.py
        renamed:    testing/Full_Attempt_1_without_Preqs_no_oop.py -> full_scripts/Full_Attempt_1_without_Preqs_no_oop.py
        deleted:    tester_1.py
        deleted:    testing/Full_Attempt_2_with_Preqs_no_oop.py
        new file:   unit_tests/xxxxxxxxxxxxxx.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        full_scripts/Full_Attempt_2_with_Preqs_no_oop.py
        full_scripts/tester_1.py
        test_preq_loader.py

Please nevermind the names of things, but this is pretty much what you see after running git status. When I try to add the missing files with git add ., this is what I get:

error: insufficient permission for adding an object to repository database .git/objects
error: full_scripts/Full_Attempt_2_with_Preqs_no_oop.py: failed to insert into database
error: unable to index file 'full_scripts/Full_Attempt_2_with_Preqs_no_oop.py'
fatal: adding files failed

Which error should I prioritize? Are these errors related? In other examples online there is some explanation of the "unable to index file" error, but I have no insight why I can't index the file.

Also, git commit and git push don't work, but I figured git add is the first one to address.

I'm still learning how git works, but is there something I can change in the objects directory? Inside of the commit/tree/blob DAG?

I'm getting tempted to just copypaste my project into a new git project, but would prefer to keep the project history, and also learn about git, what I can do to fix this, and what went wrong in the first place.

Thanks for any and all feedback/advice.

Response to comments for more information:

  • The permissions for .git: drwxrwxrwx
  • All subdirectories are either: drwxr-xr-x or drwxrwxrwx
  • I'm using WSL2 on windows 10

After reading @torek's answer I wanted to check ownership of objects in the .git/objects folder. When I run ls -l in the .git/objects directory, some of the "xx" directories are owned by me, with permissions 777, and some of the "xx" directories are owned by root, with permissions 755.

When I look into the directories owned by me, some or all of the hashed files will be owned by me with 777 permissions, and maybe some owned by root, with 444 permissions. When I look into the directories owned by root, all of the hashed files are owned by root with 444 permissions.

Final update (maybe): I think I need to change ownership from root to myself for all directories and folders. I also need to change permissions of all xx directories from 755 to 777, and blob/tree/commit hashfiles from 444 to 777. Running (from .git/objects)

sudo chmod -R 777 .

doesn't work to change anything. Also, running (from .git/objects)

sudo chown -R isaac:isaac .

doesn't change anything either. I suppose this is a different issue, so I closed the question. But that's where I'm currently stuck.

git
2 Answers

The problem is permissions of git files. You might did some operations with root or different user on repository. You may follow this instructions;

  • Detect your current user with : Type whoami hit the enter, the result is our current user.
  • Change ownership of repository to current user, go to repository on terminal and; sudo chown user:user -R .
  • Try to add files again it would be succeed but if it does not work then you should also fix the file mode with; sudo chmod 644 -R .
user_106443430

The error message:

error: insufficient permission for adding an object
to repository database .git/objects

is close, but is potentially missing a few extra details. Git's object store (a simple key-value database) is currently implemented as a directory (or folder, if you prefer that term) named .git/objects that contains numerous subdirectories (subfolders). Each directory must allow writes by the current user and/or group, with permissions being determined and managed by the operating system (not by Git itself, except as described below).

On a Unix or Linux like system (as you appear to be), permissions to read and write individual files are controlled by the file's permissions, while permissions to create new files or delete existing files (or create and/or delete subdirectories) are controlled by both the execute and write permissions bits of the various directories.1

Git will try to create new directories named .git/objects/xx where the xx represents any two hexadecimal digits if and when Git needs to add an object whose hash ID begins with those two digits. It will then try to create a new file in that directory where the file's name is the remainder of the hash ID (i.e., after stripping off the first two hexadecimal digits).

Besides the xx directories, there's a directory named pack that will be created as soon as there are any pack files (these contain packed objects, while the two-hex-digit directories contain loose objects; the difference is that the packed objects are more-compressed, and also try to work around bad performance of file systems with many loose objects). The pack directory and files within it behave the same way as the loose object directories.

When creating a new directory, Git calls the OS's mkdir with permissions 0777. Your umask, which will generally be either 002 or 022, will clear the write permission for others (result 0775) or group-and-others (result 0755) respectively. Git uses the core.sharedDirectory setting, if it exists, to set its umask relatively early on, in case you need these to be group-writable: this is normally only the case for a shared repository. Setting core.sharedRepository to true or group causes all of these to be group-writable.

Because you appear to be using Docker (modified: .devcontainer/Dockerfile) and Docker can result in UID and/or GID mapping, you might need shared-repository mode, even if you're working alone, and even that might not suffice. See appropriate Docker documentation to find out whether you're doing ID mapping and if so what you might need to do about that.

Otherwise—if you're not trying to share the .git repository across a docker mount or if you're doing this in such a way that ID mapping is irrelevant—just make sure you have not incorrectly set up the existing directories within .git/objects. In general, they should be:

  • files: mode 0444; Git writes such files once, and then does not change them, so they're deliberately read-only
  • directories: mode 0755 or mode 0775 depending on core.sharedRepository

You can set them to mode 0777, and set core.sharedRepository to world or all or everybody, if you have both UID and GID mapping going on in such a way that this is necessary.

Use chown and/or chmod recursively as shown in Yigit Yasar's answer but with the correct options to adjust the ownership and/or permissions of files. Note that you want:

chown -R user:group

(not group:user) if you need to change these, and:

chmod -R g=u

(or chmod -R go-u) to add group (or group and other) write and/or execute permissions to match the user permissions if you need group and/or world writable settings. In general, don't make the permissions any looser than necessary—this isn't because Git will break, but just a matter of general "permissions hygiene" where we don't want our systems to be too easy to attack.

1Specifically, write permission on a directory implies that you can create or delete a name within that directory. Execute permssion on a directory implies that you can use that directory to look up files. Read permission just means you can see what files are in it—you can still use the files if you know their names, even if you can't read it, as long as you can "execute" the directory. (However, some network file systems require both read and execute permissions.)

user_12564520
Related