Apache (13) Permission Denied

(13) Permission Denied

Error 13 indicates a filesystem permissions problem. That is, Apache was denied access to a file or directory due to incorrect permissions. It does not, in general, imply a problem in the Apache configuration files.

In order to serve files, Apache must have the proper permission granted by the operating system to access those files. In particular, the User or Group specified in httpd.conf must be able to read all files that will be served and search the directory containing those files, along with all parent directories up to the root of the filesystem.

Typical permissions on a unix-like system for resources not owned by the User or Group specified in httpd.conf would be 644 -rw-r--r-- for ordinary files and 755 drwxr-x-r-x for directories or CGI scripts. You may also need to check extended permissions (such as SELinux permissions) on operating systems that support them.

If you are running 2.4, the AH error code may give you more information here.

• AH00132: file permissions deny server access
• AH00035: access denied because search permissions are missing on a component of the path

An Example

Lets say that you received the Permission Denied error when accessing the file /usr/local/apache2/htdocs/foo/bar.html on a unix-like system.

First check the existing permissions on the file:

cd /usr/local/apache2/htdocs/foo
ls -l bar.htm

Fix them if necessary:

chmod 644 bar.html

Then do the same for the directory and each parent directory (/usr/local/apache2/htdocs/foo, /usr/local/apache2/htdocs, /usr/local/apache2, /usr/local, /usr):

ls -la
chmod +x .
cd ..
# repeat up to the root

On some systems, the utility namei can be used to help find permissions problems by listing the permissions along each component of the path:

namei -m /usr/local/apache2/htdocs/foo/bar.html

If your system doesn't have namei, you can use parsepath. It can be obtained from here.

If all the standard permissions are correct and you still get a Permission Denied error, you should check for extended-permissions. For example you can use the command setenforce 0 to turn off SELinux and check to see if the problem goes away. If so, ls -alZcan be used to view SELinux permission and chcon to fix them.

In rare cases, this can be caused by other issues, such as a file permissions problem elsewhere in your apache2.conf file. For example, a WSGIScriptAlias directive not mapping to an actual file. The error message may not be accurate about which file was unreadable.

DO NOT set files or directories to mode 777, even "just to test", even if "it's just a test server". The purpose of a test server is to get things right in a safe environment, not to get away with doing it wrong. All it will tell you is if the problem is with files that actually exist.

CGI scripts

Although the CGI script permission might look correct, the actual binary specified in the shebang might not have the proper permissions to be run. (Or some directory on its path, check with namei as explained above.)

(13)Permission denied: proxy: HTTP: attempt to connect to 127.0.0.1:8080 (localhost) failed

This error is not really about file permissions or anything like that. What it actually means is that httpd has been denied permission to connect to that IP address and port.

The most common cause of this is SELinux not permitting httpd to make network connections.

To resolve it, you need to change an SELinux boolean value (which will automatically persist across reboots). You may also want to restart httpd to reset the proxy worker, although this isn't strictly required.

# setsebool -P httpd_can_network_connect 1

For more information on how SELinux can affect httpd, read the httpd_selinux man page.

===

If you are using selinux, I suggest you read the Fedora documentation.

See :

http://fedoraproject.org/wiki/SELinux_FAQ

https://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/

That second link is for Feodra 13, but, IMO, remains the most up to date document on selinux.

An oversimplification of selinux is to consider it an extension of file permissions ( above and beyond owner:group:other). So every file has a context. If a file is used by a http server, then there is no reason a ftp server should be accessing it. You can allow a ftp server to access the files by enabling a Boolean.

The problem you will have, chcon does not survive a relabel or restorecon.

5.7.1. Temporary Changes: chcon The chcon command changes the SELinux context for files. However, changes made with the chcon command do not survive a file system relabel, or the execution of the /sbin/restorecon command. SELinux policy controls whether users are able to modify the SELinux context for any given file. When using chcon, users provide all or part of the SELinux context to change. An incorrect file type is a common cause of SELinux denying access.

chcon is intended for temporary changes.

See https://docs.fedoraproject.org/en-US/Fedora/12/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html.

You almost certainly will want to use restorecon

sudo /sbin/restorecon -R -v /var/www/

If that fails, post the avc denials and provide more information on what you are wanting to do. Most likely there would be a Boolean that you would need to configure.

See https://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Troubleshooting-Fixing_Problems.html

http://wiki.apache.org/httpd/13PermissionDenied

http://askubuntu.com/questions/316745/explanation-of-the-chcon-command