Recently I encountered a puzzling permission issue where a user (ftpadmin) couldn't access a directory despite having proper group membership. Here's the complete breakdown of the situation:

# User group membership
$ id ftpadmin
uid=10001(ftpadmin) gid=2525(fsg) groups=2525(fsg),10005(git)

# Directory permissions
$ ls -al /home/git/
drwxrwxrw- 6 git git 4096 Apr 26 09:20 .
drwxrwxr-x 7 git git 4096 Apr 20 14:17 fsg

At first glance, everything appears correctly configured:

• The user belongs to the git group
• The parent directory has 770 permissions (rwxrwx---)
• The target directory has 775 permissions (rwxrwxr-x)

Yet, the user still receives "Permission denied" errors when trying to list directory contents.

On Red Hat systems, SELinux often interferes with seemingly correct permissions. To check the current context:

$ ls -Z /home/git/
drwxrwxrw-. git git unconfined_u:object_r:user_home_dir_t:s0 .
drwxrwxr-x. git git unconfined_u:object_r:user_home_dir_t:s0 fsg

The solution involves updating the SELinux context:

$ sudo semanage fcontext -a -t git_content_t "/home/git(/.*)?"
$ sudo restorecon -Rv /home/git

If SELinux isn't the issue, consider these other possibilities:

1. Sticky Bit Problems:

$ ls -ld /home
drwxr-xr-x. 5 root root 4096 Apr 20 14:17 /home

2. Parent Directory Execute Permissions:

$ chmod g+x /home/git

3. Filesystem Mount Options:

$ mount | grep /home
/dev/sda1 on /home type ext4 (rw,noexec,nodev,nosuid)

Here's a comprehensive troubleshooting checklist:

# 1. Verify group membership
$ groups ftpadmin

# 2. Check effective permissions
$ getfacl /home/git/fsg

# 3. Test with direct path
$ sudo -u ftpadmin ls -l /home/git/fsg

# 4. Examine process context
$ ps auxZ | grep ftpadmin

# 5. Check SELinux denials
$ sudo ausearch -m avc -ts recent

To avoid similar issues in the future:

# Create proper directory structure
$ sudo mkdir -p /srv/git
$ sudo chown -R git:git /srv/git
$ sudo semanage fcontext -a -t git_content_t "/srv/git(/.*)?"
$ sudo restorecon -Rv /srv/git

This approach ensures proper permissions from the start while maintaining security best practices.

---

I recently encountered a frustrating scenario where a user (ftpadmin) couldn't access a directory despite having proper group permissions. Here's the complete breakdown:

-bash-3.2$ id ftpadmin
uid=10001(ftpadmin) gid=2525(fsg) groups=2525(fsg),10005(git)

The directory in question had these permissions:

drwxrwxr-x   7 git      git          4096 Apr 20 14:17 fsg

At first glance, everything appears correct:

• The ftpadmin user belongs to the git group
• The fsg directory grants read/execute permissions to group members
• Yet, attempting to list the directory results in:

-bash-3.2$ ls -al /home/git/
ls: /home/git/fsg: Permission denied

The first thing I verified was the parent directory permissions:

drwxrw-rw-   6 git      git          4096 Apr 26 09:20 git

Even after updating them to:

drwxrwxrw-   6 git      git          4096 Apr 26 09:20 git

The issue persisted. This suggested the problem might be more nuanced.

After extensive testing, I discovered several critical factors:

1. SELinux Context:

   ls -Z /home/git/
   drwxrwxrw-. git git unconfined_u:object_r:user_home_dir_t:s0 git
   

   The solution was to update the SELinux context:

   chcon -R -t httpd_sys_content_t /home/git/fsg
   

2. Group Membership Verification:

   getent group git
   git:x:10005:ftpadmin
   

   Sometimes you need to explicitly refresh group membership:

   newgrp git
   

3. Filesystem ACLs:

   getfacl /home/git/fsg
   

   If present, they might override standard permissions.

Here's the complete set of commands that resolved the issue:

# 1. Verify and update group membership
sudo usermod -a -G git ftpadmin
su - ftpadmin
newgrp git

# 2. Set directory permissions
sudo chmod -R 775 /home/git/fsg
sudo chown -R git:git /home/git/fsg

# 3. Handle SELinux if enabled
sudo semanage fcontext -a -t httpd_sys_content_t "/home/git/fsg(/.*)?"
sudo restorecon -Rv /home/git/fsg

# 4. Verify access
ls -la /home/git/fsg

This comprehensive approach ensures all permission layers are properly configured for RedHat-based systems.