When multiple developers collaborate on a shared Linux repository, file permissions become critical. The specific pain point occurs when:

• New files inherit the creator's primary group instead of the project group
• Manual chgrp operations become tedious
• Git operations don't respect the desired group settings

Here's the complete toolkit for solving this:

# 1. Verify existing group membership
groups
# 2. Check current umask
umask
# 3. View directory permissions
ls -ld /path/to/project

The most robust approach sets the SGID (Set Group ID) bit on the directory:

sudo chown :mygroup /path/to/project
sudo chmod g+s /path/to/project
umask 0002  # Set in shell startup files

For git repositories, add these hooks to maintain consistency:

# .git/hooks/post-checkout
#!/bin/sh
find . -type d -exec chmod g+s {} +
find . -type f -exec chmod g+rw {} +

When standard permissions aren't sufficient:

sudo setfacl -d -m g:mygroup:rwx /path/to/project
sudo setfacl -m g:mygroup:rwx /path/to/project

After implementation, test with:

touch newfile.txt
ls -l newfile.txt
# Should show:
# -rw-rw-r-- 1 username mygroup 0 Aug 1 10:00 newfile.txt

When multiple developers collaborate on a shared Linux directory (like a git repository), we often encounter permission issues where newly created files inherit the creator's primary group rather than the project's designated group. This creates maintenance overhead with repeated chgrp operations.

The complete solution combines three Linux features:

• SGID bit: Forces new files to inherit parent directory's group
• umask 002: Ensures group-writable permissions
• ACLs: Advanced permission management (optional)

First, set up the directory with proper group ownership and permissions:

# Set directory ownership
sudo chown -R :mygroup /path/to/project

# Apply SGID bit (2 in numeric mode)
sudo chmod g+s /path/to/project

# Verify with ls -ld
ls -ld /path/to/project
# Should show 'drwxrwsr-x' with 's' in group permissions

For SSH sessions, add this to ~/.bashrc:

# Set umask when entering project directory
cdproj() {
    cd /path/to/project && umask 0002
    echo "Active umask 0002 for project work"
}

For git repositories, core.sharedRepository provides additional control:

# Configure git to maintain group permissions
git config core.sharedRepository group
git config receive.denyNonFastForwards true

Create test files to verify the setup:

touch newfile.txt
mkdir newdir
ls -l 
# Should show:
# -rw-rw-r-- 1 user mygroup 0 Aug  1 10:00 newfile.txt
# drwxrwsr-x 2 user mygroup 4096 Aug  1 10:00 newdir/

For more complex scenarios, consider ACLs:

# Set default ACL rules
setfacl -d -m g:mygroup:rwx /path/to/project

# Verify settings
getfacl /path/to/project