Git: Can't push from one computer

Question

One of my coworkers is having a problem pushing changes from git on his machine. If he logs into another machine, he can push just fine - but from his machine, when he tries to push he gets the following error

    D:\Projects\test1\best-practices>git push
    Counting objects: 4, done.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 273 bytes, done.
    Total 3 (delta 1), reused 0 (delta 0)
    error: unable to create temporary sha1 filename ./objects/42: Permission denied

    fatal: failed to write object
    error: unpack failed: unpacker exited with error code
    To //civ3s012/gitrepos/best-practices/.git
     ! [remote rejected] master -> master (n/a (unpacker error))
    error: failed to push some refs to '//civ3s012/gitrepos/best-practices/.git'

The server is a windows machine, as is the client. No one else is having this problem - it seems to be a server permissions issue, but we've ruled that out as far as we can tell. Also, the fact that he can log into a different machine and push, using the same username, makes it seem like it's not server permissions. Any ideas what could be going wrong here?

Answer 1

Maybe he's created a branch in his local repo that already exists on the server and that ref can't be updated because it was created by someone else?

Answer 2

I know this is the easy-peasy sysadmin blowoff answer, but have you verified that his harddrive isn't full?

Answer 3

I'm not a windows user so I'm stabbing in the dark a little here. It looks like the remote file system is mounted and you're just pushing to that (not using ssh:// or git://). Is that FS somehow mounted readonly? Can he create/modify files on there (outside of git)?

Answer 4

Try adding this configuration variable to the remote repository:

 $ git config core.sharedRepository "all"
 $ git config receive.denyNonFastForwards True

These are usually set by the --shared option in git init, when the repo is set up.

I don't know how windows permissions interact, so I'm not sure that this is the solution. But I know that sometimes a linux user can create files with permissions that fail in a Git remote in exactly this way. It happened when they belong to the proper group but don't have it as their primary group. Setting the repo sharing to all gets around this.

This seems happen with shared repos imported from SVN or CVS.

Answer 5

Another brain dead answer. You sure you have permissions to read those files? Has happened to me a few times where I'll make a change as another user by mistake. Then later I can't push. Chown is your friend.

Answer 6

The problem ended up being a stored password for that share which allowed read access, but not write access. Even when we explicitly mounted the drive with the appropriate username and password, the stored password must have been used in the background, which made this difficult to track down. To clear the password, we went to Control Panel, User Accounts, clicked on Advanced, Manage Passwords, and removed the logon information for the server in question. After that, everything worked as it should. I'm accepting Pat Notz's answer, since it did end up being a read-only FS. Thanks!