Git 푸시 오류 : 저장소 데이터베이스에 개체를 추가 할 권한이 없습니다.

Git 푸시 오류 : 저장소 데이터베이스에 개체를 추가 할 권한이 없습니다.

---

공유 git 원격으로 푸시하려고하면 다음 오류가 발생합니다. insufficient permission for adding an object to repository database

그런 다음 여기에서 수정 사항에 대해 읽었습니다. Fix This는 모든 파일이 올바른 그룹이기 때문에 다음 푸시에서 작동했지만 다음에 누군가 변경 사항을 푸시하면 기본 그룹이있는 개체 폴더에 새 항목이 만들어졌습니다. 그룹으로. 내가 생각할 수있는 유일한 것은 그들이 체크인하는 항목에 대한 모든 개발자의 기본 그룹을 변경하는 것이지만 그것은 해킹처럼 보입니다. 어떤 아이디어? 감사.

---

권한 복구

근본 원인을 확인하고 수정 한 후 (아래 참조) 권한을 복구해야합니다.

cd /path/to/repo.git
sudo chgrp -R groupname .
sudo chmod -R g+rwX .
find . -type d -exec chmod g+s '{}' +

모든 사람이 저장소를 수정할 수 있도록하려면이 필요하지 않으며 chgrpchmod를 다음과 같이 변경해야합니다.sudo chmod -R a+rwX .

근본 원인을 수정하지 않으면 오류가 계속 발생하고 위의 명령을 계속해서 다시 실행해야합니다.

근본적인 원인

오류는 다음 중 하나로 인해 발생할 수 있습니다.

• 저장소는 (참조 공유 저장소로 구성되지 core.sharedRepository에서 git help config). 출력 :

  git config core.sharedRepository
  

  되지 group또는 true또는 1또는 일부 마스크, 실행 해보십시오 :

  git config core.sharedRepository group
  

  다음 재귀를 다시 실행 chmod하고 chgrp(위의 "복구 권한"참조).

• 운영 체제는 디렉토리의 setgid 비트를 "모든 새 파일 및 하위 디렉토리가 그룹 소유자를 상속해야 함"으로 해석하지 않습니다.

  때 core.sharedRepository이다 true또는 group, 힘내 새로 생성 된 하위 디렉토리가 올바른 그룹 (저장소의 모든 사용자에 있다는 그룹)가 소유하고 있는지 확인하기 위해 GNU 운영 체제의 기능 (예를 들어, 모든 리눅스 배포판)에 의존한다. 이 기능은 GNU coreutils 문서에 설명되어 있습니다 .

  ... [If] 디렉토리의 set-group-ID 비트가 설정되면 새로 생성 된 서브 파일은 디렉토리와 동일한 그룹을 상속하고 새로 생성 된 서브 디렉토리는 상위 디렉토리의 set-group-ID 비트를 상속합니다. ... [이 메커니즘을 통해] 사용자 는 새 파일 을 사용 chmod하거나 chown공유 할 필요성을 줄여 파일을 더 쉽게 공유 할 수 있습니다.

  그러나 모든 운영 체제에이 기능이있는 것은 아닙니다 (NetBSD가 한 예입니다). 이러한 운영 체제의 경우 모든 Git 사용자가 동일한 기본 그룹을 가지고 있는지 확인해야합니다. 또는 실행하여 리포지토리를 모든 사람이 쓸 수 있도록 만들 수 있습니다 git config core.sharedRepository world(하지만주의해야합니다. 보안 수준이 낮습니다).

• 파일 시스템은 setgid 비트 (예 : FAT)를 지원하지 않습니다. ext2, ext3, ext4는 모두 setgid 비트를 지원합니다. 내가 아는 한, setgid 비트를 지원하지 않는 파일 시스템은 그룹 소유권의 개념도 지원하지 않으므로 모든 파일과 디렉토리는 어쨌든 동일한 그룹 (어떤 그룹이 마운트 옵션 임)에 의해 소유 될 것입니다. 이 경우 모든 Git 사용자가 파일 시스템의 모든 파일을 소유 한 그룹에 있는지 확인하십시오.
• 모든 Git 사용자가 저장소 디렉토리를 소유하는 동일한 그룹에있는 것은 아닙니다. 디렉토리의 그룹 소유자가 올 바르고 모든 사용자가 해당 그룹에 있는지 확인하십시오.

---

Ubuntu (또는 모든 Linux)

프로젝트 루트에서

cd .git/objects
ls -al
sudo chown -R yourname:yourgroup *

ls -al 명령의 출력 대부분에 대한 권한을 살펴보면 yourname과 yourgroup이 무엇인지 알 수 있습니다.

참고 : sudo 줄 끝에있는 별을 기억하십시오.

---

sudo chmod -R ug+w .;

기본적으로 .git/objects파일에는 쓰기 권한이 없습니다. 위 줄은 디렉토리의 모든 파일과 폴더에 대한 권한을 부여합니다.

---

다음 명령을 사용하여 마술처럼 작동합니다.

sudo chown -R "${USER:-$(id -un)}" .

명령을있는 그대로 입력하십시오 (추가 공백과 끝에 점 하나 포함).

---

I just wanted to add my solution. I had a repo on OS X that had ownership of root on some directories and Home (which is my user directory) on others which caused the same error listed above.

The solution was simple thankfully. From terminal:

sudo chown -R Home projectdirectory

---

A good way to debug this is the next time it happens, SSH into the remote repo, cd into the objects folder and do an ls -al.

If you see 2-3 files with different user:group ownership than this is the problem.

It's happened to me in the past with some legacy scripts access our git repo and usually means a different (unix) user pushed / modified files last and your user doesn't have permissions to overwrite those files. You should create a shared git group that all git-enabled users are in and then recursively chgrp the objects folder and it's contents so that it's group ownership is the shared git group.

You should also add a sticky bit on the folder so that all the files created in the folder will always have the group of git.

chmod g+s directory-name

Update: I didn't know about core.sharedRepository. Good to know, though it probably just does the above.

---

Solved for me... just this:

sudo chmod 777 -R .git/objects

---

This can easily happen if you ran git init with a different user from the one you are planning to use when pushing changes.

If you blindly follow the instructions on [1] this will happen as you probably created the git-user as root and then immediately moved on to git init without changing user in between.

[1] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server

---

Linux, macOS:

cd .git/
sudo chown -R name:group *

where name is your username and group is the group that your username belongs to.

---

After you add some stuff... commit them and after all finished push it! BANG!! Start all problems... As you should notice there are some differences in the way both new and existent projects were defined. If some other person tries to add/commit/push same files, or content (git keep both as same objects), we will face the following error:

$ git push
Counting objects: 31, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (17/17), done.
Writing objects: 100% (21/21), 2.07 KiB | 0 bytes/s, done.
Total 21 (delta 12), reused 0 (delta 0)
remote: error: insufficient permission for adding an object to repository database ./objects  remote: fatal: failed to write object

To solve this problem you have to have something in mind operational system's permissions system as you are restricted by it in this case. Tu understand better the problem, go ahead and check your git object's folder (.git/objects). You will probably see something like that:

<your user_name>@<the machine name> objects]$ ls -la
total 200
drwxr-xr-x 25 <your user_name> <group_name> 2048 Feb 10 09:28 .
drwxr-xr-x  3 <his user_name> <group_name> 1024 Feb  3 15:06 ..
drwxr-xr-x  2 <his user_name> <group_name> 1024 Jan 31 13:39 02
drwxr-xr-x  2 <his user_name> <group_name> 1024 Feb  3 13:24 08

*Note that those file's permissions were granted only for your users, no one will never can changed it... *

Level       u   g   o
Permission rwx r-x ---
Binary     111 101 000
Octal       7   5   0

SOLVING THE PROBLEM

If you have super user permission, you can go forward and change all permissions by yourself using the step two, in any-other case you will need to ask all users with objects created with their users, use the following command to know who they are:

$ ls -la | awk '{print $3}' | sort -u 
<your user_name>
<his user_name>

Now you and all file's owner users will have to change those files permission, doing:

$ chmod -R 774 .

After that you will need to add a new property that is equivalent to --shared=group done for the new repository, according to the documentation, this make the repository group-writable, do it executing:

$ git config core.sharedRepository group

https://coderwall.com/p/8b3ksg

---

For my case none of the suggestions worked. I'm on Windows and this worked for me:

• Copy the remote repo into another folder
• Share the folder and give appropriate permissions.
• Make sure you can access the folder from your local machine.
• Add this repo as another remote repo in your local repo. (git remote add foo //SERVERNAME/path/to/copied/git)
• Push to foo. git push foo master. Did it worked? Great! Now delete not-working repo and rename this into whatever it was before. Make sure permissions and share property remains the same.

---

I hit this same issue. Reading around here I realised it was file permissions the message was referring to. The fix , for me, was in:

/etc/inetd.d/git-gpv

It was starting git-daemon as user 'nobody' so lacked the write permission.

# Who   When    What
# GPV   20Nov13 Created this by hand while reading: http://linuxclues.blogspot.co.uk/2013/06>/git-daemon-ssh-create-repository-debian.html
# GPV   20Nov13 Changed owner (to user_git) otherise nobody lack permission to update the repository
#git stream tcp nowait nobody  /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo
git stream tcp nowait user_git  /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo

(I doubt other call their inetd conf file git-gpv . Commonly it would be directly in /etc/inetd.conf)

---

You need the sufficient write permissions on the directory that you are pushing to.

In my case: Windows 2008 server

right click on git repo directory or parent directory.

Properties > Sharing tab > Advanced Sharing > Permissions > make sure the user has appropriate access rights.

---

You may have accidentally nested git repositories

---

There is a possibility also that you added another local repository with the same alias. As an example, you now have 2 local folders referred to as origin so when you try to push, the remote repository will not accept you credentials.

Rename the local repository aliases, you can follow this link https://stackoverflow.com/a/26651835/2270348

Maybe you can leave 1 local repository of your liking as origin and the others rename them for example from origin to anotherorigin. Remember these are just aliases and all you need to do is remember the new aliases and their respective remote branches.

---

Works for me

sudo chmod -R g+rwX .

---

I got this when pulling into an Rstudio project. I realised I forgot to do:

sudo rstudio

on program startup. In fact as there's another bug I've got, I need to actually do:

sudo rstudio --no-sandbox

---

Use sudo for commit -m

• git add -A
• sudo git commit -m "Use sudo for commit -m"
• git push origin branch_name

참고URL : https://stackoverflow.com/questions/6448242/git-push-error-insufficient-permission-for-adding-an-object-to-repository-datab