You upgraded your web server and the browser returns 403
You install Apache or Nginx on a fresh Fedora system, point it to a custom project directory, and reload the service. The browser returns a 403 Forbidden error. The access log shows nothing. The error log shows nothing. The service is running, the ports are open, and the standard ls -l permissions look correct. SELinux is standing between your web server and the files it needs to serve. A botched policy change can leave your site completely unreachable. Run these commands from a test container or a backup VM first if you can.
What is actually happening
Linux permissions you know from chmod and chown are discretionary access controls. The file owner decides who gets in. SELinux adds mandatory access controls. The kernel decides. Every process runs in a security domain. Apache runs as httpd_t. Nginx runs as httpd_t. By default, that domain can only read files labeled httpd_sys_content_t and can only bind to ports labeled http_port_t. It cannot read your home directory. It cannot connect to a backend database on port 5432. It cannot relay traffic to another server. The kernel blocks the system call before the web server ever gets a chance to log it.
Think of discretionary permissions as a keycard for the building. SELinux is the security guard checking your badge against a list of which rooms you are allowed to enter. You can have the keycard, but the guard will still stop you at the door. Fedora ships with SELinux in enforcing mode by default. That is intentional. It stops misconfigured services from leaking data or executing arbitrary code. Your job is to tell the policy exactly what your web server is allowed to do, not to disable the guard.
Run journalctl -xe first. Read the actual error before guessing.
The fix
Start by finding the exact denial. SELinux writes every blocked action to the audit log. The setroubleshoot service translates those raw audit messages into human-readable summaries. Fedora's release cadence is six months, and policy updates ship regularly. Always refresh your package cache before applying policy changes.
Here is how to pull the recent denials and read the explanation.
sudo journalctl -xe | grep -i denied # Filter the enhanced journal for SELinux denials
sudo ausearch -m avc -ts recent # Pull raw audit events from the last few minutes
sudo sealert -a /var/log/audit/audit.log # Generate a readable report with automatic fix suggestions
The output will tell you exactly what was blocked. A file access denial looks like type=AVC msg=audit(...): avc: denied { read } for pid=... comm="nginx" name="index.html" scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0. A network connection denial looks like denied { name_connect } for ... saddr=... sport=... taddr=... tport=5432.
Fix the file context first if the denial mentions tcontext ending in user_home_t, default_t, or unconfined_t. Web servers need the correct label to read directories. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
Here is how to apply the correct label to a custom web root and make it survive a reboot.
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/myapp(/.*)?" # Define the label rule for the directory and everything inside it
sudo restorecon -Rv /var/www/myapp # Apply the new label to existing files and directories
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/myapp/uploads(/.*)?" # Allow read-write access only for specific upload directories
sudo restorecon -Rv /var/www/myapp/uploads # Apply the read-write label to the upload folder
Fix the boolean if the denial mentions name_connect, name_bind, or net_raw. Booleans are toggle switches in the SELinux policy that allow specific behaviors without rewriting the entire policy. dnf upgrade --refresh is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Don't conflate them. Policy changes persist across normal upgrades.
Here is how to enable outbound connections for your web server permanently.
sudo setsebool -P httpd_can_network_connect on # Allow httpd_t to initiate outbound TCP and UDP connections
sudo setsebool -P httpd_can_network_relay on # Allow httpd_t to act as a reverse proxy or relay traffic
sudo setsebool -P httpd_unified on # Merge Apache and Nginx contexts so they share the same file access rules
The -P flag writes the change to the policy store. Without it, the toggle resets to default on the next reboot. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux.
Reboot before you debug. Half the time the symptom is gone.
Verify it worked
Check the boolean state and the directory labels before restarting the service. systemctl status <unit> shows recent log lines AND state in one view. Always check status before restart.
Here is how to confirm the policy changes and file labels are active.
getsebool httpd_can_network_connect # Verify the boolean is currently on
getsebool -a | grep httpd_unified # Check all httpd-related booleans at once
ls -Zd /var/www/myapp # Show the SELinux context of the directory
ls -Z /var/www/myapp/index.html # Verify the file inherited the correct label
Restart the web server and test the endpoint. If the 403 error disappears and the backend connection succeeds, the policy is working. If the denial returns, check the journal again. SELinux will tell you exactly what changed. firewall-cmd --reload after every rule change. Otherwise the runtime config and the persistent config diverge.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and what the error looks like
Disabling SELinux entirely is the fastest way to create a security hole. Setting SELINUX=permissive in /etc/selinux/config stops the blocks but keeps the logging. Use permissive mode only for debugging. Switch back to enforcing once the policy is correct.
Editing files in /usr/lib/systemd/ or /usr/lib/nginx/ breaks on the next package update. Those directories ship with the RPM packages. Always place custom configurations in /etc/ or /etc/nginx/conf.d/. The package manager ignores /etc/ during upgrades and preserves your work.
Forgetting the -P flag on setsebool causes intermittent failures. The toggle works until the system reboots, then the web server loses network access again. Always use -P for persistent changes.
Confusing firewalld with SELinux wastes time. firewalld controls inbound and outbound traffic at the network layer. SELinux controls process capabilities and file access at the kernel layer. A Connection refused error usually means the service isn't listening or the firewall is dropping packets. A Permission denied or 403 Forbidden with no application log entry means SELinux is blocking the file or socket access.
Here is how to isolate a network-level block from a policy-level block.
sudo firewall-cmd --list-all # Show active zones and allowed services
sudo ss -tlnp | grep :80 # Verify the web server is actually listening on the port
sudo ausearch -m avc -ts recent | grep nginx # Check if the kernel blocked the socket creation
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use this vs alternatives
Use semanage fcontext and restorecon when your web server needs to read or write files outside the default /var/www/html directory. Use setsebool when your web server needs to connect to databases, call external APIs, or proxy requests to backend services. Use audit2allow and semodule when you are building a custom application that requires highly specific socket or capability access not covered by standard booleans. Stay in enforcing mode when you want the kernel to actively block unauthorized access and protect against zero-day exploits. Switch to permissive mode only when you are debugging a complex policy failure and need to see what would be blocked without actually stopping the process.
Snapshot the system before the upgrade. Future-you will thank you.