There are several places in the code where git calls open() with the flag O_EXCL. This causes a problem for us when the current directory is on an NFS-mounted NTFS volume shared by an NAS fileserver. The open fails with "EACCES: Permission denied", even though the user has full read/write permissions on the target directory.
I used a tiny C program to confirm that the O_EXCL flag is the culprit; removing that flag from the open() call allows the open to succeed. Of course, the call also succeeds, with the O_EXCL flag in place, if the current directory is on an NFS-mounted UNIX filesystem.
We're looking into ways to work around this; one way would be to hack the git source and remove all the O_EXCL flags (are they really needed?), but I'm afraid that might break git in horrible ways. Another way might be to mount the NTFS volume via CIFS instead of NFS. But first I wanted to ask if anyone here can offer a solution based on changing our git configuration or our NFS mount options or the NTFS volume settings. (At present we have no gitconfig file, so all settings are default).
Git version is 1.6.5.3, running on x86_64 RHEL-4, kernel 2.6.9-89. The error the user sees is:
> cd /WWW > git init fatal: cannot copy '/usr/local/share/git-core/templates/info/exclude' to '/WWW/.git/info/exclude': Permission denied
Using strace, we can see the offending call:
open("/WWW/.git/info/exclude", O_WRONLY|O_CREAT|O_EXCL, 0666) = -1 EACCES (Permission denied)
We know the user has permission to create this file because he can cd into /WWW/.git/info and copy exclude there from the templates directory by hand.
-- Kai Lanz Stanford University School of Earth Sciences