Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Could not read from remote repository #3424

Closed
alfons24 opened this Issue · 95 comments
@alfons24

Hello,
i've installed GitLab 5 first time.

I get fhe following error while:

git push -u origin master
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

My ssh key is working fine, when i look at
tail -f /var/log/auth.log

Mar 27 15:33:30 ugitbuntu sshd[1802]: pam_unix(sshd:session): session opened for user git by (uid=0)
Mar 27 15:33:31 ugitbuntu sshd[1935]: Received disconnect from 10.100.2.172: 11: disconnected by user
Mar 27 15:33:31 ugitbuntu sshd[1802]: pam_unix(sshd:session): session closed for user git

What happens?
What can I do?

$ gitlab-shell/bin/check
Check GitLab API access: OK
Check directories and files:
/home/git/repositories: OK
/home/git/.ssh/authorized_keys: OK

gitlab$ bundle exec rake gitlab:env:info RAILS_ENV=production

System information
System: Ubuntu 12.04
Current User: git
Using RVM: no
Ruby Version: 1.9.3p327
Gem Version: 1.8.23
Bundler Version:1.3.4
Rake Version: 10.0.3

GitLab information
Version: 5.1.0pre
Revision: a31fe1a
Directory: /home/git/gitlab
DB Adapter: postgresql
URL: https://ugitbuntu
HTTP Clone URL: https://ugitbuntu/some-project.git
SSH Clone URL: git@ugitbuntu:some-project.git
Using LDAP: no
Using Omniauth: no

GitLab Shell
Version: 1.2.0
Repositories: /home/git/repositories/
Hooks: /home/git/gitlab-shell/hooks/
Git: /usr/bin/git

gitlab$ bundle exec rake gitlab:check RAILS_ENV=production
Checking Environment ...

Git configured for git user? ... yes
Has python2? ... yes
python2 is supported version? ... yes

Checking Environment ... Finished

Checking Gitlab Shell ...

GitLab Shell version? ... OK (1.2.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
post-receive hook up-to-date? ... yes
post-receive hooks in repos are links: ...
stefan / blabla ... repository is empty

Checking Gitlab Shell ... Finished

Checking Sidekiq ...

Running? ... yes

Checking Sidekiq ... Finished

Checking GitLab ...

Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
Projects have satellites? ...
stefan / blabla ... can't create, repository is empty

Checking GitLab ... Finished

Now I'm testing one week ago, but I won't get it work.

Regards
Stefan

@djgreg13

i have checked #3384 but no way

@orfin

We are having the same issue.

Gitlab RANDOMLY creates/deletes repos. From gitlab web-panel everything goes OK but sometimes the repo directories (home/git/repositories) are NOT physically created.
The same after removing project. Sometimes repository directories are NOT deleted.

root@tests:/home/git/gitlab-shell# bin/check
Check GitLab API access: OK
Check directories and files:
        /home/git/repositories: OK
        /home/git/.ssh/authorized_keys: OK
System information
System:         Debian 7.0
Current User:   root
Using RVM:      no
Ruby Version:   1.9.3p327
Gem Version:    1.8.23
Bundler Version:1.3.4
Rake Version:   10.0.3

GitLab information
Version:        5.0.0
Revision:       8b76157
Directory:      /home/git/gitlab
DB Adapter:     mysql2
URL:            http://gl.testing.com
HTTP Clone URL: http://gl.testing.com/some-project.git
SSH Clone URL:  git@gl.testing.com:some-project.git
Using LDAP:     no
Using Omniauth: no

GitLab Shell
Version:        1.1.0
Repositories:   /home/git/repositories/
Hooks:          /home/git/gitlab-shell/hooks/
Git:            /usr/bin/git
@rtnpro

I am also having the same issue as described above. Please help

@bbodenmiller

For those having problems with repos creating/deleting try restarting sidekiq.

@ArvinH

I have been stuck on this issue for more than ten hours....
please somebody help!

totally same problem

''''
git push -u origin master
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
''''''

@rtnpro

The error makes sense.
When we are trying to clone a repo from a url, say: git@localhost:sample_project.git, it says something like:

fatal: 'sample_project.git' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists. 

This is because the project git does not exist there but at git@localhost:repositories/sample_project.git. Cloning from/pushing to this URL works fine.

@ArvinH

okay, I find out that both of we have the similarly env setting in our GitLab information:

 git@localhost:sample_project.git 

but how do we change this setting? how to change this to git@localhost:repositories/sample_project.git ?

@rtnpro

I am also not sure about this :\

I see only one settings parameter to configure this: repos_path which in my case is already repos_path: /home/git/repositories/.

@bbodenmiller can you help us out?

@orfin

OK, we have restarted:

  • Gitlab application (with sidekiq consumers)
  • Redis

and that fixed the problem. In my opinion "something" was blocking Gitlab queue (btw. implemented on Redis).

I'm almost sure that it was caused by some low-level gitlab code which wasn't aware of possibility of such situations.

Does it mean low stability of 5.0 version, the question is: Is it suitable for production environments?!
We're preparing move from Redmine to Gitlab/Github for some projects. It was a very bad sign in the first day of Gitlab tests... :((

PING to Gitlab team @ariejan @randx

@ArvinH
@brianhmayo

I am having this issue too and it is very frustrating. I am not seeing anybody explain here "what" the error is saying. I read a few answers attempting to explain it, but none of those situations are my case.

I am assuming this error is actually coming from the Git command itself and not specifically from GitLab.

I, as others, followed the installation instructions exactly performing a fresh install on a new Ubuntu 12.04LTS server.

** update --
After relaxing a bit and reviewing all of my configuration files, I found my issue, which was my fault of course
Without thinking while I was configuring my server, in the /etc/hosts file I added the name x.m.com to the loopback IP address (127.0.0.1). Thus, any network calls performed on my local server to that name would go to that IP instead of the IP that NginX actually was bound to for the GitLab server.

Totally my fault, but I thought I would add this as something else for folks to double check. Make sure on the server itself that it has the hostname or IP address back to itself and specifically to the IP address the GitLab server is listening to.

@ArvinH

Hi,@brianhmayo
thanks for your advice, but here is my /etc/hosts


127.0.0.1       localhost
127.0.1.1         server name

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

I don't think that I have the issue you say... but I still have the same problem

@enajeeb

I have similar issue. HTTP Clone URL works but SSH Clone URL does not work.

git@my.host.com:some-project.git DOES NOT WORK
git@my.host.com:~/repositories/some-project.git WORKS

Here are the environment info.
$ bundle exec rake gitlab:env:info RAILS_ENV=production

System information
System: Ubuntu 12.04
Current User: root
Using RVM: no
Ruby Version: 1.9.3p327
Gem Version: 1.8.23
Bundler Version:1.3.5
Rake Version: 10.0.3

GitLab information
Version: 5.0.1
Revision: 907a8f4
Directory: /home/git/gitlab
DB Adapter: mysql2
URL: http://my.host.com
HTTP Clone URL: http://my.host.com/some-project.git
SSH Clone URL: git@my.host.com:some-project.git
Using LDAP: no
Using Omniauth: no

GitLab Shell
Version: 1.2.0
Repositories: /home/git/repositories/
Hooks: /home/git/gitlab-shell/hooks/
Git: /usr/bin/git

@enajeeb

I was able to resolve my issue by changing nginx configuration to listen to *:80 instead of specific IP. Apparently due to firewall different internal and external IPs.

listen *:80 default_server;

@shiquanwang

@enajeeb It is discussed here: #3384 (comment)

@junalmeida

I guess i'm having the same issue, but I didn't need to restart anything. I just created a project and its repo was not created. Then I removed the project and recreated. Git repo was there.
Cannot find anything useful on production.log.

@bbodenmiller

Creating a project does not create the repo like it does on GitHub, atleast not as of 4.2. You must init the repo and push it up to GitLab before the repo "exists". You can vote to change this functionality at http://feedback.gitlab.com/forums/176466-general/suggestions/3797854-create-empty-repo-on-project-creation

@junalmeida

I don't understand. I'm using release 5.0 and it creates an empty repository.

@bbodenmiller

So the 5.0 release now creates empty repos? Can someone confirm?

@ArvinH
@sivabalan

@bbodenmiller If you are talking about a <project>.git folder under /home/git/repositories/<user>/, 5.0 release does create that directory when I create a new project.

@jskonst

Hello, i have the same issue with missing ~/repositories in path? i have centos 6.4 with installed gitlab 5.0, and projects are created automatically. But i don't know what to do with wrong url.

@boxerab

I am having this same problem, with 5.0 I just created a fresh install.

Then I created a test project.

There is an empty project created in the /home/git/repositories/root directory,
with url git@zebra:root/test.git.

But I get the "fatal: could not read from remote repository" message when
I try to push for the first time.

Also, I tried importing an existing bare repository, but GitLab is treating it as an empty repository,
even though it is not.

@Y0shiii

I basically have the same issue. Fresh install on Debian Squeeze and I also followed the steps given in the troubleshooting guide:

env | grep -E "^(GEM_HOME|PATH|RUBY_VERSION|MY_RUBY_HOME|GEM_PATH)=" > /var/tmp/tempenv
sudo -u git -H cp /var/tmp/tempenv /home/git/.ssh/environment

No effect yet - still: Add Remote Repository: Could not read from remote repository.: Please make sure you have the correct access rights and the repository exists.

@peavers

Removing my local ip from the listen tag and adding * fixed my problem.

sudo nano /etc/nginx/sites-enabled/gitlab

//BROKEN

 server {
  listen 192.168.0.7:80 default_server;         # e.g., listen 192.168.1.1:80;
  server_name git.example.com;     # e.g., server_name source.example.com;
  root /home/git/gitlab/public;

//FIXED

 server {
  listen *:80 default_server;         # e.g., listen 192.168.1.1:80;
  server_name git.example.com;     # e.g., server_name source.example.com;
  root /home/git/gitlab/public;

And then restarting gitlab and nginx

sudo  service nginx restart
sudo /etc/init.d/gitlab restart
@Y0shiii

Do you think that the nginx configuration is causing the could not read error? Seems strange to me - unfortunately I'm not using nginx though and my apache vhost is listening to *:80

@guillaume-algis

I had the same error and found it came from gitlab-shell not being able to access to gitlab from the API.
Use sudo -u git -H /home/git/gitlab-shell/bin/check to verify if you have the same problem (I had an output similar to: Check GitLab API access: 403).

In my case the 403 response was caused by Nginx refusing connections from localhost.

@boxerab

Looks like 5.0/gitlab-shell is not quite ready for release, given so many people are having the most basic of difficulties. Or, at least, it needs better testing and documentation. I was thinking of switching from gitosis to gitlab; but I am going to hold off until things are more stable.

@bbodenmiller

@boxerab things are actually quite stable and reliable... Bit if you look at the issue tracker or support forum you are going to see the worst of the worst. Biggest issues apply when you install outside of its recommended configuration. Anyone having issues should upgrade to 5.1 released today which also includes new version of gitlab shell.

@boxerab

@bbodenmiller thanks, I will try the 5.1 release.

@boxerab

I installed 5.1, and the same problem is happening. I followed the install steps: the only deviation was to modify the puma.rb config file instead of unicorn.rb (unicorn seems to have been replace by puma, but there is no mention of this in the install files.) I also had to create a tmp/sockets directory to get the service to run. I also used the 1.3 tag for gitlab-shell.

sudo -u git -H /home/git/gitlab-shell/bin/check

return OK

ssh -vT git@my.gitlab.server

returns no errors, so ssh key is fine.

@boxerab

Where would this type of issue be logged in gitlab?? I checked production.log, application.log and the nginx log.

@boxerab

it would be helpful if someone from the gitlab team did a fresh install of 5.1 and updated the install instructions;
also verify that the fresh install works.

@boxerab

I tried @peavers advice, and this fixed the problem.

@peavers
@c7l8

I followed @peavers advice and I checked authorized_key file and I found a duplicate key. I just delete that keys and git clone over ssh work fine again.

@boxerab

my gitlab install was a fresh install on a new ubuntu VM, so I didn't have any issues with duplicate keys.

@ArvinH
@brianhay-energetica

Same issue here. Very frustrating. See #3745

@googolmo

the same to u
my ssh key can not add to ~/.ssh/authorized_keys

@jimmybrancaccio

Using the solution suggested by @peavers and others worked for me. I changed from a server using a public address to one using a private address so using *:80 worked for me.

@prestayn

Solution for me was similar to the advice by @rtnpro.
After creating the repository in Gitlab (5.1) the web page suggested to do
git remote add origin git@localhost:root/test.git
It worked with
git remote add origin git@localhost:repositories/root/test.git

@Falconne

I recently installed the latest stable version (5.1.0) and had the same issue. After following shiquanwang suggestion it was fixed.

I'm surprised his month old pull request to the documentation hasn't been actioned yet, considering this problem causes new installation to not work.

@bbodenmiller

@Falconne I don't actually see a pull request for this issue. @senny @randx have you had a chance to look into the issues posted here?

@Falconne

@bbodenmiller Actually the pull request was created by ProverbioBayardi: #3403 after shiquanwang figured out the issue.

I found that in this related thread: #3384

Looking at the change, it should probably also remove the example after the #. Having an IP address there would confuse people into adding one.

@bbodenmiller

Related to #3863, #3840

@junalmeida

Got something useful on sidekiq.log:

2013-05-07T10:18:03Z 5247 TID-fpur8 GitlabShellWorker JID-9d0a0649b52412d12d177f8e INFO: start
/usr/lib/ruby/1.9.1/fileutils.rb:244:in `mkdir': Permission denied - /home/git/repos/junalmeida (Errno::EACCES)
from /usr/lib/ruby/1.9.1/fileutils.rb:244:in `fu_mkdir'
from /usr/lib/ruby/1.9.1/fileutils.rb:221:in `block (2 levels) in mkdir_p'
from /usr/lib/ruby/1.9.1/fileutils.rb:219:in `reverse_each'
from /usr/lib/ruby/1.9.1/fileutils.rb:219:in `block in mkdir_p'
from /usr/lib/ruby/1.9.1/fileutils.rb:205:in `each'
from /usr/lib/ruby/1.9.1/fileutils.rb:205:in `mkdir_p'
from /home/git/gitlab-shell/lib/gitlab_projects.rb:42:in `add_project'
from /home/git/gitlab-shell/lib/gitlab_projects.rb:28:in `exec'
from /home/git/gitlab-shell/bin/gitlab-projects:23:in `<main>'
2013-05-07T10:18:05Z 5247 TID-fpur8 GitlabShellWorker JID-9d0a0649b52412d12d177f8e INFO: done: 1.897 sec

But I don't know why I got a permission denied. The path is correct, and permissions seems to be too. I can create files and folders inside that dir using the git user.

The most weird thing is that it have permission to create aaaa.git project but doesn't have for a particular name. I was using the latest TAG from gitlab-shell: 1.4.0.

Tryed the latest unstable master and worked.

@dhampik

I think I have something related to this issue.
I just found that my repo in /home/git/repositories was removed!
And I don't know how it happend - I did not removed a project from gitlab and I did not touch files!

Using gitlab 5.1

/offtopic
And that is a very bad sign that gitlab removes repos with no reason!
After a day of playing with gitlab, it seems to be a very raw thing - had a lot of issues with it:

  • check script compares init.d script with the different one rather than the one in installation instrucations
  • had to install pkgs from backports and I'm not glad about it (redis, git)
  • problems with gitlab.socket which somehow is not removed on sudo /etc/init.d/gitlab stop
  • had problems with Files browsing until installed git from backports (no word about it in manual)
  • had problems with importing repos, seems it doesn't work properly
  • and now that... deleted repo! WTF?

and that is just one day of usage! (glad that for all above problems there are issues)
Devs, you should NOT release a version with so many bugs! That is not stable at all! Alpha - maybe!
Just sad.

You are doing an incredible awesome tool, but it seems like you are hurrying to much. Take your time! Release alphas, betas, rcs first. This will make people more loyal to you.

@bbodenmiller

@dhampik if you are able to make pull requests for any of the issues mentioned (documentation included) I'm sure the devs will be greatful. @senny @randx a bit concerning about the repo deleting itself. Might be good to create a new issue on this and get to the bottom of what happened.

@dhampik

@bbodenmiller Created issue #3919

@Razer6
Collaborator

@senny The attached PR has been merged. Please close.

@senny senny closed this
@caiwangqin

this issue still exist in 5.2

I have a fresh installation for 5.2, and nginx is config to *:80, but i still got the error mentioned by @rtnpro:

Doesn't work with the project git url list on web:
git remote add origin git@localhost:root/test.git
It worked with
git remote add origin git@localhost:repositories/root/test.git

http totally doesn't work:
$ git clone http://git.server.com/root/test.git
Cloning into test...
error: Empty reply from server while accessing http://git.server.com/root/test.git/info/refs

fatal: HTTP request failedork:

could not found any useful error message for this issue.

@bbodenmiller

Can you make sure all config files are updated as per #4005?

@caiwangqin

@bbodenmiller i was install from 5.2 stable, not upgrade from 5.1, after i change host to "git.myserver.com" in
https://github.com/gitlabhq/gitlabhq/blob/5-2-stable/config/gitlab.yml.example, gitlab_url to "http://git.myserver.com/" in https://github.com/gitlabhq/gitlab-shell/blob/v1.4.0/config.yml.example, and add "public-ip git.myserver.com" into /etc/hosts. then clone from http works "git clone http://git.myserver.com/root/test.git".

but the clone ssh still need add "repositories" folder in clone url, any suggestions or where i can see error log?

@caiwangqin

#3686 fixed my problem, So many people face this issue, Maybe should add this into troubleshoot document.

@bbodenmiller

Can you create PR to update docs as you see fit?

@senny

@bbodenmiller the troubleshooting is still in the wiki and it's not possible to submit a PR. I think we should move it into the repository to allow for community suggestions. Are you interested in moving it? Otherwise I put it on my todo list.

@bbodenmiller

Awh I forgot about that. I'll add it to my list as well but it will be awhile.

@senny

@bbodenmiller let me move it.

@bbodenmiller

@caiwangqin can you fork https://github.com/senny/gitlabhq/blob/move_troubleshooting_guide_from_wiki_into_repo/doc/install/troubleshooting.md and start adding the troubleshooting details? Also can you detail exact what the configuration issues were so we can try adding to check script?

@senny

The troubleshooting guide stays in the public wiki. Everyone should have acces to make changes directly. No need to bring it into the repository.

@jdurand

I lost 5 hours of my life on this issue. @shiquanwang's fix works but if you tried different solutions you ended up with a dirty ./ssh/authorized_keys file with either duplicates or legit keys assigned to the wrong user id's.
Emptying this file and re-adding my key did it for me.

@kapoorsunny

I am getting below error.

git push -u origin master
Access denied.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I have already wasted by 8 hour....could anyone please HELP!!

@peavers
@kapoorsunny
@jdurand

Are there any duplicates in your ./ssh/authorized_keys file? (meaning the same key for different users)

@kapoorsunny
@jdurand

Well... if @shiquanwang's fix doesn't work for you, I'm out of solutions. Sorry.

@kapoorsunny
@jdurand

If you try 'ssh -v' or look at the '/var/log/auth.log' file on the server. Do you get any more info on why the server hung up?

@kapoorsunny
@DasLampe

Same problem here.

One push was ok (1 commit), after this I can't do anything. No push, no clone... nothing. :(

@peavers
@DasLampe

#sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production

Checking Environment ...

Git configured for git user? ... yes
Has python2? ... yes
python2 is supported version? ... yes

Checking Environment ... Finished

Checking GitLab Shell ...

GitLab Shell version >= 1.4.0 ? ... OK (1.7.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
post-receive hook up-to-date? ... can't check because of previous errors
post-receive hooks in repos are links: ... can't check because of previous errors

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes

Checking Sidekiq ... Finished

Checking GitLab ...

Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... no
Try fixing it:
Install the init script
For more information see:
doc/install/installation.md in section "Install Init Script"
Please fix the error above and rerun the checks.
Init script up-to-date? ... can't check because of previous errors
Projects have satellites? ...
Administrator / Test Project ... yes
[some more]
Redis version >= 2.0.0? ... yes
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (1.8.3)

Checking GitLab ... Finished

#sudo -u git -H /home/git/gitlab-shell/bin/check
Check GitLab API access: OK
Check directories and files:
/home/git/repositories: OK
/home/git/.ssh/authorized_keys: OK

I hadn't edit some file between first commit and the error.
Exists more checks?
Why "post-receive hook" not run? Oo I can't see an error before.

@kapoorsunny

Silly me, I missed port number in gitlab_url .
Issues is now sorted

@DasLampe

Oh. That's fixed it. :)

But I had pushed without error before, one time. That's crazy.

@Leandros

I got a similar issue, but none of the fixes here worked for me: My issue: #4751

@wojciech-wieronski

I just went through a migration from 2.7.0 to 5.4 and finally got it working 100%. The last hurdle that I had to overcome was the notorious: "fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists."

Turns out I had to update the /home/git/.ssh/authorized_keys file and change from gitolite's shell to the gitlab-shell. Changing the shell alone didn't do the trick. You have to make sure you update the shell and key-token right after the shell (it has to correlate to the Key id in gitlab's key table).

i.e.

command="/home/git/gitlab-shell/bin/gitlab-shell key-{key.id}",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa {rest of key}

Being that I had a ton of users, I wrote this:

select concat('command="/home/git/gitlab-shell/bin/gitlab-shell key-',id,'",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ',
key) as command
from keys order by id asc

After overwriting the authorized_keys file with the output from the above query....I was in business.

Hope this helps someone.

Wojo

@flakrat

I had the same issue as the original poster on a new Gitlab install:

The issue turned out to be related to the rewrite rule to force SSL (port 443) and am using a self signed cert.

I needed to modify gitlab-shel/config.yml as follows, change http to https and self_signed_cert from false to true:

gitlab_url: "https://gitlab.mydomain.org/"
http_settings:
self_signed_cert: true

@jiangdapeng

I had the same issue after I install gitlab 5.1.0 on ubuntu 12.04

some config files' content:
in gitlab-shell/config.yml gitlab_url: "http://my_ip/"
in nginx config: listen *:8081 default_server

(because port 80 was used by other site)

the problem was solved by change listen *:8081 to listen *:80

@davidxchen

flakrat's solution works for me:

gitlab_url: "https://gitlab.mydomain.org/"
http_settings:
self_signed_cert: true

@lygstate

What's this mean:

root@ubuntu:/home/git/gitlab-shell# bin/check 
Check GitLab API access: 
/opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `initialize': No such file or directory - getaddrinfo (Errno::ENOENT)
    from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `open'
    from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `block in connect'
    from /opt/bitnami/ruby/lib/ruby/1.9.1/timeout.rb:55:in `timeout'
    from /opt/bitnami/ruby/lib/ruby/1.9.1/timeout.rb:100:in `timeout'
    from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:763:in `connect'
    from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:756:in `do_start'
    from /opt/bitnami/ruby/lib/ruby/1.9.1/net/http.rb:745:in `start'
    from /opt/bitnami/apps/gitlab/gitlab-shell/lib/gitlab_net.rb:62:in `get'
    from /opt/bitnami/apps/gitlab/gitlab-shell/lib/gitlab_net.rb:29:in `check'
    from bin/check:11:in `<main>'

@jmiguel77

i have tried every check and solution listed in this page ten times over, and i still get the same error:
Access denied.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights

Everything gives me a correct response, every test is fine, every configuration working correctly, the http access works (clone, push, pull, etc) but i still cannot make the ssh access work

i always get this in the gitlab-shell.log

WARN -- : gitlab-shell: Access denied for git command by user with key key-6.

@jmiguel77

FOUND IT !!
it was the ldap bind cn password that was causing the problem !!! it is really really hard to debug problems in gitlab !!

@GeorgeZhuo

And how to fix it?

@gaui

I'm getting the same issue.

$ git clone git@myserver.com:gaui/foobar.git

But I'm getting:

fatal: 'gaui/foobar.git' does not appear to be a git repository
fatal: Could not read from remote repository.

How should it be able to access gaui/foobar.git when my repo is under /home/git/repositories/foobar.git ?

If I try to add repositories/ to clone path it works:

$ git clone git@myserver.com:repositories/gaui/foobar.git
Cloning into 'foobar'...
warning: You appear to have cloned an empty repository.
@gaui

Got it finally to work. Although it may sound weird, the reason was the /home/git/.ssh/authorized_keys file.

I got it to work by doing:

sudo -u git -H /home/git/gitlab-shell/bin/gitlab-keys clear
sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production

Now my authorized_keys looks something like this:

# Managed by gitlab-shell
command="/home/git/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty [rest of key]
@andrewjmead

I had to edit nginx conf:
> sudo vi /etc/nginx/sites-enabled/gitlab

change:
client_max_body_size 5m;
to
client_max_body_size 100m;

@miko miko referenced this issue in sameersbn/docker-gitlab
Closed

git push/pull: Access denied #26

@shinvdu

@jmiguel77 can you tell us how to fix it by step?

@fibo99

The same problem did re-appear.
Getting mad at the impossible hope to creat enew projects (but existing ones are OK!)

(Later edit: for some reasons the new project directories were owned by root:root instead of the expected git:git. Changing that solved the problem)

@jmiguel77

@shinvdu sorry for the really late reply; the only thing that i did to fix is to put the correct password for the ldap account
In your gitlab installation go to gitlab > config folder
Open the gitlab.yml file
In the ##LDAP setting section, check the data entered (here was my mistake, the password for my ldap admin account was wrong)

@DavidLemayian DavidLemayian referenced this issue from a commit in DavidLemayian/documentcloud
@DavidLemayian DavidLemayian Updated documentcloud-notes github reference
The previous method of referencing is prone to failures [1] with frequent access loss. This change is a simple and commonly used (jQuery et al) but could still fail on certain networks. If it does, `https;//` works fine.

[1]: gitlabhq/gitlabhq#3424
c37c5e8
@DavidLemayian DavidLemayian referenced this issue in documentcloud/documentcloud
Open

Updated documentcloud-notes github reference #130

@jcberthon

I had the issue with GitLab 7.0 on openSUSE 13.1. I followed and adapted the installation guide for Ubuntu (I'm familiar with both flavour of Linux, so it was an "easy" ride). But at the end and like some of you, I could clone and push via HTTPS successfully. But via SSH, I got the same error as you all did: "fatal: Could not read from remote repository."

I've found a "solution". The git user created following the installation manual has the possibility to login disabled (created via "sudo adduser --disabled-login --gecos 'GitLab' git"). This command setted for the default shell for git the /bin/false executable, which disallow login for the user. I've edited the file to set it back to bash, thus allowing local and remote login to happen (in terms of security this is really unwise). This has solved my problem: I can now clone and push using SSH as well.

My quest is not finished, I need to find a way to block remote login at least but still allowing git clone and push, via SSH. But I thought this could already help some of you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.