Setgid Bit Not Preserved by Git on New Directory in '.Git' Folder

How to use group file permissions correctly on a git repository?

You need to set the setgid bit on the group as well.


chgrp -R GROUP /path/to/repo
find /path/to/repo -type d -print0 | xargs -0 chmod g+s

Prevent Git Push live master from changing file permission and ownership

You wrote a script, which, at some point, executes git checkout -- or an equivalent command -- that actually creates and updates files in your target folder.

You should make it so that this command is run with the user you want, for example :

sudo -u www-data git checkout ...

You may need to set the access rights on the repo itself so that user www-data can read the repo :

if your repo has r access for all users, you have nothing more to do,
you can decide to set the group of all files in that specific repo to www-data :
```
# in your post-receive script :
chrgp www-data -R .
```

or set the setgid bit on that repo's directory, so that files and directories created within automatically inherit this directory's group (instead of the user's group) :

# run once on your server, as root user :
$ chmod -R g+s /path/to/repo.git
$ chgrp -R www-data /path/to/repo.git

$ ls -ld /path/to/repo.git
drwxrwsr-x 9 root www-data 4096 janv. 13 14:20 repo.git
      ^
# notice the 's' in the access rights

How to force git to use specific permission settings when pushing via ssh

Check if the config core.sharedRepository could help in your target repo:

When group (or true), the repository is made shareable between several users in a group (making sure all the files and objects are group-writable).

But when it comes to ACL (Access Control Level) with git ssh, nothing is more easier or precise to put in place than gitolite (which is an authorization layer).

File Permission issues with sharing a GIT Remote Repository

git now has a core.sharedRepository option for exactly this purpose.

I recommend:

git config core.sharedRepository group

Then, to set the initial group ownership, do:

sudo chgrp -R somegroup .
sudo find -type d -exec chmod g+s {} +
sudo chmod -R g+rw .git/objects/

in the root of the repo.

For a new repo, you can do:

git init --shared=group

Only if the above doesn't work:

chgrp git -R repo.git 
find repo.git -type d -exec chmod g+rws {} +

s is the setgid flag. On directories, this means files and directories created within that directory have the same group (git in this case). Newly created subdirectories also inherit setgid.

This is similar to how the git repo is set up at my work. However, I agree you should consider an actual git server process.

Retaining file permissions with Git

The git-cache-meta mentioned in SO question "git - how to recover the file permissions git thinks the file should be?" (and the git FAQ) is the more staightforward approach.

The idea is to store in a .git_cache_meta file the permissions of the files and directories.

It is a separate file not versioned directly in the Git repo.

That is why the usage for it is:

$ git bundle create mybundle.bdl master; git-cache-meta --store
$ scp mybundle.bdl .git_cache_meta machine2: 
#then on machine2:
$ git init; git pull mybundle.bdl master; git-cache-meta --apply

So you:

bundle your repo and save the associated file permissions.
copy those two files on the remote server
restore the repo there, and apply the permission

How do I set SGID in PHP?

In the end, the only way I could find to obtain the permissions I need is to profit of the correct behaviour of mkdir() and avoid calling chmod() which appears to reset the SGID bit no matter what. The only way I can think of doing this is to change the umask with umask():

$myumask = umask(2);
mkdir("/mydir/test6");
umask($myumask);

This appears to work fine:

  4 drwxrwsr-x  2 www-data mygroup   4096 Oct  9 14:22 test6

This leaves me with the issue raised in the note of https://www.php.net/manual/en/function.umask.php: that all threads of a multithreaded webserver share the same umask, obviously leading to undesired and unpredictable behaviour. Luckily, in my case, I could ascertain that all directory creations are done in a monothreaded context (essentially, on the first test run of a script) and thus I feel safe. Hence, this is a useful workaround but not a general solution.

git: can't push (unpacker error) related to permission issues

I had this error for two weeks, and the majority of the solutions stated 'chmod -R' as the the answer, unfortunately for me my git repos (local / remote / shared - with team) were all on Windows OS, and even though chmod -Rv showed all the files changed to 'rwxrwxrwx', a subsequent 'ls -l' still showed all files as 'rwxr-xr-x' and the error repeated itself. I eventually saw this solution by Ariejan de Vroom. It worked and we were all able to pull and push again.

On both local (the local that is having trouble pushing) and remote repos, run the following commands:

$ git fsck
$ git prune
$ git repack
$ git fsck

On a side note, I tried using Windows' native file permissions / ACL and even resorted to elevating the problem user to Administrator, but none of that seemed to help. Not sure if the environment is important, but it may help someone with a similar setup - problem team member and remote (Windows Server 2008 R2 Standard), my local (Windows 7 VM).