GitHub को पुश करने में त्रुटि - रिपॉजिटरी डेटाबेस में ऑब्जेक्ट जोड़ने के लिए अपर्याप्त अनुमति


126

मैं अपने GitHub रिपॉजिटरी में "git पुश" करने की कोशिश करते हुए एक असामान्य त्रुटि वापस पा रहा हूं:

गिनती की वस्तुओं: 8, किया।
2 थ्रेड्स का उपयोग करते हुए डेल्टा संपीड़न।
संपीड़ित वस्तुएं: 100% (4/4), किया।
लेखन वस्तुएं: 100% (5/5), 1.37 KiB, किया।
कुल 5 (डेल्टा 2), पुन: उपयोग किया गया 0 (डेल्टा 0)
त्रुटि: किसी ऑब्जेक्ट को रिपॉजिटरी डेटाबेस में जोड़ने के लिए अपर्याप्त अनुमति ।/objects

घातक: वस्तु लिखने में विफल
त्रुटि: अनपैक-ऑब्जेक्ट्स त्रुटि कोड 128 के साथ बाहर निकल गए
त्रुटि: अनपैक विफल: अनपैक-ऑब्जेक्ट असामान्य निकास
Git@github.com पर: bixo / bixo.git
 ! [दूरस्थ अस्वीकृत] मास्टर -> मास्टर (n / a (अनपेकर त्रुटि))
त्रुटि: कुछ संदर्भों को 'git@github.com: bixo / bixo.git' पर धकेलने में विफल रही
  • GitHub से एक साफ क्लोन के बाद, मैं एक संशोधित फ़ाइल को संपादित / जोड़ / जोड़ / धक्का कर सकता हूं।
  • यदि मैं इसे दूसरी बार दोहराता हूं तो मुझे उपरोक्त त्रुटि मिलती है।
  • मैं अन्य GitHub रिपॉजिटरी को ठीक कर सकता हूं।
  • मैंने अपनी ओर से फ़ाइल / निर्देशिका अनुमतियों की जाँच की है, और वे ठीक लगते हैं।
  • मैं Mac OS X 10.5.8 पर git 1.6.2.3 चला रहा हूं

उपरोक्त भंडार पिछले स्टैक ओवरफ्लो प्रश्न ( SO 1904860 ) के लिए मेरे मज़े का स्रोत था , इसलिए शायद GitHub रेपो भ्रष्ट हो गया। केवल इसी तरह की समस्या जिसे मैंने खोज के माध्यम से पाया है, जीथब पर रिपोर्ट की गई एक अनपैक विफल समस्या थी। किसी और को पहले इस मुद्दे में चला गया है, खासकर जब GitHub का उपयोग नहीं ?



1
इस त्रुटि वाले लोगों के लिए एक और संकेत: मुझे यह त्रुटि मिली क्योंकि मैं गलत उपयोगकर्ता को धक्का देने के लिए उपयोग कर रहा था। मेरे सर्वर में उपयोगकर्ता fooऔर हैं git; दोनों पढ़ सकते हैं /opt/git/<repo>, लेकिन केवल gitइसे लिख सकते हैं। gitयदि कोई नहीं दिया गया है .git/config, तो वर्तमान उपयोगकर्ता के लिए डिफ़ॉल्ट , जिसे मैं भूल गया था। नीचे दिए गए विस्तृत जवाबों में से कोई भी आवश्यक नहीं था।
सेबस्टियन

जवाबों:


209

जब आप इस त्रुटि को गिटब के बाहर देखते हैं, तो यहां एक उपाय है।

इसे इससे प्राप्त करें: http://mapopa.blogspot.com/2009/10/git-insufficient-permission-for-adv.html

ssh me@myserver
cd repository/.git

sudo chmod -R g+ws *
sudo chgrp -R mygroup *

git config core.sharedRepository true

इसके बाद git डेमॉन को .ITIT / ऑब्जेक्ट्स पर लिखते समय समूह फ़ाइल अनुमतियों का उपयोग करना चाहिए।


4
+1 यह हमारे लिए काम करता है। किसके लिए 's' है sudo chmod -R g+ws *?
एरिक बी

5
यह किसी अन्य उपयोगकर्ता द्वारा बनाई गई किसी भी नई फ़ाइल को रूट डायरेक्टरी की समूह अनुमतियों को बनाए रखने की अनुमति देगा। अन्यथा, आपके पास रिपॉजिटरी तक पहुंचने में त्रुटियां होंगी। Setuid और setgid देखें
syvex

मुझे डेबियन 6 और PHPStorm IDE पर Gitorious के साथ एक ही त्रुटि मिली, इस संदेश के साथ "त्रुटि: रिपॉजिटरी डेटाबेस के लिए एक ऑब्जेक्ट जोड़ने के लिए अपर्याप्त अनुमति ।गित / ऑब्जेक्ट्स"। मैं इस समाधान का उपयोग परियोजनाओं के मूल फ़ोल्डर पर करता हूं, "+ s ट्रिक" के साथ अच्छा काम करता है।
बेंज

3
रेपो-कॉन्फ़िगरेशन अप्रचलित है। होना चाहिए git config core.sharedRepository true
lpapp

4
ध्यान दें: यदि आप वाइल्डकार्ड " " का उपयोग करते हैं , तो छिपी हुई फ़ाइलें और फ़ोल्डर्स (जैसे .it!) प्रभावित नहीं हो सकते हैं! तो अगर ऊपर आप के लिए काम नहीं करता है, के लिए आदेशों को चलाएं। / साथ ही
बेन रोजमैन्स

54

आमतौर पर यह समस्या आपके Git सर्वर फ़ाइल-सिस्टम पर गलत उपयोगकर्ता और समूह अनुमतियों के कारण होती है। गिट रिपॉजिटरी को उपयोगकर्ता और उसके समूह के स्वामित्व में होना चाहिए।

उदाहरण:

यदि आपके उपयोगकर्ता को "git" कहा जाता है, तो उसका समूह "gitgroup", और Git repo का स्थान है: git@mygitserverxyz.com: path / to / repo.git

तो एक करो:

sudo chown -R git: gitgroup path / to / repo.git /

इसने मेरे लिए git अपर्याप्त अनुमति त्रुटि को ठीक किया।


chown: अमान्य उपयोगकर्ता: `git: git '
एलन कॉरमनो

4
@ मारीकेवन्स्की ने $ USER की कोशिश की: git के बजाय $ USER: git
dwurf

मेरे मामले में यह कुछ समय के लिए ही काम करता है। मुझे इसे कुछ पुश करने के बाद फिर से करना होगा।
BuZZ-dEE

यह सबसे अच्छा उत्तर है, लेकिन आपको यह कहना चाहिए कि आप चाउट को ".गित / ऑब्जेक्ट्स" तक सीमित कर सकते हैं और जिस उपयोगकर्ता को आप "गिट" कहते हैं, वह केवल वह उपयोगकर्ता है जिसके साथ आप लॉग इन हैं। तथ्य यह है कि उपयोगकर्ता ज्ञात है या git सर्वर द्वारा महत्वपूर्ण नहीं है।
ट्रिस्टन

34
sudo chmod 777 -R .git/objects

4
यह मेरे लिए काम किया ... लेकिन डब्ल्यूटीएफ ?? मैं महीनों से रेपो को अपडेट कर रहा हूं और आज दोपहर से अचानक शुरू हो गया ...
GojiraDeMonstah

मेरे लिए फिक्स लगभग समान था, लेकिन इसमें .IT डायरेक्टरी की कुछ फाइलों के मालिक को बदलना / सही करना शामिल था। मैंने कुछ git मेंटेनेंस किया था जबकि 'root' के रूप में लॉग इन किया था, और ऐसा लगता था कि या तो मालिक को रूट में बदल दिया है या रूट के मालिक के साथ कुछ नई फाइलें बनाई हैं जो git पर निर्भर थी। मेरे पास 'अपाचे' के मालिक के पास एक ऑटो-तैनाती की स्क्रिप्ट थी जो तब काम करना बंद कर देती थी।
coatesap

9
chmod 777एक अच्छा समाधान नहीं है, बस एक असुरक्षित समाधान है। इसके बजाय @ सेटवेक्स के उत्तर की कोशिश करें (सेटगिड के साथ)
4wk_

10

मेरे साथ ऐसा हुआ जब मैंने कोशिश की git pull। कुछ विश्लेषणों से पता चलता है कि किसी ने अतीत में जड़ से शुरुआत की थी, जिससे जड़ स्वामित्व के साथ कुछ वस्तुओं का निर्माण हुआ .git/objects

तो मैं भागा

cd <repo>
la .git/objects/

और rootइस तरह से कुछ वस्तुओं (निर्देशिका) के लिए स्वामित्व दिखाया गया है:

user@host:/repo> la .git/objects/
total 540
drwxr-xr-x 135 user user 4096 Jun 16 16:29 .
drwxr-xr-x   8 user user 4096 Jun 16 16:33 ..
drwxr-xr-x   2 user user 4096 Mar  1 17:28 01
drwxr-xr-x   2 user user 4096 Mar  1 17:28 02
drwxr-xr-x   2 user user 4096 Jun 16 16:27 03
drwxr-xr-x   2 user user 4096 Mar  3 13:22 04
drwxr-xr-x   2 root root 4096 Jun 16 16:29 05
drwxr-xr-x   2 user user 4096 Jun 16 16:28 07
drwxr-xr-x   2 root root 4096 Jun 16 16:29 08

फिर मैं भागा

sudo chown -R user:user .git/objects/

और यह काम किया!

मैं अपने वास्तविक उपयोगकर्ता के साथ उपयोगकर्ता की जगह ले रहा था , बिल्कुल।


4

उपरोक्त में से कुछ भी मेरे लिए काम नहीं किया। कुछ घंटों बाद मुझे समस्या का कारण पता चला: मैंने टाइप के एक रेपो यूआरएल का इस्तेमाल किया

ssh://git@example.com/~git/repo.git

दुर्भाग्य से मैंने नाम के साथ एक पोटीन सत्र संग्रहीत किया example.comजो उपयोगकर्ता के रूप में लॉगिन करने के लिए कॉन्फ़िगर किया गया था myOtherUser

इसलिए, जब मुझे लगा कि git example.comयूजर 'git' के साथ होस्ट से जुड़ता है , Git / TortoiseGit ने पोटी सेशन से कनेक्ट किया है example.comजो यूजर का उपयोग करता है myOtherUser। यह ठीक उसी ..insufficient permission..त्रुटि की ओर जाता है (कारण दोनों उपयोगकर्ता विभिन्न समूहों में हैं)।

समाधान: पोटीन सत्र example.comका नाम बदलेंmyOtherUse@example.com


4

chmod को चाउन किया जाना चाहिए, इसलिए सही लाइन है:

sudo chown -R gituser:gituser objects

3

ताज्जुब है, मेरे पास रेपो के एक क्लोन पर यह मुद्दा था, लेकिन मेरे पास नहीं था। रेपो के पुन: क्लोनिंग के अलावा (जो एक सहकर्मी ने इस मुद्दे को सफलतापूर्वक प्राप्त करने के लिए किया था), मैं असफलताओं के शुरू होने से पहले की गई प्रतिबद्धता के लिए "गिट रीसेट" करने में कामयाब रहा। फिर मैंने परिवर्तनों को फिर से प्रतिबद्ध किया, और मैं उसके बाद सफलतापूर्वक पुश करने में सक्षम था। इसलिए सभी संकेतों के बावजूद सर्वर पर एक समस्या थी, इस मामले में यह स्पष्ट रूप से स्थानीय रेपो में कुछ विषमता का संकेत था।


3

मुझे यह त्रुटि मिल रही थी क्योंकि हर बार जब कोई उपयोगकर्ता किसी सामग्री को धक्का देता है, तो फ़ाइल का समूह उपयोगकर्ता में बदल जाता है। और फिर यदि कुछ अन्य उपयोगकर्ता ने रिपॉजिटरी में पुश करने की कोशिश की, तो यह अनुमति त्रुटि का कारण बन गया और पुश अस्वीकार कर दिया गया। तो एक को अपने sysadmin को रिपॉजिटरी की सेटिंग्स को बदलने के लिए कहने की आवश्यकता है ताकि रिपॉजिटरी में किसी भी फाइल का समूह किसी भी उपयोगकर्ता द्वारा किसी भी पुश के लिए नहीं बदला जाए।

इस तरह की समस्या से बचने के लिए, कृपया सुनिश्चित करें कि जब आप अपने गिट रिपॉजिटरी को इनिशियलाइज़ करते हैं, तो कमांड "git init --soded" "का उपयोग करें।


अधिक स्पष्टीकरण के लिए आप लिंक stackoverflow.com/questions/16183345/…
अरुण चौधरी

2

यदि आपको अभी भी यह त्रुटि मिलती है तो अनुमतियाँ सेट करने के बाद आपको अपना निर्माण मास्क संशोधित करना पड़ सकता है। हमने पाया कि हमारे नए कमिट (ऑब्जेक्ट्स के तहत फ़ोल्डर) अभी भी बिना किसी ग्रुप राइट की अनुमति के बनाए जा रहे थे, इसलिए केवल उन्हें प्रतिबद्ध करने वाले व्यक्ति ही रिपॉजिटरी में धकेल सकते थे।

हमने सभी उपयोगकर्ताओं द्वारा साझा किए गए एक उपयुक्त समूह के साथ SSH उपयोगकर्ताओं के umask को 002 पर सेट करके इसे ठीक किया।

जैसे

umask 002

जहां मध्य 0 डिफ़ॉल्ट रूप से समूह लिखने की अनुमति दे रहा है।


क्या आप सुनिश्चित हैं कि यूनिक्स या लिनक्स में ऐसी कोई कमांड है? क्योंकि मैं काफी निश्चित हूं कि उमक स्थान-विशेष नहीं है।
जन हडेक

हाँ, मुझे खेद है कि आप सही हैं - मुझे नहीं पता कि मुझे लगा कि इसमें एक अतिरिक्त निर्देशिका पैरामीटर क्यों है। यह केवल उपयोगकर्ता के लिए लागू होता है। मैंने टिप्पणी अपडेट की है।
स्काइपिलॉट

2

आप कुछ सामान जोड़ने के बाद ... उन्हें कमिट करें और सब खत्म होने के बाद इसे पुश करें! बैंग !! सभी समस्याओं को शुरू करें ... जैसा कि आपको ध्यान देना चाहिए कि दोनों नई और मौजूदा परियोजनाओं को परिभाषित करने के तरीके में कुछ अंतर हैं। यदि कोई अन्य व्यक्ति समान फ़ाइलों को जोड़ने / प्रतिबद्ध / धक्का देने की कोशिश करता है, या सामग्री (दोनों वस्तुओं को समान रखता है), तो हम निम्नलिखित त्रुटि का सामना करेंगे:

$ 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 / ऑब्जेक्ट) की जांच करें। आप शायद ऐसा कुछ देखेंगे:

<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

समस्या हल करना

यदि आपके पास सुपर उपयोगकर्ता अनुमति है, तो आप आगे बढ़ सकते हैं और चरण दो का उपयोग करके अपने आप से सभी अनुमतियों को बदल सकते हैं, किसी भी अन्य मामले में आपको अपने उपयोगकर्ताओं के साथ बनाई गई वस्तुओं के साथ सभी उपयोगकर्ताओं से पूछने की आवश्यकता होगी, निम्न कमांड का उपयोग करके जान सकते हैं कि वे कौन हैं :

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

अब आपको और सभी फ़ाइल के मालिक उपयोगकर्ताओं को उन फ़ाइलों की अनुमति बदलनी होगी,

$ chmod -R 774 .

उसके बाद आपको एक नई प्रॉपर्टी जोड़ने की आवश्यकता होगी जो नए रिपॉजिटरी के लिए --sared = group के बराबर हो, दस्तावेज़ीकरण के अनुसार, यह रिपॉजिटरी समूह-योग्य बनाता है, इसे निष्पादित करें:

$ git config core.sharedRepository group

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


2

निम्नलिखित करने की कोशिश करें:

अपने सर्वर पर जाएं

    cd rep.git
    chmod -R g+ws *
    chgrp -R git *
    git config core.sharedRepository true

फिर अपनी वर्किंग कॉपी (लोकल रिपॉजिटरी) में जाएं और उसे रीपैक करें git repack master

पूरी तरह से मेरे लिए काम करता है।


2

आप इसका उपयोग कर सकते हैं

sudo chown -R $USER:$USER "$(git rev-parse --show-toplevel)/.git"

1
यह क्या कर रहा है? क्या आप एक स्पष्टीकरण जोड़ सकते हैं?
अनुबिन नोब

यह आपके रेपो के शीर्ष-स्तर की निर्देशिका प्राप्त करेगा, इसलिए कमांड आपके रेपो में वर्तमान में जहां भी है, उसकी परवाह किए बिना काम करेगा। यदि आप पहले से ही जड़ में हैं, तो आप सिर्फ सूडो चाउन -R $ USER: $ USER .गित चला सकते हैं
Tâm

इसे अपने प्रश्न में संपादित करें। अन्यथा आपका प्रश्न बहुत बेकार है।
अनुबिन नोब

2
sudo su root

chown -R user:group dir

दिर आपका गिट रेपो है।

फिर करो:

git pull origin master

आप दूसरों द्वारा किए गए कमिट के बारे में परिवर्तन देखेंगे।



1

ठीक है - यह पता चलता है कि यह GitHub पर एक अनुमति समस्या थी जो ईएमआई / बिक्सो के बिक्सो / बिक्सो के कांटे के दौरान हुई थी। एक बार जब टेककुब ने इन्हें ठीक किया, तो इसने फिर से काम करना शुरू कर दिया।


क्या हुआ और आपने इसे कैसे ठीक किया? मुझे पता है यह कुछ समय पहले था ... किसी भी विचार?
मेटा जनर

1
यह GitHub के पक्ष में एक मुद्दा था - इसलिए मुझे नहीं पता कि उन्होंने इसे ठीक करने के लिए क्या किया, बस GitHub में "Tekkub" ने कहा कि "मैंने अनुमतियां तय कर दी हैं" और फिर इसने काम किया।
krrugler

ठंडा। जानकारी के लिए धन्यवाद। मैं रेपो को फिर से क्लोन कर रहा हूं। उपसमिति, लेकिन यह काम किया। चीयर्स!

4
हम, उह, हमने गड़बड़ को ठीक किया । इसलिए उन्हें अब तनख्वाह नहीं मिलेगी, इसलिए यह स्वाभाविक रूप से खुद काम करेगा।
एलन

1

चूंकि त्रुटि ऑब्जेक्ट फ़ोल्डर पर अनुमतियों से संबंधित है, इसलिए मैंने ऑब्जेक्ट फ़ोल्डर पर सीधे एक चाउन किया और यह मेरे लिए काम करता है।


1

यह काम:

sudo chmod -R gituser.gituser objects

1
नहीं chmod, फ़ाइल अनुमतियों को बदलता है और मोड को तर्क के रूप में, उपयोगकर्ताओं और समूहों को नहीं। यह chmod -R ${some_octal_num} blaया तो हैchown -R ${some_user}:${some_group} bla
डेनिस विंटर

1

मुझे लगता है कि मेरे जैसे कई लोग मंचों में इस तरह से समाप्त होते हैं जब जीओटी समस्या के रूप में ऊपर वर्णित है। हालाँकि, ऐसे बहुत से कारण हैं जो इस समस्या का कारण बन सकते हैं कि मैं सिर्फ वही साझा करना चाहता हूं जो दूसरों के लिए मेरी परेशानी का कारण है जैसा कि मैंने पहले ही सीखा था।

मेरे पास एक लिनक्स NAS पर बैठकोम (कभी-कभी सीसकॉम, प्लेअसेज़ से एनएएस खरीदते हैं) पर मेरे प्रतिनिधि हैं। मेरे पास एक रेपो है जो कई कंप्यूटरों पर क्लोन किया गया है लेकिन जिसे मैंने अचानक पुश करने से इनकार कर दिया था। हाल ही में मैंने एक प्लगइन स्थापित किया ताकि मेरा NAS एक स्क्वीज़बॉक्स सर्वर के रूप में खड़ा हो सके।

यह सर्वर मीडिया को साझा करने के लिए स्कैन करता है। मुझे नहीं पता था कि बग के कारण संभव था, सर्वर निचोड़ने के लिए उपयोगकर्ता और समूह सेटिंग में बदलाव करता है: सभी फ़ाइलों के लिए उपयोगकर्ता उस पर नज़र रखता है। और वह सभी फाइलें हैं। इस प्रकार अधिकारों में फेरबदल करने के लिए मुझे धक्का देना पड़ा।

सर्वर चला गया है और उचित अधिकार सेटिंग्स फिर से स्थापित हैं और सब कुछ पूरी तरह से काम करता है।

मैंनें इस्तेमाल किया

chmod -R g+ws *
chown -R <myuser>:<mygroup> *

जहां मायूसर और मायग्रुप ऑफ-कोर्स को आपके सिस्टम के लिए उचित सेटिंग्स से बदला जाना चाहिए। git या gitter: gitter या कुछ और जिसे आप पसंद कर सकते हैं।


1

भंडार की जाँच करें: $ git रिमोट -v

origin  ssh://git@example.com:2283/srv/git/repo.git (fetch)
origin  ssh://git@example.com:2283/srv/git/repo.git (push)

ध्यान दें कि यहाँ एक 'git @' विकल्प है, यह git को दूरस्थ सर्वर पर उपयोगकर्ता नाम 'git' के रूप में प्रमाणित करने का निर्देश देता है। यदि आप इस पंक्ति को छोड़ देते हैं, तो git अलग-अलग यूज़रनेम के तहत प्रमाणित होगा, इसलिए यह त्रुटि होगी।


1

मेरे मामले में मेरी मशीन और गिट वर्चुअल सर्वर के बीच कोई एकीकृत प्रमाणीकरण नहीं था (जैसे डोमेन + विज्ञापन जैसी सेवा के भीतर)। इसलिए git उपयोगकर्ता और समूह वर्चुअल सर्वर के लिए स्थानीय हैं। मेरे मामले में मेरा दूरस्थ उपयोगकर्ता (जिसका उपयोग मैं दूरस्थ सर्वर में प्रवेश करने के लिए करता हूं) को अभी दूरस्थ गिट समूह में नहीं जोड़ा गया था।

ssh root@<remote_git_server>
usermod -G <remote_git_group> <your_remote_user>

इसके बाद ऊपर दी गई पोस्ट्स में बताई गई अनुमतियों की जांच करें ...


1

आप sudo git धक्का -u मूल की कोशिश करो - सभी ? कभी-कभी यह केवल एक चीज है जिसे आपको इस समस्या से बचने की आवश्यकता है। यह आपको व्यवस्थापक सिस्टम पासवर्ड के लिए पूछता है - वह जिसे आप अपनी मशीन में लॉगिन कर सकते हैं - और यह वही है जो आपको पुश करने की आवश्यकता है - या यदि यह मामला है, तो प्रतिबद्ध।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.