힘내 푸시 오류 : 저장소 데이터베이스에 개체를 추가 할 수있는 권한이 없습니다

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

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

수리 권한

근본적인 원인을 식별하고 수정 한 후 (아래 참조) 권한을 복구하려고합니다.

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 문서에 설명되어 있습니다 .

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

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

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

우분투 (또는 리눅스)

프로젝트 루트에서

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

ls -al 명령의 출력 대부분에 대한 권한을 확인하여 사용자 이름과 그룹이 무엇인지 알 수 있습니다.

참고 : sudo 줄 끝의 별을 기억하십시오

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

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

명령을 그대로 입력하십시오 (추가 공백과 끝에 하나의 점이 있음)

sudo chmod -R ug+w .;

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

방금 솔루션을 추가하고 싶었습니다. OS X에서 일부 디렉토리의 루트 소유권과 다른 사용자의 홈 디렉토리 (내 사용자 디렉토리)가 위에 나열된 동일한 오류를 일으킨 리포지토리를 가졌습니다.

해결책은 고맙게도 간단했습니다. 터미널에서 :

sudo chown -R Home projectdirectory

이것을 디버깅하는 좋은 방법은 다음에 발생할 때 원격 저장소에 SSH를 넣고 객체 폴더로 cd 한 다음을 수행하는 것 ls -al입니다.

다른 user : group 소유권을 가진 2-3 개의 파일이 표시되면 이것이 문제입니다.

과거에는 일부 레거시 스크립트가 git repo에 액세스하여 일반적으로 발생했으며 일반적으로 다른 (유닉스) 사용자가 마지막으로 푸시 / 수정 된 파일을 의미하며 사용자는 해당 파일을 덮어 쓸 수있는 권한이 없습니다. 모든 자식 사용이 가능한 사용자가에있는 다음 재귀 것을 당신은 공유 자식 그룹을 만들어야 폴더와이 폴더의 내용이 그래서 그것의 그룹 소유권이 공유되는 그룹.chgrpobjectsgit

또한 폴더에 스티키 비트를 추가하여 폴더에서 작성된 모든 파일이 항상의 그룹을 갖도록해야합니다 git.

chmod g + s 디렉토리 이름

업데이트 : core.sharedRepository에 대해 몰랐습니다. 알아두면 좋을 것입니다.

나를 위해 해결 ... 단지 이것 :

sudo chmod 777 -R .git/objects

git init변경 사항을 푸시 할 때 사용하려는 사용자가 아닌 다른 사용자와 함께 실행 한 경우 쉽게 발생할 수 있습니다 .

[1]의 지침을 맹목적으로 따르면 git-user를 루트로 만든 다음 사용자를 변경하지 않고 즉시 git init로 옮길 수 있습니다.

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

리눅스, macOS :

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

여기서 name귀하의 사용자 이름은 귀하의 사용자 group이름이 속한 그룹입니다.

당신이 몇 가지 물건을 추가 한 후 ... 그들을 저지른 후 그것을 모두 밀어! 쾅!! 모든 문제를 시작하십시오 ... 새 프로젝트와 기존 프로젝트가 정의 된 방식에 약간의 차이가 있습니다. 다른 사람이 동일한 파일 또는 내용을 추가 / 커밋 / 푸시하려고하면 (git은 둘 다 동일한 객체로 유지) 다음 오류가 발생합니다.

$ 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

이 문제를 해결하려면이 경우 제한되는 운영 체제 권한 시스템을 염두에 두어야합니다. 문제를 더 잘 이해하고 git 객체의 폴더 (.git / objects)를 확인하십시오. 아마도 다음과 같은 것을 보게 될 것입니다.

<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

*이 파일의 사용 권한은 사용자에게만 부여되었으며 아무도 변경할 수 없습니다 ... *

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

문제 해결

수퍼 유저 권한이있는 경우 2 단계를 사용하여 직접 모든 권한을 변경하고 변경할 수 있습니다. 다른 경우에는 모든 사용자에게 사용자로 작성된 오브젝트를 요청해야합니다. 다음 명령을 사용하여 자신이 누구인지 확인하십시오. :

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

이제 귀하와 모든 파일 소유자는 다음을 수행하여 해당 파일 권한을 변경해야합니다.

$ chmod -R 774 .

그런 다음 문서에 따라 새 리포지토리에 대해 --shared = group done과 동일한 새 속성을 추가해야합니다.

$ git config core.sharedRepository group

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

내 경우에는 제안이 효과가 없었습니다. 나는 Windows에 있고 이것은 나를 위해 일했다 :

• 원격 저장소를 다른 폴더로 복사
• 폴더를 공유하고 적절한 권한을 부여하십시오.
• 로컬 컴퓨터에서 폴더에 액세스 할 수 있는지 확인하십시오.
• 이 리포지를 로컬 리포지토리의 다른 원격 리포지토리로 추가하십시오. ( git remote add foo //SERVERNAME/path/to/copied/git)
• foo로 밀어 넣습니다. git push foo master. 효과가 있었습니까? 큰! 이제 작동하지 않는 저장소를 삭제하고 이전 이름으로 바꾸십시오. 권한과 공유 속성이 동일하게 유지되도록하십시오.

나는이 같은 문제에 부딪쳤다. 여기를 읽으면서 메시지가 참조하는 파일 권한이라는 것을 알았습니다. 나에게 대한 해결책은 다음과 같습니다.

/etc/inetd.d/git-gpv

사용자 ' nobody ' 로서 git-daemon을 시작 했기 때문에 쓰기 권한이 없습니다.

# 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

(다른 사람들은 inetd conf 파일 git-gpv라고 의심합니다. 일반적으로 /etc/inetd.conf에 있습니다.)

푸시하려는 디렉토리에 대한 충분한 쓰기 권한이 필요합니다.

제 경우에는 : Windows 2008 server

git repo 디렉토리 또는 부모 디렉토리를 마우스 오른쪽 버튼으로 클릭하십시오.

속성> 공유 탭> 고급 공유> 권한> 사용자에게 적절한 액세스 권한이 있는지 확인하십시오.

실수로 자식 저장소를 중첩 했을 수 있습니다.

동일한 별명으로 다른 로컬 저장소를 추가했을 수도 있습니다. 예를 들어, 이제 origin푸시하려고 할 때 2 개의 로컬 폴더가 참조 되므로 원격 저장소는 신임 정보를 승인하지 않습니다.

로컬 저장소 별명을 바꾸면이 링크를 따라갈 수 있습니다 https://stackoverflow.com/a/26651835/2270348

어쩌면 원하는대로 1 개의 로컬 리포지토리를 남겨 둘 수 origin있고 다른 것은 이름을에서 origin로 변경 할 수 anotherorigin있습니다. 이들은 별칭 일 뿐이며 새 별칭과 해당 원격 브랜치를 기억하기 만하면됩니다.

나를 위해 작동

sudo chmod -R g+rwX .

Rstudio 프로젝트를 가져올 때 이것을 얻었습니다. 나는 내가 잊었다는 것을 깨달았다.

sudo rstudio

프로그램 시작시. 실제로 내가 가지고있는 또 다른 버그가 있으므로 실제로해야합니다.

sudo rstudio --no-sandbox

commit -m에 sudo 사용

• 자식 추가 -A
• sudo git commit -m "커밋에 sudo 사용 -m"
• 자식 푸시 원점 branch_name

Samba 공유의 원격 저장소 에서이 문제가 발생했습니다. 이 리모컨에서 성공적으로 잡아 당겼지만 밀어 넣을 때 실패했습니다.

오류의 원인은 내 ~/.smbcredentials파일의 자격 증명이 잘못되었습니다 .