Unable to open primary script

The Ultimate Fix for ‘Unable to Open Primary Script Permission Denied’ on CentOS 8 (Solving the SELinux Headache)

Welcome back to Darren’s Tech Tutorials! If you’ve ever tried setting up a complex web application—like Moodle, WordPress, or any custom PHP site—on a fresh CentOS 8 server, you’ve likely run into a frustrating wall of error messages.

I recently faced this exact issue while getting a Moodle installation up and running. Everything seemed right: files were downloaded, the database was configured, but when I hit the URL, all I got was a big, fat permission denial error.

If you are seeing the error “unable to open primary script permission denied” when trying to access your site’s index file, you might be banging your head against standard file permissions (chmod/chown). But let me save you the trouble: the true culprit on CentOS 8 is often SELinux.

In this guide, we are going to dive deep into why this error occurs and, more importantly, give you two simple, actionable commands to fix it instantly—for good!

Understanding the Permission Denied Mystery

When your web server (usually Apache or Nginx) tries to execute the core PHP file for your application (like index.php), it needs permission not just from the standard Linux permission system, but also from the security layer provided by SELinux.

Checking the Apache Logs

If you’re dealing with this issue, the browser might show a generic “Forbidden” message or a blank page. The real diagnostic gold is found in your server logs (typically located in /var/log/httpd/error_log on CentOS).

This is what I saw when I hit the problem:

unable to open primary script:
'/var/www/html/moodle/index.php (Permission denied)

This message confirms that Apache knows where the file is but is being blocked from accessing or executing it. This is a massive hint that the standard file owner/group settings are insufficient.

The Culprit: Security-Enhanced Linux (SELinux)

CentOS, like many Red Hat-based distributions, uses SELinux by default. SELinux is a powerful security mechanism that enforces Mandatory Access Control (MAC). It’s designed to isolate processes and prevent malicious code from accessing system resources.

While this is excellent for security, it often prevents the Apache process (which runs under a specific SELinux context) from reading or executing files that haven’t been explicitly labeled with the correct permissions context.

For a quick and effective fix, especially in testing, development, or controlled environments, we can instruct SELinux to step aside. We have two ways to do this: temporarily or permanently.

Solution 1: Temporarily Disabling SELinux (The Quick Fix)

If you need to get your application running right now to test configurations or finish an install, you can temporarily set SELinux to Permissive mode. This means it will log warnings but will not enforce its security policies.

You can do this without rebooting the server using the setenforce command:

Step 1: Execute the Temporary Disable Command

Run the following command as a root user or with sudo:

sudo setenforce 0

After running this command, immediately try accessing your web application again. It should load!

⚠️ Important Note: Setting SELinux to 0 using setenforce only lasts until the next server reboot. If you reboot, SELinux will return to the setting specified in its configuration file.

Solution 2: Permanently Disabling SELinux (The Long-Term Fix)

For many developers and those running servers in controlled internal environments, permanently disabling SELinux is the most hassle-free solution. This ensures that you won’t encounter this permission denial error again after a maintenance reboot.

Step 1: Open the SELinux Configuration File

You need to edit the main SELinux configuration file, usually located at /etc/selinux/config. Use your preferred text editor (like nano or vi):

sudo vi /etc/selinux/config

Step 2: Edit the SELINUX Variable

Inside the configuration file, you will look for the line that defines the SELINUX mode. It likely currently looks like this:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=enforcing

Change the value from enforcing to disabled:

SELINUX=disabled

Save the file and exit the editor.

Step 3: Reboot the System

For this change to take effect permanently, you must reboot your server:

sudo reboot

Once the system has restarted, SELinux will be completely disabled, and your web application (whether it’s Moodle, a custom PHP script, or anything else) will no longer face the ‘unable to open primary script permission denied’ error!

Wrapping Up and Getting Back to Work!

That’s all there is to it! Dealing with permission errors can be incredibly time-consuming, but when you know that SELinux is the common culprit on CentOS systems, the fix is literally just a couple of simple commands. Now you can get back to installing Moodle, configuring your database, or finishing whatever awesome project you were building.

If this guide saved you hours of troubleshooting, please make sure to give this post a thumbs-up and subscribe to Darren’s Tech Tutorials for more clear, actionable guides! Happy coding!