42

My friend's website was working fine until he moved the document root from /var/www/xxx to /home/user/xxx.

Apache gives 13 permission denied error messages when we try to access the site via a web browser.

The site is configured as a virtual directory. All the Apache configurations were unchanged (except for the directory change).

We tried to chmod 777 /home/user/xxx, chown apache /home/user/xxx. But they didn't work.

Is there some kind of security feature set on the user's home directories? The server OS is CentOS (Godaddy VPS).

Any help is appreciated!

Thanks!

Santosh Kumar
  • 26,475
  • 20
  • 67
  • 118
Dave
  • 12,117
  • 10
  • 46
  • 52
  • Didn't know about that until you mentioned it =) I guess I'll give it a go. Why they keep two (maybe more?) sites anyway? Isn't it better to centralize those categories? – Dave Aug 04 '09 at 03:50
  • @Dave: stackoverflow.com is for programming questions; serverfault.com is for sysadmin/server questions; superuser.com is for general "power users" and other misc computer related questions. Helps people focus on their areas of expertise I suppose. – Josh Aug 04 '09 at 13:47
  • Can the question (and it's answers) be migrated over to serverfault - it is a good question, and cleared up an issue for me. I have also learned a little more that I would add as an answer for it if it was not closed. – Danny Staple May 11 '11 at 10:05
  • I left a flag asking to be migrated to server fault. – Dave Dec 23 '12 at 06:36

9 Answers9

92

Turns out... we had to also chmod 755 the parent directory, user, in addition to xxx.

Dave
  • 12,117
  • 10
  • 46
  • 52
  • 3
    THANK YOU<3 (15 character limit... blah) – Petter Thowsen Jul 14 '13 at 04:24
  • Also ran into this issue, I had followed the steps here: http://serverfault.com/questions/124800/how-to-setup-linux-permissions-for-the-www-folder and ultimately had lost the execution bit for the directory for others which was denying me access to the folder, ran 'sudo chmod o+x /var/www' for the directory so apache can read – shaunhusain Sep 24 '13 at 19:45
  • Banged my head for two hours, never thought to check permissions on user's home. Thanks Dave! – Marius Stuparu Oct 04 '13 at 11:58
37

im using CentOS 5.5 and for me it was SElinux messing with it, i forgot to check that out. you can temporary disable it by doing as root

echo 0 > /selinux/enforce

hope it help someone

kek
  • 371
  • 3
  • 2
  • 9
    This would certainly help for those not interested in selinux at all. I recommend just changing your selinux settings a little instead. For example, running the following will make it so that users can setup a virtual host to be run out of their home dir: setsebool -P httpd_enable_homedirs 1 – shaune May 25 '11 at 22:26
  • you are genius...... kek.... – Ishan Liyanage May 30 '14 at 08:32
  • this is magic ! thank you so mush – Spartan Apr 26 '16 at 16:39
13

selinux is cause for that problem.....

TException: Error: TSocket: Could not connect to localhost:9160 (Permission denied [13]) 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

or

(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.

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 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 -alZ can 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.

selvakumar
  • 141
  • 1
  • 2
8

Not sure if you've fixed it but in your httpd.conf

Check to see your User/Group settings. Usually it will be set to

User www Group www

If so change it to your name/group

User Greg group staff

Greg
  • 4,509
  • 2
  • 29
  • 22
3

Apache's errorlog will explain why you get a permission denied. Also, serverfault.com is a better forum for a question like this.

If the error log simply says "permission denied", su to the user that the webserver is running as and try to read from the file in question. So for example:

sudo -s
su - nobody
cd /
cd /home
cd user
cd xxx
cat index.html

See if one of those gives you the "permission denied" error.

Josh
  • 10,961
  • 11
  • 65
  • 108
  • Yup we looked through the error log. All it had was (13) permission denied. Is there some parameter that we can set to enable more debug outputs? – Dave Aug 04 '09 at 03:51
3

Can't you set the Loglevel in httpd.conf to debug? (I'm using FreeBSD)

ee usr/local/etc/apache22/httpd.conf

change loglevel :

'LogLevel: Control the number of messages logged to the error_log. Possible values include: debug, info, notice, warn, error, crit, alert, emerg.'

Try changing to debug and re-checking the error log after that.

  • Thanks, now the error log is: (13)Permission denied: /home/user/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable – Dave Aug 05 '09 at 20:01
  • I tried to search for solutions specific to that error. But, most of them involve chmod'ing files to the right permissions (which I have already done). Some of them say it involves front page extension. But, we never used that to begin with... – Dave Aug 05 '09 at 20:06
2

Could be SELinux. Check the appropriate log file (/var/log/messages? - been a while since I've used a RedHat derivative) to see if that's blocking the access.

nobody
  • 19,814
  • 17
  • 56
  • 77
  • Thanks for your help. I tried to look into /var/log/messages; there are a whole bunch of them: messages, messages.1.gz, messages.2.gz, ... up to messages.14.gz. /var/log/messages is empty; so are the other ones after I decompress them ... – Dave Aug 04 '09 at 04:35
  • right: `SELinux is preventing /usr/sbin/httpd from append access on the file error.log` – Ricky Levi Oct 03 '22 at 10:34
0

Error:

[error] [client 127.0.0.1] (13)Permission denied: Could not open password file: /home/XXX/svn/svn_password

Info:

##SELinux Security Context File Labels
#httpd_sys_content_t  The type used by regular static web pages with .html and .htm extensions.
#httpd_sys_script_ro_t  Required for CGI scripts to read files and directories.
#httpd_sys_script_ra_t  Same as the httpd_sys_script_ro_t type but also allows appending data to files by the CGI script.
#httpd_sys_script_rw_t  Files with this type may be changed by a CGI script in any way, including deletion.
#httpd_sys_script_exec_t  The type required for the execution of CGI scripts 

Solution:

[root@localhost]# perror 13
OS error code  13:  Permission denied
[root@localhost]# chown apache.apache /home/XXX/svn/ -R
[root@localhost]# semanage fcontext -a -t httpd_sys_script_rw_t  "/home/XXX/svn(/.*)?"
[root@localhost]# restorecon -R -v /home/XXX/svn/
[root@localhost]# restorecon reset /home/XXX/svn/ context
[root@localhost]# ls -dZ /home/XXX/svn/
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 /home/XXX/svn/
[root@localhost]# ls -dZ /home/XXX/svn/svn_password 
-rwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 /home/XXX/svn/svn_password
[root@localhost]# 

-2

Have you changed the permissions on the individual files as well as just the directory?

chmod -R 777 /home/user/xxx