Permissions & Security (Chmod/Chown/ACLs/SELinux/AppArmor)

Stop SELinux from Silently Blocking Your Stuff

🧩 The Challenge

You’ve checked chmod, chown, and ls -l a dozen times, convinced the permissions are perfect. Still, that “Permission denied” error just laughs at you from the logs, especially after you’ve moved files, restored a backup, or set up a new service in an odd directory like /srv/my_new_app. And nobody tells you this isn’t a standard file permission problem. I’ve wasted hours on this before.

💡 The Fix

That sneaky Permission denied often isn’t about user or group permissions at all. It’s SELinux getting in the way because your file or directory has the wrong security context. There’s a quick way to fix it for specific files, and a proper way to make it stick across reboots or restorecon runs.

# Fix temporarily (until restorecon or file system relabel)
chcon -R --reference=/var/www/html/ /srv/my_new_app/
# Or set explicitly for http content
chcon -R -t httpd_sys_content_t /srv/my_new_app/

# Make it persistent for new paths or restorecon runs
semanage fcontext -a -t httpd_sys_content_t "/srv/my_new_app(/.*)?"
restorecon -Rv /srv/my_new_app/

⚙️ Why It Works

Standard chmod and chown handle DAC (Discretionary Access Control). SELinux adds MAC (Mandatory Access Control), using security contexts to label files and processes. When your web server process (e.g., httpd_t) needs to read content, but the file is labeled default_t, SELinux blocks it cold. This happens even if ‘other’ permissions would normally allow read access. chcon changes the label temporarily. semanage fcontext registers a rule that tells SELinux how files in that path should be labeled, and restorecon applies those rules.

🚀 Pro-Tip: ls -Z shows you contexts. And for stubborn issues, audit2allow -a often gives the exact fix.

Linux Tips & Tricks | © ngelinux.com | 10/19/2026