Git work on http but not ssh

Question

I have a remote repository that works fine when I communicate via http, but if I use ssh, it gives me errors when trying to push.

Goal: get the repo to work on ssh

I can easily delete ssh directly to a remote computer, all folders and files in the git repo and git working directory have 771 permission, the owner is apache, and the group is 'test' (which user I'm ssh-ing with 'test' is member). I also tried changing the owner and group to "test", but that didn't help. I have confirmed that a user account can read / write / execute from git directories via ssh.

I have a non-standard directory setting due to the use of virtualmin:
/ home / test (custom home)
/ home / test / public _html (web root)
/ home / test / public _html / git (gitweb directory)
/ home / test / public _html / git / git.git (repo directory)

This results in the same error message as below (there is no such file or directory) when I execute any git commands "locally" (directly on the remote server), unless I specify - git -dir and -work - tree, however, since http works and clicking on a remote server does not need to know the remote working directory, I don’t see how this will be a problem (and also I don’t see how to fix it, if it was).

In addition, if relevant, I use password authentication, not keys.

Does anyone have any thoughts on how I can solve / continue diagnosing this problem?

Error

git push origin:

Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 309 bytes, done. Total 3 (delta 2), reused 0 (delta 0) error: unable to create temporary sha1 filename ./objects/1d: No such file or directory fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To [e-mail] :/home/test/public_html/git/git.git/ ! [remote rejected] master -> master (n/a (unpacker error)) error: failed to push some refs to ' [e-mail] :/home/test/public_html/git/git.git/' 

Additional Information

git push origin (WHEN USES HTTP to http: // [e-mail] /git/git.git/ ):

 Password: Password: Fetching remote heads... refs/ refs/heads/ refs/tags/ updating 'refs/heads/master' from 425f5c3810b1c9e4ecc7ee7df3cd1bb8818b2115 to 65d2358df3035689116339a14f504f34a6212a27 sending 3 objects done Updating remote server info To http:// [e-mail] /git/git.git/ 425f5c3..65d2358 master -> master 

(I'm a little confused why there is so much difference between http and ssh, http twice asks for my password and then starts fetching the remote heads, while ssh asks for my password once and then starts counting objects.)

git pull origin:

 Already up-to-date 

git start remote show:

 * remote origin Fetch URL: [e-mail] :/home/test/public_html/git/git.git/ Push URL: [e-mail] :/home/test/public_html/git/git.git/ HEAD branch: master Remote branches: master tracked release tracked Local branches configured for 'git pull': master merges with remote master release merges with remote release Local refs configured for 'git push': master pushes to master (fast-forwardable) release pushes to release (up to date) 

And if used, my local configuration file:

 [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = [e-mail] :/home/test/public_html/git/git.git/ [branch "master"] remote = origin merge = refs/heads/master [branch "release"] remote = origin merge = refs/heads/release 

And the remote configuration file:

 [core] repositoryformatversion = 0 filemode = true bare = false worktree = /home/test/public_html sharedRepository = true 

---

Further research

After January comments, I explored the issue a bit. I assumed that during push over ssh (and apache used over http push) only the “test” account will be used, but I think it should be both.

I came back through a non-working repo and set the property in the same way as in the working repo (some files / folders are apache.test, others are test.test, and the configuration file is root.test).

I did not check absolutely everything, but the files in the repo directory, as well as all the files and folders under the objects, refs and info have the same ownership and permissions in both working and non-working state, and user accounts are configured in the same way ( I previously tried 777 in my troubleshooting).

The main difference I can think of is that in the non-working repo I started using http and then switched to ssh, while in the working repo I went directly to using ssh and the repo was empty before that. Perhaps there is a strange file somewhere with incorrect permissions that break everything, or something strange happens inside the actual files that I am upset with using different protocols, or maybe it just got corrupted due to my hours of trying make it work yesterday.

Answer 1

I created a new remote repository under a different user account, and now it works fine. All settings are more or less the same (permissions are less strict this time), so I'm not sure what the problem is.

Answer 2

If you search the Internet for the exact text of the error message you receive, it returns many hits. Due to a quick look at them, the resolution problem seems to be.

You say that you have a repository owned by apache.test . However, does apache actually work like apache.test ? If not, the new directories on which git server runs apache create will belong to another group (regardless of what the server’s main group is), and user test cannot write there, even though you told git to record the group repo.

You have several options:

• Use suExec to run git cgi as test.test and deny permission to write to the group.
• Use the primary web server group as the owner group
• Make repo all writable ( core.sharedRepository = everybody )
• It should be possible to make the SGO repo in the desired group by setting core.sharedRepository to 2664 , but I'm not sure about that.

Personally, I would prefer suExec.