I'm trying to setup gitlab (6.5.1) on a fresh clean server. Everything appears to work, but git is unable to push to any project. Following the commands from the newly created project page and pushing to the remote via ssh gives:
$ 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.
This seems to be a fairly common problem. Unfortunately it seems to have a number of potential causes and none of them seem to match. From issue 3424 on an old release and various other sources online I've seen and checked the following suggestions:
Leftover ssh keys
This is a clean setup with no leftovers. My key got added to the authorized keys file properly and is the only one listed.
Running ssh with debug logging shows errors related to Ruby environment vars.
Mine comes up clean. SSH debug shows a successful connection. Everything about the authentication handshaking is normal, then this is the end of the output:
debug1: Sending command: git-receive-pack 'username/reponame.git' debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype firstname.lastname@example.org reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK
Problems with the gitlab-shell environment.
Unlike many others with the same error message above, my gitlab-shell check script returns a clean bill of health:
% sudo -u gitlab -H ~gitlab/gitlab-shell/bin/check Check GitLab API access: OK Check directories and files: /var/lib/gitlab/repositories: OK /var/lib/gitlab/.ssh/authorized_keys: OK Test redis-cli executable: redis-cli 2.8.5 Send ping to redis server: PONG
The reports that restarting one or more services clears this up don't seem to apply here. This isn't an intermittent problem that releading a daemon fixes.
The repo isn't getting physically created
But it is. The first time every time, the bare git repo in
~gitlab/repositories/username/reponame.gitgets created every time and seems to have the correct permissions.
Gitlab-shell can't talk to the API server because A) DNS problems, B) wrong ip/port/interface binding C) not having/having a trailing slash.
The check script says the API access is fine.
I'm not running nginx, so the default ip binding issue related to that is n/a.
I've tried both
127.0.0.1:8080for the listen value in
Beyond that, I have tried various iterations of localhost, 127.0.0.1 and the fully qualified domain name (which is DNS resolving fine) with and without trailing slashes in
shell.ymlto no avail. I have also tried wiring this directly to the unicorn server on port 8080 instead of the Apache SSL / proxy host on port 80. Nothing seems to make any difference. My certificate is not self signed and are working fine for browsers, but I tried setting
self_signed_cert: trueanyway. Nothing.
The reported git paths are wrong, add fully qualified path from gitlab user home.
This seems like a legit suggestion if the gitlab-shell isn't doing some monkey business to correct this already, but I tried changing
git remote add origin gitlab@server:username/reponame.gitto
`git remote add origin gitlab@server:repositories/username/reponame.gitto no avail. Same error.
This seems to be the litany of solutions suggested, but none of them seem right. Note I am able to push over http. The login prompt accepts my ldap username and password and accepts a push. This is only a problem trying to use SSH. Testing just the ssh login part with
ssh -T gitlab@server works fine.
What else could be causing this error?
How does one go about debugging such an issue in gitlab? There does not seem to be anything relevant at all in
~gitlab/gitlab-shell/gitlab-shell.log. Where would a more informative error message be found?