Diagnosing and fixing permission problems

The idea

“Permission denied” is an answer, not a diagnosis. Work through the same checklist every time and the cause appears quickly.

1. Who am I? id shows the user, primary group and supplementary groups the process really has. A group added with usermod -aG takes effect only at the next login.
2. Can I reach the file? You need x on every directory in the path. namei -l /full/path prints each component’s owner and mode, so the broken one stands out.
3. Is the mode right for what I’m doing? Reading a file needs r; writing needs w; running needs x; listing a directory needs r on it; creating or deleting entries in a directory needs w and x on the directory.
4. Who owns it? ls -ld. Fix with chown user:group or chgrp.
5. Is there an ACL? A + after the mode in ls -l means extra rules: getfacl FILE.
6. Is something other than permissions involved? Mount options (ro, noexec, nosuid), SELinux (ls -Z, ausearch -m avc), file attributes (lsattr), or, on NFS, the server.

Shared directories: setgid

For a team that edits each other’s files, three things must be true:

Need	Mechanism
Only the team may enter	Directory owned root:developers, mode 770
New files get the team’s group, not the creator’s	setgid bit on the directory (chmod g+s, or 2770)
Team members can modify each other’s files	New files are group-writable: umask 002, or a default ACL

The setgid bit on a directory makes new files and subdirectories inherit its group, and new subdirectories inherit setgid too. But the mode of a new file is the creator’s umask applied to 666, and the usual umask 022 removes group write, so inherited group alone does not let teammates edit. On RHEL, regular users whose primary group matches their name get umask 002 from /etc/profile.d//etc/bashrc, but you should not rely on that.

A default ACL on the directory is the robust fix: setfacl -d -m g:developers:rwx /srv/projects gives every new entry that group’s access regardless of umask.

ACLs in two commands

setfacl -m u:erin:r file          # give erin read access
setfacl -m g:auditors:rx dir      # give a group read and enter
setfacl -x u:erin file            # remove one entry
setfacl -b file                   # remove all ACL entries
getfacl file                      # list owner, group, ACL entries and the mask

The mask entry caps the permissions of named users and groups; getfacl shows the effective rights when the mask is narrower. If an ACL does not seem to work, check the mask.

The sticky bit

On a shared directory like /tmp (mode 1777, shown as drwxrwxrwt), the sticky bit means only a file’s owner (or root) can delete or rename it, even though everyone can write there. Use it when many users must add files to one place but not remove each other’s.

Try it

sudo mkdir -p /srv/lab/a/b && echo hello | sudo tee /srv/lab/a/b/file.txt
sudo chmod 700 /srv/lab/a
sudo -u alex cat /srv/lab/a/b/file.txt
namei -l /srv/lab/a/b/file.txt

cat: /srv/lab/a/b/file.txt: Permission denied
f: /srv/lab/a/b/file.txt
dr-xr-xr-x root root /
drwxr-xr-x root root srv
drwxr-xr-x root root lab
drwx------ root root a
drwxr-xr-x root root b
-rw-r--r-- root root file.txt

The file is world-readable, yet denied: directory a is drwx------. namei -l shows it at a glance.

A shared project directory

sudo groupadd developers
sudo usermod -aG developers alex
sudo usermod -aG developers dana
sudo mkdir -p /srv/projects
sudo chown root:developers /srv/projects
sudo chmod 2770 /srv/projects
sudo -u alex touch /srv/projects/plan.txt
ls -ld /srv/projects
ls -l /srv/projects

drwxrws---. 2 root developers 22 Nov  3 12:41 /srv/projects
total 0
-rw-r--r--. 1 alex developers 0 Nov  3 12:41 plan.txt

The s in the group triplet is setgid. The file’s group is developers (inherited), but it is -rw-r--r--: dana can read it and not edit. Now the default ACL:

sudo setfacl -d -m g:developers:rwx /srv/projects
sudo -u alex touch /srv/projects/new.txt
getfacl /srv/projects
ls -l /srv/projects/new.txt

# file: srv/projects
# owner: root
# group: developers
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:group:developers:rwx
default:mask::rwx
default:other::---

-rw-rw----+ 1 alex developers 0 Nov  3 12:44 new.txt

Note the + and -rw-rw----: the new file has group write and no access for others.

One extra reader

sudo setfacl -m u:erin:r /srv/projects/plan.txt
getfacl -c /srv/projects/plan.txt

user::rw-
user:erin:r--
group::r--
mask::r--
other::---

Beyond mode bits

Symptom	Layer	Check
Read-only file system	Mount	findmnt -no OPTIONS -T FILE shows ro
Script with x bit says Permission denied	Mount	noexec in the options
Modes right, service still denied	SELinux	ls -Z, sudo ausearch -m avc -ts recent
Operation not permitted even as root	Attribute	lsattr FILE shows i (immutable): chattr -i
Fine locally, denied over NFS	Server	UID mismatch, export options, root squash

Going further

chmod -R with a capital X (chmod -R g+rX dir) adds execute only to directories and already-executable files, which is what you want for recursive fixes. find /srv -nouser -o -nogroup finds files whose owner no longer exists, typically after deleting a user. restorecon -Rv repairs SELinux labels after moving files; moved files keep their old label, copied files get the destination’s. getfacl -R src | setfacl --restore=- copies ACLs, and cp -a preserves them. stat FILE shows mode in octal, owner, timestamps and context in one view.