Every time I do git pull or git reset, git resets changes to permissions and ownership I made. See for yourself:

#!/usr/bin/env bash
rm -rf 1 2

mkdir 1
cd 1
git init
echo 1 > 1 && git add 1 && git ci -m 1

git clone . ../2
cd $_
chmod 0640 1
chgrp http 1

cd ../1
echo 12 > 1 && git ci -am 2

cd ../2
stat 1
git pull
stat 1

The output:

$ ./1.sh 2>/dev/null | grep -F 'Access: ('
Access: (0640/-rw-r-----)  Uid: ( 1000/    yuri)   Gid: (   33/    http)
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    yuri)   Gid: ( 1000/    yuri)

Is there a way to work around it?

I want to make some files/directories accessible for writing by the web server.


This sounds like the user you're running has the default group set to yuri. You can confirm this like so:

$ id -a
uid=1000(saml) gid=1000(saml) groups=1000(saml),10(wheel),989(wireshark)

The UID of your account is this: uid=1000(saml) whereas the default group is git=1000(saml) and any secondary groups are thereafter.

NOTE: If you want the git clone to have specific ownership, then you have at least 2 options.

Option #1

Set a parent directory with the permissions as you want like so:

$ mkdir topdir
$ chgrp http topdir
$ chmod g+s topdir

$ cd topdir
$ git clone ....

This forced the directory topdir to enforce any child directories underneath it to have the group http applied. This will work by in large but can lead to problems, since if you move files into this git clone workspace, those files will not have their groups enforced by the changes made above.

Option #2

Prior to doing work, change your default group to http like so:

$ newgrp http
$ git clone ...

This method will force any new files created to have their group set to http instead of your normal default group of yuri, but this will only work so long as you remember to do a newgrp prior to working in this workspace.

Other options

If neither of these seem acceptable you can try using ACLs instead on the git workspace directory. These are discussed in multiple Q&A's on this site, such as in this Q&A titled: Getting new files to inherit group permissions on Linux.

  • First, you must be meaning newgrp. Then, does it change group for current shell only? And lastly, the point was to make only specific files/directories accessible for writing by web server. After all, I should probably fix them manually, or set up some git hook... – x-yuri Oct 11 '14 at 9:14
  • @x-yuri - yes sorry it's 5am here and I'm about to go to bed 8-). Yes this only persists for the current shell, so that would be a downside to that approach. If you're intending for only certain access for the webserver then that's going to be tricky, and you'll likely want to use ACLs then. Also you might want to add these details to your Q. As it is, it's unclear what your intended purpose is, so I can only answer you in non-specific terms. – slm Oct 11 '14 at 9:16
  • 1
    @x-yuri - a post update hook like this may be more apt: stackoverflow.com/questions/9613545/… – slm Oct 11 '14 at 9:22
  • 1
    @x-yuri - controlling permissions is discussed in the git book under hooks: git-scm.com/book/en/Customizing-Git-Git-Hooks – slm Oct 11 '14 at 9:24
  • I don't actually see how changing group for only current shell may be a downside, to be honest. I was concerned about it not changing the way the rest of apps work. – x-yuri Oct 11 '14 at 10:05

The solution I use is to run the command as the user that has the permissions you want to keep:

sudo -u user command

This keeps the permissions from changing. I use it when updating git repositories on my VPS, while keeping the file permissions set to the webserver user.

See also the same question here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.