How to troubleshoot 'permission denied' errors while accessing files in linux?

Question

My question is concerning generic troubleshooting when getting 'permission denied' errors while accessing files as certain user and here is a specific example where I could use some extra help:

As a user 'builder' I have a folder 'repo' in my home dir that belongs to group 'builders'. It currently reads as follows:

$ pwd
/home/builder/repo
$ ls -la
total 4
drwxr-sr-x 2 builder builders  20 Jun  9 02:28 .
drwxr--r-- 4 builder builder  123 Jun  7 23:36 ..
-rw-rw-r-- 1 builder builders   5 Jun  9 02:18 status

So, I can see that everyone who is in the 'builders' group should be able to access that 'status' file. It should be noted, that as 'builder' user I can read it, file is not corrupted and readable, i.e. cat /home/builder/repo/status returns its contents.

However, for some reason I can't access it as another user - 'ec2-user' who happens to be in the builders group:

$ whoami
ec2-user
$ groups
ec2-user adm wheel systemd-journal docker builders
$ ls -la /home/builder/repo/status
ls: cannot access /home/builder/repo/status: Permission denied
$ cat /home/builder/repo/status
cat: /home/builder/repo/status: Permission denied

I'm obviously missing something, but I'm still stuck trying to answer why user belonging to the same group can't access that file. Is there something else that can tell me what I need to do (e.g. as superuser or owner) to properly grant group access permission to a dir/file - or just find out why read permissions not working for some user? The only answer I found for myself is just carefully inspecting ownership info and access control bits, but in the example above everything looks good.

Solution

You get the permission denied error because the /home/builder directory is missing the x (execution) bit for group and others. This prevents that group members and others can change into the /home/builder directory or access anything beneath.

Depending on what if that was just set accidentally, you could just add the x (execution) bit for group to /home/builder

chmod g+x /home/builder  

If you want group members to only access subfolders and prevent them from listing the contents of /home/builder, you could add the x (execution) bit and remove the r (read) bit from the folder.

chmod g+x,g-r /home/builder

You also might want to change the permissions for o (others) as above or remove it completely.

---

For such problems namei is very helpful as it can display all the permissions of a file down the path. You should run that as a user that has access to get the desired output.

# namei -olm /tmp/test/testdir/status 
f: /tmp/test/testdir/status
dr-xr-xr-x root root /
drwxrwxrwt root root tmp
drwxr-x--x root root test
drwxr-xr-x root root testdir
-rw-r--r-- root root status

Comments

[Davidw]

It might not be relevant, but what is that s in the group permission for the . file?

[Alex]

That makes nested files and directories to inherit that directory's group.

[ivanivan]

@Davidw that represents the SETGID bit which does as Alex says - any newly created files/directories under it will inherit the group ownership. Quite useful for things like this where default is to create new files owned by the user's primary group but you need to share all files across a group.

[ivanivan]

That namei is a cool tool, and new to me (and been using linux for 20 years!) Very nice answer, with the bonus info

[Alex]

Thanks for the hint, I tried namei with chmod g+x. Maybe I'm missing something very obvious but I don't see why I still can't read file (even though everybody should have r permission) - snippi.com/s/ljay902 I could attribute it to NFS quirkiness had I had this file on the remote disk but it happens to be on the local filesystem.

[Alex]

My mistake was that I didn't set up permission for home folder. I thought that it is only an immediate folder I should set x-permission for.