Tag Info

Hot answers tagged

24

I'll bet that some directory above the one you want to access doesn't have permissions to allow Apache to traverse it. Become the user that Apache is running as (sudo -i -u apache or whatever), then try to change into the directory of interest and ls it. If you can't (as expected), then try getting into the directories above it, one by one, until one lets ...


6

If the webserver cannot read the file you will get this problem. Make sure that the webserver can read the file by setting the ownership and permissions on the .htaccess appropriately.


6

You've made a mistake in php location. You need to escape . since it's otherwise used in regex. location ~ \.php$ { Edit: You should also add the following under server: index index.html index.htm index.php; That is required to automatically pass the index.php (if index.html and index.htm don't exist) if no file is specified.


5

You are using a stock install of CentOS, if that is correct please check that if SELinux is in Enforcing mode getenforce if the result is "Enforcing" temporally change it to permissive setenforce 0 and try again, you can also guide the condition of web content to the files in your home directory.


5

Given the permissions of /home/blogs/, only the owner of the directory can see the contents. you may want to grant 750 or 755 permissions, so apache could read the contents. The reason its looking for a /home/blogs/.htaccess file is a configuration option you haven't shown from your configs. It is probably a <Directory /> AllowOverride ...


5

I suspect that you have SELinux set to enforcing by the default. And it is the cause of this problem, check with: # getsebool or: # cat /etc/sysconfig/selinux Try this: # chcon -R -t httpd_sys_content_t /var/www/webdocs and let me know if it works.


5

Either remove wget exclusion from the nginx configuration, or add something like this as an option to your wget command: --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0" --referrer whatever.example.com


4

You're sending requests to 127.0.0.1:8000, which the server is listening on but your virtual host is configured for 205.13.12.12:8000. When a virtual host is not matched it will try and serve the default site which, from the error, looks like a DocumentRoot /etc/apache2/htdocs which might not have correct permissions, or exist, or be configured in ...


4

I have a wrong entry on the authz file (it was trying to give permission to a deleted group), so I deleted the entry and it's working now


4

How about the ownership/permissions of the files your pointing to? I'm more inclined to think Apache can't get to them rather than it being Apache at this point. Edit with solution: Put Options +FollowSymLinks above RewriteEngine On


4

Check out if apache can access (+x) the /home, /home/user AND /home/user/vhost folder, as it normally checks the .htaccess down the tree.


3

Disable SELinux or run in ROOT setsebool -P httpd_enable_homedirs on chcon -R -t httpd_sys_content_t /home/ chcon -R -t httpd_sys_rw_content_t /home/


3

Add in a block like: ErrorDocument 403 /40x.html ErrorDocument 404 /40x.html into the server or virtualhost configuration. Here's the relevant section of the documentation: http://httpd.apache.org/docs/2.2/mod/core.html#errordocument


3

Permissions of the symlink target are good to have, but they're not the whole picture. The Apache user needs traverse rights into the directory - which I'm willing to bet that it doesn't have. Check the permissions on the directories /home/sam and /home/sam/proto-spa - the x bit needs to be present for traversal. Also - what OS are you on? SELinux or ...


3

A 403 error can also mean that your file permissions are wrong. If the user running the web server is not allowed to read that file, you will receive this status code. See what permissions a working file has and put the same to a file that is not working.


3

You probably have a deny all somewhere in the global config. Try adding this to the vhost stanza: <Directory /home/mcmoddr/www> Order allow,deny Allow from all </Directory>


3

Check that the permissions in the DocumentRoot directory and all the directories below allow the apache user read and execute. Check that the files in DocumentRoot and below allow the apache user read permission.


3

SELinux is one way in which permissions can be denied, but you haven't mentioned file permissions. Ensure that the permissions on the directory allow the httpd user the ability to read and execute files in the directory. This is could be accomplished with the following: chown -R root:httpd /home/websites/public_html chmod -R 755 /home/websites/public_html ...


3

Adding FollowSymlinks to the htaccess didn't work for me so I googled a bit a found another solution It turns out there is another Directory block in /etc/apache2/users/.conf in which you need to add FollowSymlinks to Options and change AllowOverride to All <Directory "/Users/<your user>/Sites/"> Options Indexes MultiViews FollowSymlinks ...


3

A number of things could be going wrong. First thing is to look in your error log (maybe in /var/log/apache2/error_log) and look for the Apache reason for failing to serve this location. Next is to check your directory permissions up to your document root. E.g. if your document root is in /var/www/htdocs then you need to ensure the Apache user has +x ...


3

Try disabling selinux: setenforce 0 If that works then you need to decide what you want to do permanently about selinux. On/Off. That's going to depend on where your app is used, what it does, whether it has financial value, PCI requirements and so on. Update This is probably the most used FAQ entry: ...


3

You appear to be using a Samba share to store your web content. If you want SELinux to allow your web server to read files on Samba shares, you need to set the appropriate boolean. For instance: setsebool -P httpd_use_cifs 1


3

You can get a 403 error for many reasons. See here: http://en.wikipedia.org/wiki/HTTP_403 Are you running IIS on Windows Server? Since you're running IIS, I wonder if it could be one of these problems: 403.9 - Too many users. 403.15 - Client Access Licenses exceeded. I would have a look in the even log to get further information. Can your run your ...


3

You have Options Indexes turned on somewhere in your configuration. That is what causes Apache to generate the page you are seeing above. That page is made up of HTML and to the left of each item (where you see [ ] and [TXT] etc.) would normally appear an image representing the type of file that line is for. These images are requested, just like with any ...


3

To fix the icon problem, I had to edit httpd-autoindex.conf located in \bin\apache\apache2.2.22\conf\extra I changed Alias /icons/ "c:/apache2/icons/" to Alias /icons/ "D:/wamp/bin/apache/apache2.2.22/icons/" and <Directory "c:/apache2/icons"> to <Directory "D:/wamp/bin/apache/apache2.2.22/icons/"> The icons will now display as per ...


3

This will most likely be SELinux. You will need to ensure that the files you want to serve have a security context of httpd_sys_content_t try chcon -Rv --type=httpd_sys_content_t /webapps Which will set the correct security context.


2

Order Allow, Deny Allow from all These are not required if you're using HTTP authentication and you can get rid of them. (And Order breaks if there is whitespace after the comma.) BTW, it's a good idea to keep your htpasswd file outside the web documents directory. Since you've updated your question with additional information, I would say that you ...


2

The 403 suggests that there is a permissions error. Check that the apache user has permission to read the .htaccess file and that is has traverse permission on the drugi directory tree, so that would be r-x for other (if it isn't owned by apache)or r-x for owner/group if it is owned by apache or it's group.


2

SELinux is likely to be the culprit here. Somehow the parent's context wasn't inherited correctly when creating files/directories in the /var/www directory. Setting the container implicitly with restorecon or explicitely with chcon should fix the issue. Watch out for lines in /var/log/audit.log when you are troubleshooting issues in a SELinux setting. To ...



Only top voted, non community-wiki answers of a minimum length are eligible