The error: A service fails to start, or a process gets "Permission denied" trying to read/write a file — despite ls -l showing exactly the ownership and permissions you'd expect. chmod, chown, double- and triple-checking the obvious — nothing changes.
Environment: Any RHEL/CentOS/Rocky/Alma system with SELinux in Enforcing mode (the default).
Why this happens: SELinux enforces a second, completely separate permission model — security contexts — layered on top of standard Unix permissions. A file can have perfectly correct ownership and mode bits and still be denied if its SELinux context doesn't match what the accessing process is allowed to touch. This trips people up specifically because standard permission troubleshooting (ls -l, chmod) shows nothing wrong — the actual problem is invisible unless you know to look for it.
The fix:
- Confirm SELinux is actually the cause:
sudo ausearch -m avc -ts recent(or check/var/log/audit/audit.logdirectly) to see if a denial was actually logged around the time of the failure. - Check the file's current context:
ls -Z /path/to/file. - Check what context the service actually expects:
semanage fcontext -l | grep <servicename>, or check documentation for the expected context type. - If the context is wrong (common after moving a file into place with
mvinstead ofcp, sincemvpreserves the old context):sudo restorecon -v /path/to/fileresets it to the policy-defined default. - If there's a genuine, intentional need to allow something outside the default policy, generate a proper policy module rather than disabling SELinux:
audit2allow -a -M mypolicy, review the generated rule before applying it, thensemodule -i mypolicy.pp.
One thing worth knowing: the instinct to just run setenforce 0 and move on is the single most common mistake here. It "fixes" the immediate problem by disabling the entire security layer system-wide, which is a real reduction in your actual security posture, not a fix. restorecon first, a real policy module second, disabling SELinux never.