Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

I'm sharing a git repository with a friend over SSH. He pushes from and pulls to his git repository using my machine's SSH server, where the shared git repository is.

Problem is that when he pushes a commit, I can't pull, because the commit is janito users rwx------ (these are permission metadata).

I created a group called git, added him and myself, and the repository is jpmelos git rwxrwx---. How can I force files created in the repository directory to be <creator> git rwxrwx--- as well, so we can always pull and push without worrying about permissions?

Or you can suggest better solutions to the problem, of course. Restrictions are that we need to use the SSH on my machine (we are not ready to make the code public yet) and we are already pushing and pulling from a bare repository I created separately from my working repository.


share|improve this question
possible duplicate of Permission of saved files –  Gilles Nov 20 '11 at 0:32

5 Answers 5

Other things to consider:


To use pam to control umask, have UsePAM yes in sshd_config, and this in /etc/pam.d/sshd:

session    optional umask=0027


Read Gilles' post here. It includes install instructions. I don't know if it's a dupe question but that page is worth a read :-)

To fix acls in your already existing repository:

find git_repository/ -type d -exec setfacl -m d:g:git:rwx {}
find git_repository/ -f -exec setfacl -m g:git:rwx {}

quick and dirty: hook

Create a hook as previously mentioned, edit git_repository/hooks/post-update to be:

chmod -R g+w . 2>/dev/null
chgrp -R git . 2>/dev/null

That'll fix things after each update and will probably do fine for a small repository and 2 users. Probably not for larger, busy repositories ;-)

share|improve this answer

The umask issues can be taken care with the core.sharedRepository Git configuration variable:

( cd /path/to/shared-repository.git &&
git config --bool core.sharedRepository true

Whenever Git creates a new file or directory, it will make sure the group bits are set appropriately (always group readable, group writable and executable when appropriate—even if the invoking user’s umask is overly “wide”).
Note: The core.sharedRepository setting only applies to entries Git itself makes, so it will not help set the permissions of entries in the working tree of a non-bare repository. You will have to set your umask manually for that.

You can make new files and directories be group-owned by your git group by setting the setgid bit on the directories (after chgrping the file and directories to the appropriate group).

chgrp -R git /path/to/shared-repository.git &&
find /path/to/shared-repository.git -type d -exec chmod g=rwxs '{}' \;

If you are creating a new repository from scratch, you can just chgrp an empty directory and run git init --shared on it (Git will set core.sharedRepository and do the chmod g=rwxs on the GIT_DIR):

mkdir new-shared.git &&
chgrp git new-shared.git &&
git init --bare --shared new-shared.git
share|improve this answer

You should probably check out gitosis.

Under this system a special git account is created to host all your repositories. As the gitosis admin you just add your users' ssh public keys in order grant access. Your git urls end up looking like this:


All users connect using the git user account but it's secure because shell access isn't allowed. Instead all access is forced to go through gitosis which can regulate and secure access to individual git repositories in a configurable way. And your permission problem doesn't come up because only the single git user ever actually interacts with the file system.

share|improve this answer
Gitosis is no longer actively developed (or maintained). You might want to consider recommending Gitolite instead. –  Chris Johnsen Nov 20 '11 at 8:39

I think this could be done by writing a custom script as a Git hook—any scripting language will do as long as everyone cloning the Git repo can use it. Read about Git hooks at Pro Git.

share|improve this answer

What is your friend's umask setting? Have him type umask at his command prompt on your server and see what comes up. If it reads 0077 (or 077), that's likely the problem, because that means "when creating files, clear all permission bits for group or other".

A more appropriate umask would be 0027, which will allow group read and execute permissions on created files. He can set this temporarily by running umask 0027, or permanently by adding it to his ~/.profile or ~/.bash_profile.

share|improve this answer
This won't quite solve the problem... It will create janito users rwxr-x--- files, but I want only users in the group git to have access to those files. So, I need janito git rwxrwx---. –  jpmelos Nov 19 '11 at 20:31
Ah, yes! You can't use the filesystem to force permissions, but you can force group ownership. Run chmod g+s on your .git directory and all of its subdirectories. –  Jander Nov 20 '11 at 8:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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