Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
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!
Turns out... we had to also chmod 755 the parent directory, user, in addition to xxx.
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
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.
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
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.
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.
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.
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]#
Have you changed the permissions on the individual files as well as just the directory?
chmod -R 777 /home/user/xxx
Related
i'm running into a problem where a program written to be accessed as a web service can't access anything in the local file system. running the program from the command line works correctly, but fails when called via apache as a subprocess exec'd via system() from a php script ; it simply can't find the files it's supposed to work on. i'm convinced this is an apache configuration issue, as the program has no problem reading /var/www/html [the webserver document root] and any/all files/directories under it.
here are some details :
virtual centos 7 server running apache 2.4.6.
the program runs as user apache
it can read / [root dir] and interprets it correctly [i.e. it really is / the system root, not /var/www/html]
it doesn't have access to /tmp at all, nor to /var/tmp
some external files are network mounted on /mnt. the program can access /mnt, but attempts to read /mnt/{anything} fail -- even though remote shares are mounted w/effective uid/gid as apache and all files/directories are readable by world.
selinux is currently disabled
for kicks, i tried setting Require all granted inside <Directory / > and <Directory /tmp > in httpd.conf, but that didn't change anything.
does anyone have any idea what could be causing this and how i could fix it ?
thanks.
Have you checked to see if selinux is restricting access?
You can see if Selinux is causing issues by install selinux troubleshooting
yum install -y setroubleshoot
sealert -a /var/log/audit/audit.log
I am trying to migrate a web application from a Slackware config of Apache to a CentOS 7 one. DocumentRoot set to /home/STORAGE and there is a simple index.html file in it for testing. Both /home/STORAGE and index.html have 777 permissions set, yet Apache reports :
access to /index.html denied ... because search permissions are missing on a component of the path.
On the other hand, phpMyAdmin works fine, configured with a separate .conf file in /etc/httpd/conf.d . I tried using their example to make a .conf file for my app, but it still reports the same error. I don't even know where to start looking here.
EDIT:
I think this has something to do with the user of Apache. It is set to a local user in httpd.conf not to root, but the only pages the server serves are those in directories owned by root.
It was not a permission error but a Selinux issue. I decided to use the default /var/www/html for the application but still, had to allow write access to some dirs. Here is what I typed:
sudo chcon -t httpd_sys_rw_content_t /some/dir/in/var/www/html -R
The first time I typed it without -R and the permissions didn't change (check with ls -Z /dir/path). Now it is fine.
I'm trying to set up a website using Silex Bootstrap.
I've put it in my folder with other web projects and changed the DocumentRoot in the Apache config.
<Directory /folder/to/silex_projects/web>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
But I can't open the index page of the framework, Apache gives:
[Mon Dec 17 21:10:52 2012] [crit] [client 127.0.0.1] (13)Permission denied: /folder/to/silex_project/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
I've chmod'ed the whole project folder with chmod a+r -R. Other projects in the same folder are working fine with the .htaccess file.
The .htaccess file does exist.
chmod 755 -R /silex_project/ solved my problem. I still don't know why Apache needs write permissions to work.
This is probably because the user running Apache doesn't have eXecute permission on the directory. It is also needed to read the files within it. chmod a+rx /folder/to/silex_projects would probably have solved your error.
Your chmod 755 -R doesn't solve this by also giving write access, but because this just happens to add the eXecute also.
In addition to the other answers posted, something else than can bite you in this situation is SELinux (if it's enabled) if you're changing up anything where files might be accessed from the distributions "default" locations.
The fix is to add an appropriate policy to selinux for the directory/files, or disable it if you do not want selinux security running.
i have this error too and find this good refrence (13)Permission denied: /home/username/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
When viewing your domain, if you see the error "Forbidden" and then check your apache logs:
/var/log/httpd/error_log
/var/log/httpd/domains/domain.com.error.log
and see the error:
[crit] [client 1.2.3.4] (13)Permission denied: /home/username/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
it would imply that apache does not have read access on your /home/username directory.
The cause for this can be permission related, config related or ownership related.
Apache runs as user "apache", thus the directory must be +x for that user or group.
1) As of DirectAdmin 1.38.0, we implement the secure_acccess_group feature, which will set the /home/user (for Users) to chmod 750 and chown username:access. The apache user will be in the "access" group. To confirm this, type the following:
[root#server]# grep ^access: /etc/group
access:x:506:apache,nobody,mail,majordomo,daemon
and you should get something similar to the output shown.
If you get a blank list of Users, then the access group exists, but is empty. To correctly fill the group (on RedHat/CentOS/Debian systems), type:
usermod -G access apache
usermod -G access nobody
usermod -G access mail
usermod -G access majordomo
usermod -G access daemon
on FreeBSD systems, the command to create the group is:
pw groupadd -n access -M apache,nobody,mail,majordomo,daemon
but this implies the group doesn't yet exist. This case has not been seen on FreeBSD, so likely won't be needed.
I have clean CentOS 6. I just install via yum install httpd mysql-server, python, mysql-python.
First Step
$ trac-admin /home/tracprojects/main2 initenv
Project name: Main
SQL Connect string: mysql://trac#localhost:3306/trac (base exists, utf8, innoDB)
OK.
$ trac-admin /home/tracprojects/main2 deploy /var/www/html/
OK.
Second Step
Then I move cgi-bin/trac.wsgi to my /cgi-bin/ server's alias folder. (mod_wsgi working well. NOT as a daemon. tested on wsgi scripts).
Then I've grant permissions to Apache user for whole directories I've create earlier. And add access from apache config. (order-allow-deny).
But when I open my browser and go to url, I've got this error message:
Internal Server Error
TracError: IOError: [Errno 13] Permission denied: '/home/tracprojects/main2/VERSION'
What I do wrong?
Do you use SElinux (enabled by default)? With default SElinux I believe Apache can not access /home. You can check this by disabling SElinux temporarily ("setenforce 0" as root) and maybe restarting Apache. Also check /var/log/audit.log.
Check permissions of '/home/tracprojects' etc. Apache runs as special user and simply may not be able to read into directories, read files, or even write files.
You may be better off using mod_wsgi daemon mode and telling mod_wsgi to run the process as a different user who can access that location. Even if do this, the WSGI script file directory still at least needs to be readable to Apache user.
I am trying to have Apache follow a symlink to a raid array server that will contain some large data files. I have tried modifying httpd.conf to have an entry like this
<Directory "/Users/imagine/Sites">
Options FollowSymLinks
AllowOverride all
Order allow,deny
Allow from all
</Directory>
to have Apache follow any sym link in the Sites folder.
I keep getting an error return that seems to indicate I don't have any permissions to access the files. The error is:
Forbidden
You don't have permission to access
/~imagine/imageLibraryTest/videoClips/imageLibraryVideos/imageLibraryVideos/Data13/0002RT-1.mov
on this server.
The sys link file is the last "imageLibraryVideos" in the line with the Data13 being the sub dir on the server containing the file.
The 0002RT-1.mov file hase these permissions:
-rwxrwxrwx 1 imagine staff 1138757 Sep 15 17:01 0002RT-1.mov
and is in this path:
cd /Volumes/ImagineProducts-1/Users/imagine/Sites/imageLibraryVideos/Data13
the link points to:
lrwxr-xr-x 1 imagine staff 65 Sep 15 16:40 imageLibraryVideos -> /Volumes/ImagineProducts-1/Users/imagine/Sites/imageLibraryVideos
I had the same problem last week and the solution was pretty simple for me.
Run:
sudo -i -u www-data
And then try navigating the path, directory by directory. You will notice at some point that you don't have access to open the dir.
If you get into the last directory, check that you can read the file (with head for example).
Look in the enclosing directories. They need to be at least mode 711. (drwx--x--x)
Also, look in /var/log/apache2/error_log (Or whatever the concatenation of ServerRoot and ErrorLog is from the httpd.conf) for a possibly more-detailed error message.
Finally, ensure you restart apache after messing with httpd.conf.
You should also look at bind mounts rather than symlinks - that would allow you to remount a given path at a new point. The following is an example:
mount --rbind /path/to/current/location/somewhere/else /new/mount/point
You can also edit your fstab to do this at boot:
/path/to/original /new/path bind defaults,bind 0 0
This is a permissions problem where the user that your web server is running under does not have read and/or execute permissions to the necessary directories in the symbolic link path. The quick and easy way to check is to su - web-user (where web-user is the user account that the web server is running under) and then try to cd into the path and view the file. When you come across a directory that you don't have permission to enter, you'll have to change the permissions and/or ownership to make it accessible by the web server user account.