Skip to main content
In this walkthrough you’ll learn how to identify and resolve SELinux denials by troubleshooting a real-world scenario: starting Apache (httpd) fails because SELinux policy prevents it from binding to a custom port and from reading web content. The steps cover:
  • Reproducing the failure
  • Inspecting system logs and AVC denials
  • Allowing httpd to bind to a custom TCP port
  • Fixing file context labels so httpd can read content
  • Verifying the service and content are accessible

​
1. Attempt to start Apache

Reproduce the failure by starting httpd:
Check the unit status to see why it failed:
The failure shows Permission denied when attempting to bind to port 9495 — this commonly indicates an SELinux denial on the network port. Check system logs for SELinux messages (on many distributions either /var/log/messages or journalctl):
The logs show setroubleshoot messages indicating SELinux prevented httpd from binding to TCP port 9495. setroubleshoot suggests running sealert for the full report. View the full sealert report (sample ID shown):
Alternatively, search for AVC denials directly with ausearch:
This confirms that httpd was denied name_bind for tcp port 9495.

​
3. Check current SELinux port labels for httpd

List the SELinux port types and filter for http-related entries:
Here you can see 9495 is not listed under http_port_t. SELinux will block httpd from binding to ports that are not labeled for the service by default.

​
4. Allow httpd to bind to port 9495

Add a port mapping so SELinux permits httpd to bind to your chosen port. Use the type appropriate for your use case; http_port_t is the common choice for general web server ports:
If semanage reports the mapping already exists, modify the existing mapping:
Verify the change:
Start httpd again and check status:
At this point the service runs, but attempting to fetch the site returns a 403 Forbidden. That indicates a separate SELinux denial — typically a file-label (context) issue preventing httpd from reading the files.

​
5. Verify HTTP access and file context

Attempt to fetch the index page:
Inspect the SELinux file context on the web content directory (example path /webcontent/html used here):
These entries are labeled default_t instead of the expected httpd_sys_content_t. That mismatch prevents httpd from reading the files under the default SELinux policy. Check the logs for related AVC denials:
You can also query AVC denials and suggest allow rules:

​
6. Relabel files so httpd can read them

To allow httpd to serve files from /webcontent, add a file-context rule mapping that path to httpd_sys_content_t and then apply the labels.
  1. Add the file-context rule (recursive pattern):
  1. Apply the new labels with restorecon:
Verify the updated labels:
Re-test access:
The page is now served correctly.

​
Quick reference — useful commands

On some systems the semanage command is provided by the policycoreutils-python-utils or policycoreutils-python package. Install it with your distribution package manager if semanage is not present (for example: dnf install -y policycoreutils-python-utils or yum install -y policycoreutils-python).
Be cautious when opening ports or changing file contexts. Only allow ports and contexts that are necessary for your service. If you are unsure, generate an SELinux policy module using audit2allow and review it before installing with semodule -i.

​
Recap and troubleshooting checklist

  • Use getenforce to confirm SELinux mode (Enforcing vs Permissive).
  • For port bind failures:
    • Inspect systemctl status and logs.
    • Use ausearch -m AVC and sealert for detailed SELinux denial messages.
    • Use semanage port -l to find the correct SELinux port type and add the port with semanage port -a -t <type> -p tcp <port>.
  • For file-access (403) errors:
    • Check file contexts with ls -Z.
    • Add a file-context rule with semanage fcontext and apply it with restorecon -R.
  • For creating temporary or permanent policy exceptions:
    • Collect the denial with ausearch and feed to audit2allow to create a local module (-M) and install it with semodule -i.
  • Always verify changes by restarting the service and testing access.
Following these steps allows you to diagnose SELinux denials, permit necessary actions safely, and restore correct file and port contexts while keeping SELinux enforcement intact.

Watch Video

Practice Lab