gitlab-uberspace-tutorial icon indicating copy to clipboard operation
gitlab-uberspace-tutorial copied to clipboard

Repository Pfad falsch bei SSH

Open eknoes opened this issue 7 years ago • 2 comments

Hallo,

Ich habe alles wie im Tutorial angegeben gemacht, mit einer Custom Subdomain. Es funktioniert alles, allerdings kommt Gitlab noch nicht so recht mit dem Repo-Pfad klar:

Wenn ich über SSH klonen will, wird mir dieser Pfad angezeigt: [email protected]:user/repo.git

Allerdings funktioniert das klonen nur mit: [email protected]:repositories/user/repo.git

Allerdings kann ich so nicht pushen, nur pullen. Beim Push kommt diese Fehlermeldung:

Versende nach [email protected]:repositories/user/repo.git
Zähle Objekte: 3, Fertig.
Delta compression using up to 4 threads.
Komprimiere Objekte: 100% (2/2), Fertig.
Schreibe Objekte: 100% (3/3), 245 bytes | 0 bytes/s, Fertig.
Total 3 (delta 1), reused 0 (delta 0)
remote: GitLab: The project you were looking for could not be found.
To alpheca.uberspace.de:repositories/user/repo.git
 ! [remote rejected] master -> master (pre-receive hook declined)

Wenn ich die URL zu [email protected]:user/repo.git ändere, kommt bei Pull & Push:

fatal: 'user/repo.git' does not appear to be a git repository
fatal: Konnte nicht vom Remote-Repository lesen.

Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen
und das Repository existiert.

Über HTTP funktioniert Clonen, Pullen und pushen problemlos.

eknoes avatar Mar 01 '17 13:03 eknoes

Hast du den Repositorie Pfad in der Gutlab Conifg (gitlab.yml) angepasst?

## Repositories settings
  repositories:
    # Paths where repositories can be stored. Give the canonicalized absolute pathname.
    # IMPORTANT: None of the path components may be symlink, because
    # gitlab-shell invokes Dir.pwd inside the repository path and that results
    # real path not the symlink.
    storages: # You must have at least a `default` storage path.
      default: /home/<uberspace_username>/repositories/

sauberfred avatar Mar 01 '17 16:03 sauberfred

Ja, das habe ich alles gemacht. Habe den Fehler nun gefunden, es lag an meiner lokalen SSH Konfiguration. Trotz IdentityFile Angabe in ~/.ssh/config hat ssh meinen "normalen" Key genutzt und ich musste in meine Globale SSH-Konfiguration IdentitiesOnly Yes einfügen.

eknoes avatar Mar 02 '17 09:03 eknoes