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

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

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

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

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

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


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

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

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

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

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

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.


3

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


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


2

Use +FollowSymlinks Alias /foo /Users/someone/Documents/foo/html <Directory "/Users/someone/Documents/foo/html"> Options +Indexes +FollowSymLinks +MultiViews Order allow,deny Allow from all </Directory>


2

www-data may have shell like /bin/false, so if you want to check exactly where is problem, do following: switch to root(su or sudo -i), then run # su -s /bin/bash www-data $ cat /path/to/problem/file And you will see, is this problem about permissions or somewhere else. UPD: Hmm... I din't look at post writing time. Is there "necropost" achievement on ...


2

Are you saying that lighttpd doesn't serve the directory listing, and gives out a 403 error instead? If that's the case, you have to add the following line to your config: dir-listing.activate = "enable"


2

Make sure that fastcgi and fastcgi-php modules are enabled in lighttpd: lighty-enable-mod fastcgi lighty-enable-mod fastcgi-php


2

Grep for DocumentRoot in your other conf files, like httpd.conf - is it defined anywhere outside of your vhosts? It's unclear from your question and the followups if your default DocumentRoot is actually in /var/www. You could have a different DocumentRoot pointing at an entirely different directory tree that's not /var/www - in which case changing ...


2

Create a user account, grant it the ability to 'run as a service' and 'act as part of the OS' from the local security policy. Ensure that that account has permissions to your Apache directories. Once your service is installed, configure it to run as that user.


2

You need to give execute permissions to the user under which your web server is running to all directories in the path /home/Dropbox/www and /opt/lampp/htodcs/. You also need to give that user read permission in the last directory of both paths.


2

What are the permissions in the folder ? Does lampp user and group can acess the folder? Check the permissions in the folder Beside, apache is configured not to access folders outside the documentroot (tipical /var/www/html or something like it) You need to edit httpd.conf (or whatever is the configuration file for lampp) and add a few lines: ...


2

When you create an encrypted disk image in OS X, it defaults to creating the enclosed volume with restrictive permissions -- the owner (whoever mounted it) gets full access, while group members and others get no access. The web server normally runs as the _www system user, so it falls into the other/no access category. You can check this easily at the ...


2

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



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