Resolving "Client Denied by Server Configuration" Error in Apache 2.4.6 with PHP FPM on Ubuntu Server

Problem Context and Error Analysis

After upgrading Ubuntu Server from 13.04 (Raring Ringtail) to 13.10 (Saucy Salamander), Apache 2.4.6 configuration encountered compatibility issues preventing proper PHP file loading. The error log reveals the critical message: [authz_core:error] [pid 8294:tid 139804573181696] [client 81.219.59.75:3536] AH01630: client denied by server configuration: /usr/lib/cgi-bin/php5-fcgi. This indicates that Apache's authorization core module is denying client access requests to the PHP FastCGI handler.

Apache 2.4 Authorization Mechanism Changes

Apache 2.4 introduced a completely new access control configuration syntax, which is the root cause of configuration failures after upgrades. In Apache 2.2 and earlier versions, access control primarily used Order, Allow, and Deny directives, for example:

Order Deny,Allow
Deny from all

In Apache 2.4, these directives were replaced by the Require directive, with the new syntax being more concise and intuitive. This change is often overlooked during upgrades, causing existing configurations to malfunction.

Core Solution

Based on the best answer analysis, the key to resolving this issue lies in modifying the PHP-FPM configuration file. The specific steps are as follows:

First, locate and edit the /etc/apache2/conf-available/php5-fpm.conf file. In this file, replace all access control directives using the old syntax with the new syntax. The original configuration might contain:

Order Deny,Allow
Deny from all

This needs to be modified to:

Require all granted

The significance of this modification is that the Require all granted directive explicitly allows all clients to access the relevant resources, replacing the order-based Order directive and explicit denial rules. This change ensures Apache 2.4 can correctly parse and execute access control logic.

After modifying the configuration file, enable the new configuration by executing:

sudo a2enconf php5-fpm

This command creates symbolic links, connecting php5-fpm.conf from the conf-available directory to the conf-enabled directory, ensuring Apache loads this configuration at startup.

Finally, restart the Apache service to apply the changes:

sudo service apache2 restart

Supplementary Solutions and In-Depth Analysis

In addition to the core solution above, other answers provide valuable supplementary information. Particularly, the second answer notes that access permissions must also be configured for the directory referenced by the Alias directive.

In the mods-enabled/fastcgi.conf file, the following configuration exists:

<IfModule mod_fastcgi.c>
    AddHandler php5-fcgi .php
    Action php5-fcgi /php5-fcgi
    Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi -socket /var/run/php5-fpm.sock -pass-header Authorization
</Ifmodule>

Here, the Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi directive creates a virtual path mapping. When a client requests /php5-fcgi, Apache maps it to the filesystem path /usr/lib/cgi-bin/php5-fcgi. However, this path doesn't correspond to an actual file but rather to the FastCGI handler defined by the FastCgiExternalServer directive.

The crucial point is that Apache still needs to verify whether the client has permission to access the /usr/lib/cgi-bin directory. Therefore, the following configuration should be added:

<Directory /usr/lib/cgi-bin>
    Require all granted
</Directory>

This configuration ensures Apache doesn't deny requests due to directory permission issues before attempting to access the FastCGI handler. It's important to note that this configures the directory /usr/lib/cgi-bin, not the specific file php5-fcgi, since the latter doesn't physically exist in the filesystem.

Security Considerations and Best Practices

While the Require all granted directive resolves access issues, it should be used cautiously in production environments. This directive allows all clients to access relevant resources, potentially creating security risks.

For production environments, more granular access control strategies are recommended. For example, access could be restricted to specific IP addresses or networks:

Require ip 192.168.1.0/24

Or based on user authentication:

Require valid-user

In development environments where the server is used only for local development, using Require all granted is reasonable. However, when deploying to public networks, appropriate security measures must be implemented.

Configuration Verification and Troubleshooting

After completing configuration modifications, the following verification steps are recommended:

1. Check if Apache configuration syntax is correct:

sudo apache2ctl configtest

2. Review error logs to confirm if the issue is resolved:

tail -f /var/log/apache2/error.log

3. Test whether PHP files execute normally. Create a simple test file:

<?php
phpinfo();
?>

4. If the problem persists, check if other configuration files contain old access control syntax. Use the following command to search:

grep -r "Order Deny,Allow" /etc/apache2/

Conclusion

The new access control syntax introduced in Apache 2.4 is the primary cause of configuration failures after upgrades. By replacing old Order Deny,Allow and Deny from all directives with Require all granted, and ensuring appropriate permissions for directories involved in Alias directives, the "client denied by server configuration" error can be effectively resolved. When implementing solutions, security factors must be considered based on the specific environment, following the principle of least privilege. Proper configuration not only solves current issues but also establishes a foundation for system stability and security protection.