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
Running wordpress locally on a centOS 7 server running the latest apache, PHPmyadmin and mariadb-server.
IP/wordpress and IP/phpmyadmin on systems within the local network yields "403 forbidden" "you dont have permission to access (directory) on this server."
How can I fix this to allow the website to be seen on the public internet?
Could be a lot of things.
In your main Apache configuration file (e.g. /etc/httpd/conf/httpd.conf on Arch Linux), confirm your DocumentRoot path. The files you want to serve must reside there, or in sub-directories from there (If not, you might want to use an Alias to specify another path). Since you call IP/wordpress and IP/phpmyadmin, then you probably have directories called wordpress and phpmyadmin under your DocumentRoot path.
You also want to check the Directory groups in your Apache configuration file. Under those, the main culprit would be the Require directive set to all denied or something else too much restrictive like ip your_ip.
Finally, PHP can restrict path access with the open_basedir directive. Look for it in your php configuration file (e.g. /etc/php/php.ini on Arch Linux). If the line is commented, you're fine. But if a path is specified, your wordpress and phpmyadmin files must reside there.
Depending on your setup, any directive mentioned above could be in another Apache configuration file (e.g. /etc/httpd/conf/extra/* on Arch Linux).
Take a look at Apache and PHP online documentation for information about those directives.
Probably there is an issue with your directory privileges.
Use the follwing command to check it:
cd your_site_directory
ls -l
You can have a look to have a better understanding on directory privileges here.
As mentioned here apache runs under "apache" user.
Have a look at this post here to fix the issue.
All files should belong at least to apache group. To do it you can use
cd your_site_directory
chgrp -R apache ./*
I have installed apache2 server on Ubuntu 14.04. It is working well with the files and directories which i have created here after installation, but if i copy any file or folder from anywhere else (already written) then is gives Forbidden error message.
Thanks in advance.
For a file to be accessible by apache2, it should be owned by the user which runs the apache2 server. On most systems the user is www-data or httpd or apache. To find which user is that, just look into your apache2.conf or httpd.conf. Once you know the user, make it the owner of the copied files/folders or reiterate it for the whole /var/www//html folder.
sudo chown -R www-data:www-data /var/www/html
This should do it. But, if it doesn't, verify that the user has at least read and execute permissions on the folder (write also, if you need to write some data through your script).
I am attempting to edit the "default" file located at ..
"/etc/apache2/sites-available/default"
on my Ubuntu machine running Apache 2.2.8.
I want to do this in order to enable the use of .htaccess files. I have downloaded the "default" file and edited it and now I am trying to upload it back to the server via SFTP. I keep getting permission denied errors.
Could it be because Apache is running and making use of the file? I am an admin on the machine so I would expect to be able to overwrite the file. Thanks for any assistance.
No it does not need to be stopped.
Try accessing the file through ssh, and make sure you access it with root privileges:
sudo nano /etc/apache2/sites-available/default
You would still need to force-reload Apache after changing the config files, as tux21b suggested in a comment below:
sudo /etc/init.d/apache2 force-reload
For Apache/2.4.7 , the file that you want to edit is:
/etc/apache2/apache2.conf
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