1

Im running a redmine server with the redmine-git-hosting plugin to control git repos. The repository dir points to a separate hard drive mounted at /srv/share. Now the setup is changing and I'm trying to move the repos to a nfs share on another server.

The mount works fine, I simply replaced the entry in the fstab file from /etc/sdb1 to ip:/share. Now I had some permission problems beforehand since the drive is accessed by redmine (user www-data) and gitolite (user git) at the same time, so I ran a chmod -R 777 on the whole drive to deal with this.

I set the Windows NFS server to the same umask (It's 000 there, for some reason it's inverted) and in fact both users can read and write to the drive. But now when trying to create a new repository with redmine, error 500 pops up. The unhelpful log entry says Rugged::NetworkError (unpacking the sent packfile failed on the remote):

Now there are git repos already configured on the server and when I try to commit something to one of them the following error pops up

Total 3 (delta 0), reused 0 (delta 0)
POST git-receive-pack (397 bytes)
remote: fatal: error when closing sha1 file: Permission denied

Any ideas what to do here?

nfs client, redmine and git server: ubuntu server 14.04.4 LTS
nfs server: haneWin nfs server on Windows Server 2012R2

yspreen
  • 1,759
  • 2
  • 20
  • 44
  • Regarding ssh, make sure none of the parent folders of .ssh and ssh folder itself has any write attribute. `chmod 700` for .ssh itself (on the server and the client) – VonC Jun 04 '16 at 16:38
  • I'm using https to access git – yspreen Jun 04 '16 at 16:39
  • OK, I misread sha1 for ssh! – VonC Jun 04 '16 at 16:40
  • After a chmod, maybe a chown? http://stackoverflow.com/a/692062/6309 – VonC Jun 04 '16 at 16:51
  • 1
    Or at least a `git config core.sharedRepository true` – VonC Jun 04 '16 at 16:52
  • To be clear, I don't perform chmod on the nfs because it doesn't change anything I just set the umask in the nfs server config, then confirmed everyone has access – yspreen Jun 04 '16 at 16:59
  • OK. Did you try the core.sharedRepository on the server side? – VonC Jun 04 '16 at 16:59
  • Not yet, will report back when I'm home around one hour from now. To be honest I don't think that's it though – yspreen Jun 04 '16 at 17:03
  • Ok, I ran the command on the repo Im testing in particular, and also with the --global modifier, as user, as root and as the git user. Im not too sure what this is supposed to change, but cloning the repo anew, changing something, starting the push I get the same error: `remote: fatal: error when closing sha1 file: Permission denied error: unpack failed: unpack-objects abnormal exit To ~some url~ ! [remote rejected] master -> master (unpacker error) error: failed to push some refs to '~some url~'` (I change the url myself, the path in the original is correct) Also my bad for the late reply – yspreen Jun 05 '16 at 14:16

1 Answers1

1

So this entire thing is pretty weird. In the end I went with a virtual vdi disk which is stored on a folder on the Windows server which is shared and mounted by ubuntu through SMB (to /srv/shareSMB). The vdi is then again mounted by ubuntu to the original /srv/share. This works.

I think the problem(s) resulted in the differences between the unix and the Windows world when it comes to file structures, especially links. Gitolite seems to work with links quite a lot, that might have been the root of all evil, that way all the gitolite repos were broken and I needed to reinstall it.

yspreen
  • 1,759
  • 2
  • 20
  • 44
  • 1
    Interesting of vdi there. +1 – VonC Jun 07 '16 at 22:20
  • To add to this, vdi seemed the best solution since it's the only virtual format for which dynamic sizing has worked reliably for me in the past. Also it can be mounted by ubuntu and you can even share the mounted vdi over nfs, thats pretty cool. – yspreen Jun 07 '16 at 22:23