Problem Description
Any one of these might apply:
- Your static resources like CSS and image files fail to load and the log file and/or your browser's web inspector show that the static files are getting a 403 forbidden error, but the logs don't specify a reason for the error. (Note that if the logs specify why, then you will likely need this article instead).
- You're seeing an error in your web server logs indicating: client denied by server configuration or pcfg_openfile: unable to check htaccess file, ensure it is readable
- You're trying to save a page or setting in WordPress and the server logs show a 403 error whenever you do.
Problem Resolution
A 403 Forbidden error means you don't have permission to view the file or page. This could be because of file or folder permissions, or because of a firewall blocking the action. Solutions for this error are as follows, starting with the simplest things to check first. We recommend proceeding down the list with each solution until the problem is resolved.
You'll want to start by checking the web server logs using this guide: https://websavers.ca/view-web-server-logs-plesk
The logs will often provide a more precise error.
The web server logs show a ModSecurity error
See our guide to managing web application firewall errors here.
There is only a 403 error on WordPress admin-ajax.php with no additional error showing in the logs
When this occurs with admin-ajax.php it's typically caused by a firewall plugin like WordFence or Sucuri. Try disabling the plugin temporarily to see if that resolves the issue. If it does, then you can check its settings or reach out to their support for further help resolving the issue.
If you don't have a firewall plugin or your firewall plugin has been disabled and the issue continues, try clearing your cache and completing the action again. If that resolves the issue, then whatever action you're completing does not like the longevity of your cache. This typically occurs when a form is being submit and the form plugin uses stale nonce/token values. You can work around this by disabling caching on the page, or reducing your cache timeout to under 4 hours. However the real solution is to reach out to the form and/or plugin developer and inform them of the issue. They should be able to resolve this by adjusting how their nonce/token is retrieved.
File or Path Permissions
The file being requested has bad permissions. If file permissions is your issue, a specific file path will be referenced in the error logs as being the problem. The following list is how permissions should be set. Note that you can set these permissions via FTP, SSH, or (easiest) Plesk File Manager. If your preferred method does not use numeric permissions (Plesk File Manager does not), you can enter them in this permissions calculator by adding a zero to the left side, to get the values to set.
- Directories and folders must be 755 | Shell Command: find . -type d -exec chmod 755 {} \;
- Executable scripts within the cgi-bin folder must be 755
- Images, media, and text files like HTML should be 755 or 644 | Shell Command: find . -type f -exec chmod 644 {} \;
- Configuration files that contain secure contents, like database passwords and hashes should be 600 (ex: wp-config.php)
If you're not sure how to do this, check out our article in using the Plesk File Manager to learn how to use it to change file permissions. (It's about half way down the page).
You get "client denied by server configuration" on legitimate requests for files with acceptable permissions
It's important to first ensure that the path that follows the error does not have any file permission issues (see above). If all permissions check out OK, the most common cause for this that we've found is an apache module causing the issue.
If you have your own VPS and you're seeing client denied by server configuration: <path_to_wordpress>/wp-admin/admin-ajax.php or with other built-in WordPress paths, and they worked a couple times before then presenting the 403 error, this is typically caused by mod_evasive being installed and configured with low values. You can either adjust its configuration in /etc/httpd/conf.d/mod_evasive.conf, or remove it by running `yum remove mod_evasive`
Hidden Files (start with a dot, like .htaccess)
If you get "client denied by server configuration"pcfg_openfile: unable to check htaccess file, ensure it is readable" in your web server error logs and it specifies a path to a .htaccess or other such hidden file (starting with a dot), then either:
- A visitor is trying to look at a hidden file, like the .htaccess file. You cannot look at any file that starts with a dot and this is good behaviour to throw an error, or
- One of the folders leading to your .htaccess file does not have correct permissions. Check each of the parent folders that the .htaccess file is found within to ensure their permissions are 755 using the steps described above in Option 1. You receive an error about the .htaccess file because the apache web server checks for a .htaccess file in every directory. When it cannot read the contents of the directory, it can't check for the .htaccess file, even if such a file does not exist in this particular directory.
All static files are not loading
To resolve this very specific issue, log in to Plesk, then choose Apache and Nginx settings for the domain encountering the problem. Uncheck the box that says "Smart Static File Processing" and click OK. The issue should now be resolved.
