Gitプッシュエラー：オブジェクトをリポジトリデータベースに追加するための十分な権限がありません

共有のgitリモートにプッシュしようとすると、次のエラーが発生します。 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 '{}' +

すべての人がリポジトリを変更できるようにしたい場合は必要ありません。chmodを次のように変更する必要がchgrpあります。sudo chmod -R a+rwX .

根本的な原因を修正しないと、エラーが再発し、上記のコマンドを何度も繰り返し実行する必要があります。

根本的な原因

エラーは次のいずれかが原因である可能性があります。

• リポジトリは共有リポジトリ（参照可能に構成されていませんcore.sharedRepositoryでgit help config）。出力の場合：

  git config core.sharedRepository
  

  でない、groupまたはtrue、1または何らかのマスクです。実行してみてください：

  git config core.sharedRepository group
  

  次に、再帰的chmodandを再実行しますchgrp（上記の「権限の修復」を参照）。

• オペレーティングシステムは、ディレクトリのsetgidビットを「すべての新しいファイルとサブディレクトリがグループオーナーを継承する必要がある」と解釈しません。

  ときcore.sharedRepositoryであるtrueかgroup、Gitは新たに作成されたサブディレクトリが正しいグループ（リポジトリのユーザーのすべてがであることをグループ）が所有していることを確認するために、GNUオペレーティングシステムの機能（例えば、すべてのLinuxディストリビューション）に依存しています。この機能は、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 chown -R "${USER:-$(id -un)}" .

コマンドをそのまま入力します（余分なスペースと最後に1つのドットを使用）

sudo chmod -R ug+w .;

基本的に、.git/objectsファイルには書き込み権限がありません。上記の行は、ディレクトリ内のすべてのファイルとフォルダーにアクセス許可を付与します。

ソリューションを追加したかっただけです。OS Xで、一部のディレクトリにはrootの所有権があり、他のディレクトリにはホーム（これは私のユーザーディレクトリです）の所有権があるため、上記と同じエラーが発生しました。

解決策はありがたいことにシンプルでした。ターミナルから：

sudo chown -R Home projectdirectory

これをデバッグする良い方法は、次にそれが発生したときに、リモートリポジトリにSSH接続し、オブジェクトフォルダーにcdして、を実行することls -alです。

user：groupの所有権が異なる2〜3個のファイルがある場合は、これが問題です。

以前にいくつかのレガシースクリプトがgitリポジトリにアクセスしていて、通常は別の（unix）ユーザーが最後にファイルをプッシュまたは変更し、ユーザーにそれらのファイルを上書きする権限がないことを意味します。すべてのgit対応ユーザーがいる共有gitグループを作成してからchgrp、objectsフォルダーとそのコンテンツを再帰的に作成し、グループの所有権が共有gitグループになるようにします。

また、フォルダにスティッキービットを追加して、フォルダ内に作成されたすべてのファイルが常にのグループを持つようにする必要がありgitます。

chmod g + sディレクトリ名

更新：core.sharedRepositoryについて知りませんでした。知っておくと便利ですが、おそらく上記のことだけを行います。

私のために解決しました...これだけです：

sudo chmod 777 -R .git/objects

これはgit init、変更をプッシュするときに使用する予定のユーザーとは別のユーザーで実行した場合に簡単に発生します。

[1]の指示を盲目的に実行すると、おそらくgit-userをrootとして作成し、ユーザーを変更せずにすぐにgit initに移動したため、これが発生します。

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

Linux、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

この場合は制限されているため、この問題を解決するには、運用システムのアクセス許可システムを念頭に置く必要があります。Tuは問題をよりよく理解し、先に進み、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と同等の新しいプロパティを追加する必要があります。ドキュメントによると、これにより、リポジトリグループが書き込み可能になり、次のように実行します。

$ 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サーバー

git repoディレクトリまたは親ディレクトリを右クリックします。

[プロパティ]> [共有]タブ> [高度な共有]> [権限]>ユーザーに適切なアクセス権があることを確認します。

誤ってgitリポジトリをネストしている可能性があり ます

同じエイリアスで別のローカルリポジトリを追加した可能性もあります。例として、2つのローカルフォルダーがoriginようになりました。プッシュしようとすると、リモートリポジトリは資格情報を受け入れません。

ローカルリポジトリエイリアスの名前を変更します。このリンクをたどることができます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を使用します

• git add -A
• sudo git commit -m "コミット-mにsudoを使用"
• git push origin branch_name

Samba共有のリモートリポジトリでこの問題が発生しました。このリモートからのプルは成功したが、プッシュすると失敗した。

エラーの原因は、~/.smbcredentialsファイル内の誤った資格情報でした。