When setting up Apache on Fedora 16, many developers encounter the frustrating "Permission denied" error even after setting proper file permissions (777 in extreme cases). The root cause typically lies in SELinux (Security-Enhanced Linux), which implements mandatory access controls beyond traditional Unix permissions.

First, let's check the current SELinux context of your web directory and files:

ls -Z /var/www/html/
ls -Z /var/www/html/files/

You should see output like this for proper web server access:

drwxr-xr-x. apache root system_u:object_r:httpd_sys_content_t:s0 files

If the context doesn't show httpd_sys_content_t, run these commands:

sudo chcon -R -t httpd_sys_content_t /var/www/html/
sudo restorecon -Rv /var/www/html/

For uploaded files that need write access (like upload directories):

sudo chcon -R -t httpd_sys_rw_content_t /var/www/html/uploads

If you're in a development environment and need to temporarily disable SELinux enforcement (not recommended for production):

sudo setenforce 0

To make this permanent (until next reboot):

sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config

After applying the context changes, test your configuration:

curl -I http://localhost/files/SRR022918.errors.tar.gz
sudo ausearch -m avc -ts recent

The latter command checks for any remaining SELinux denials in the audit logs.

For production systems, create a custom SELinux policy module:

sudo grep httpd /var/log/audit/audit.log | audit2allow -M mypolicy
sudo semodule -i mypolicy.pp

This creates a persistent policy that survives reboots and maintains system security.

---

When you encounter a 403 Forbidden error in Fedora despite correct file permissions (644/755), SELinux is almost certainly the culprit. The key diagnostic clue is the (13)Permission denied in your error logs - this numeric code specifically indicates SELinux enforcement.

# Quick diagnostic command:
ls -Z /var/www/html/files/
# Expected output shows security context:
-rw-r--r--. apache users unconfined_u:object_r:httpd_sys_content_t:s0 SRR022918.errors.tar.gz

Fedora's default SELinux policy requires web-accessible files to have the httpd_sys_content_t context. Common problematic scenarios:

• Files copied from /home retain user_home_t context
• Downloads via wget/curl get user_tmp_t context
• External drives mount with default_t context

Method 1: Restore default contexts

sudo restorecon -Rv /var/www/html/
# -R recursive, -v verbose

Method 2: Apply proper context manually

sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html/files(/.*)?"
sudo restorecon -Rv /var/www/html/files/

Method 3: Alternative quick fix (not recommended for production)

sudo chcon -R -t httpd_sys_content_t /var/www/html/files/

Verify SELinux denials in audit logs:

sudo ausearch -m avc -c httpd --start recent

Check boolean settings that may affect access:

getsebool -a | grep httpd
# Important flags:
httpd_unified --> on
httpd_use_nfs --> off
httpd_anon_write --> off

For upload directories requiring write access:

sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"
sudo restorecon -Rv /var/www/html/uploads
sudo setsebool -P httpd_unified 1