Help me alsjeblieft, ik probeer dit in mijn terminal uit te voeren:
asgard@asgard-A7N8X2-0:~/CollegePortal$ git pull
error: cannot open .git/FETCH_HEAD: Permission denied
Dan probeer ik deze
asgard@asgard-A7N8X2-0:~/CollegePortal$ sudo git pull
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Help me, ik begrijp dit probleem niet.
Antwoord 1, autoriteit 100%
Het lijkt erop dat de eerste niet werkt omdat je gebruiker niet de rechten heeft om die map te wijzigen, en de tweede omdat je rootgebruiker niet de juiste SSH-sleutels heeft om toegang te krijgen tot die git-repository.
p>
Afhankelijk van wat u probeert te doen, is het misschien beter om de repository naar een andere map te klonen, of misschien chownde huidige map om volledige toegang voor uw gebruiker te hebben
Antwoord 2, autoriteit 72%
Controleer of je genoeg rechten hebt voor de .git/directory. U moet schrijfrechten hebben. Je kunt ze instellen met het volgende commando.
Ga naar je projectmap:
chown -R youruser:yourgroup .git/
Antwoord 3, autoriteit 23%
Als je de groep toestemming wilt geven,
sudo chmod g+w .git -R
werkte het beste voor mij.
Voor MacOS
sudo chmod -R g+w .git
Antwoord 4, autoriteit 14%
Dit is een UNIX-machtigingsprobleem. Gebruik sudoniet om de repository te klonen. Je hebt niet dezelfde ssh-sleutels als root en je zou sowieso niet als root moeten werken. Probeer ls -laom de rechten op de bestanden te vinden en gebruik chmod(of sudo chown) om ze te herstellen. Ik hoop dat dat helpt.
Antwoord 5, autoriteit 13%
In mijn geval werkt het daarna prima:
rm -f .git/FETCH_HEAD
git branch -u
Antwoord 6, autoriteit 10%
Het antwoord op dit probleem zorgt ervoor dat .git/FETCH_HEAD schrijfrechten heeft en je bent helemaal klaar.
Ik had dit probleem op Windows en het werd opgelost door schrijfrechten te geven.
In Unix kan men chmod a+rw .git/FETCH_HEADuitvoeren vanuit de projectrepository waarna het zou moeten werken.
Antwoord 7, autoriteit 10%
Probeer het op deze manier,
Stap 1:Controleer eerst wie je bent? het geeft de huidige gebruikersnaam terug, bijvoorbeeld ubuntu
$ whoami
Stap 2:Stel vervolgens de toestemming in voor uw huidige gebruiker, in dat geval ubuntudoor
sudo chown -R ubuntu .git/
Antwoord 8, autoriteit 5%
In mijn geval had ik alleen leestoegang tot het .git/FETCH_HEAD-bestand. Ik moest “sudo chmod g+w .git/FETCH_HEAD” doen om een pull-verzoek te kunnen doen.
Antwoord 9, autoriteit 5%
Ik had het eerste probleem (FETCH_HEAD toestemming geweigerd) op Windows.
Ik heb het opgelost door Git Bash als beheerder uit te voeren (klik met de rechtermuisknop, voer uit als beheerder).
10, Autoriteit 4%
Voer toestemming in aan uw huidige gebruiker door de opdracht
te draaien
$ sudo chown -R <username> .git/
11, Autoriteit 3%
Hiermee wordt alle machtigingen in de map
opgelost
sudo chown -R $(whoami) ./
12, Autoriteit 3%
Windows 7, toen ik dit probleem had, was het omdat ik de map .git had verborgen. De machtigingen waren prima, het was gewoon verborgen. Het tonen van de map is het opgelost.
13, Autoriteit 3%
Ga gewoon naar uw -wortelmap en voer deze opdracht uit:
chmod a+rw .git/FETCH_HEAD
14
Dit werkte voor mij:
- rechts klik op de map
- Klik op Info
- Toestemming instellen bij uw gebruiker
- Klik op het tandpictogram en klik op Toepassen op bijgevoegde items
Geen toestemming meer ontkende fouten in Git. 🎉
15
FOUT: kan niet openen / fetch_head: toestemming geweigerd
Dit werk voor mij:
- Standaard .Git map is verborgen.
- Volg de map en de mappen van het kind en het bestand en probeer het verzoek te trekken.
16
Kijk naar de eigenaar en een groep .gitDirectory With (Eerste Ga naar Oudermap van .git) ll .git, kijk naar de groep en eigenaar van de Directory,
Voeg uw gebruiker toe aan de groep van van de eigenaar met sudo usermod -a -G yourusername groupsofonwner, DAN LOGOUT = & GT; Inloggen en alles wordt aan het werk.
Dus in zomers
-
Ga naar oudergids van GIT
$cd your path -
Vind groepseigenaar van de
.gitDirecteCotry$ll .git -
Voeg uw gebruiker toe aan die groep
$usermod -a -G yourusername ownergroupofgit -
Uitloggen en inloggen op het systeem aan deze wijziging wordt van kracht.
-
Geniet ervan;)
17
Hebt die kwestie wanneer .git-map verborgen is en alle bestanden erin is ook verborgen.
Maak alleen .Git-map verborgen zonder recursieve bestanden-update en het zal werken.
18
Redenen van deze fout kunnen veelvouden zijn, maar in mijn geval heb ik het filiaal bijgewerkt met root en toen ik probeerde het bij te werken met de normale gebruiker.
Probeer beide oplossingen die men voor u moet werken
1- sudo chmod g+w .git -R
Als het niet werkt, probeer dan de volgende oplossing Hoop dat het uw probleem zal oplossen
2 - rm -f .git/FETCH_HEAD
19
Ik had dit bericht bij het gebruik van GIT-extensies voor Windows. Mijn fix was om Git Extensions te sluiten en vervolgens opnieuw openen als beheerder
20
In mijn geval,
sudo chmod ug + wx .git -r
deze opdracht werkt.
21
Dit probleem ontstaat wanneer u voldoende machtigingen niet geeft aan de map.
Om dit probleem op te lossen –
- Navigeer eerst naar uw werkdirectory.
-
Voer deze opdracht in –
SUDO CHMOD A + RW .GIT -R
Ik hoop dat het helpt .. !!
22
Ik had exact dezelfde fout, maar in mijn geval was het probleem het gevolg van het opnieuw opbouwen van Apache na een upgrade naar de PHP-versie. Om een lang verhaal kort te maken, ik ben vergeten de Apache-module ‘suexec’ te installeren.
Het had niets te maken met groep of eigendom. Het kostte me maar twee dagen om erachter te komen, iemand schiet me neer…
Antwoord 23
In mijn geval had ik een dual-boot systeem (Windows 10 en Linux) met projectmap op NTFS-schijf. Het bleek dat bij een andere update Windows 10 zichzelf “snel opstarten” in de instellingen heeft ingeschakeld.
Nadat ik het in Windows heb uitgevinkt – de “fout: kan .git/FETCH_HEAD: toestemming geweigerd” in Linux niet openen.
Antwoord 24
gebruik dit voor MacOS-gebruikers (indien High Sierra of een hogere versie):
sudo chown -R $(whoami) $(brew --prefix)/*
Antwoord 25
Ik heb dit gekregen omdat ik meer dan 1 gebruikersaccount op mijn box had. Ik was ingelogd als gebruiker A en bevond me in een map voor gebruiker B. Gebruiker A had geen toestemming voor de spullen van gebruiker B. Toen ik me realiseerde dat ik niet was waar ik dacht dat ik was in het bestandssysteem, was deze fout logisch.
Antwoord 26
Als u hetzelfde probleem aantreft in de Windows-server, moet u de opdrachtregel uitvoeren met voldoende toestemming, zoals beheerdersrechten.
Antwoord 27
Veel antwoorden hier, velen suggereren een chown te doen.
Voor mij was het veel gemakkelijker om de gebruiker te veranderen in de gebruiker die de map bezit (in mijn geval Tomcat) omdat de eigenaar mocht schrijven:
sudo su tomcat
en doe dan een
git pull
het is niet nodig om de machtigingen te wijzigen. Ik geef hier de voorkeur aan omdat ik er niet aan hoef te denken om de toestemming weer te wijzigen nadat ik klaar ben.
Om de gebruiker te vinden die eigenaar is van de map, doe een ls -la
Opmerking: geef geen niet-sudo-schrijftoegang tot mappen die worden aangeboden!
28
in mijn case Werk dat: I Just schreef sudovóór de opdracht:
sudo npm run deploy