Record the failing operation, application account and time. Confirm the system uses SELinux and inspect its mode. Preserve audit evidence without sharing sensitive file names or data unnecessarily. Rule out ordinary ownership and permission errors as well.

1. Find the relevant AVC denial using the distribution's audit tools, such as a time-bounded ausearch query. Match the process, object and requested permission with the actual application failure.
2. Check file contexts and compare them with the documented location. Files copied from another path can retain an inappropriate label even when Unix permissions look correct.
3. For standard paths, restore the expected context through the supported restorecon workflow. For a legitimate custom path, define a persistent file-context mapping before applying it instead of relying on a temporary chcon change.
4. If the service needs a nondefault port or documented optional behavior, use the supported SELinux port labeling or narrowly appropriate boolean. Review its scope before enabling it.
5. Retest the exact operation and inspect new denials. Create a custom policy only after understanding why existing supported policy cannot cover the intended behavior.

On an SELinux-enabled server you administer, reproduce the specific failure once, note the time and inspect recent audit evidence. These commands display enforcement state, recent denials and the label of an example content directory. They do not change the policy.

getenforce
sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
ls -Zd /srv/example-site

Read the result: Match the denied operation, process context, target context and path to the application failure. A mismatch between the intended content role and its label can explain access denied even when ordinary Unix permissions appear correct. An unrelated denial is not evidence that this request needs a new allow rule.

Check the documented file-context or service setting for the identified case. Preserve the denial details before making a narrow correction. Do not disable enforcement or turn every audit message into a broad local policy merely to make a warning disappear.

Not universally. SELinux policy can constrain privileged processes too. Correct the intended policy and context rather than assuming a root-owned file or root process must be allowed.

Confirm the application works while the system remains enforcing and no unrelated access was granted. Verify the correction survives a relabel or reboot where relevant. Record the purpose of any persistent mapping or policy change.

Do not blindly feed every audit event into audit2allow or disable SELinux globally to suppress an error. That can permit unintended behavior alongside the legitimate operation. If the process is doing something unexpected, investigate the application or potential compromise before authorizing it.

• Investigating a failed systemd service
• Finding which process listens on a Linux network port
• Testing a persistent filesystem mount before reboot
• Investigating an out-of-memory process kill on Linux

• docs.redhat.com: Troubleshooting Problems Related To Selinux Using Selinux