服务器无法读取 htaccess 文件，拒绝安全访问

"Server unable to read htaccess file" means just that. Make sure that the permissions on your .htaccess file are world-readable.

Set group of your public directory to nobody.

This is a common problem with GoDaddy virtual server hosting when you bring up a new website.

Assuming you have SSH access to the server (you have to enable it on cPanel), login to your account. Upon successful login, you will be placed in the home directory for your account. The DocumentRoot for your website is located in a subdirectory named public_html. GoDaddy defaults the permissions for this directory to 750, but those permissions are inadequate to allow Apache to read the files for website. You need to change the permissions for this directory to 755 (chmod 755 public_html).

Copy the files for your website into the public_html directory (both scp and rsync work for copying files to a GoDaddy Linux server).

Next, make sure all of the files under public_html are world readable. To do this, use this command:

cd public_html
chmod -R o+r *

If you have other subdirectories (like css, js, and img), make sure they are world accessible by enabling both read and execute for world access:

chmod o+rx css
chmod o+rx img
chmod o+rx js

Last, you will need to have a .htaccess file in the public_html file. GoDaddy enforces a rule that prohibits the site for loading if you do not have a .htaccess file in your public_html directory. You can use vi to create this file ("vi .htaccess"). Enter the following lines in the file:

Order allow,deny
Allow from all
Require all granted

This config will work for both Apache 2.2 and Apache 2.4. Save the file (ZZ), and then make sure the file has permissions of 644:

chmod 644 .htaccess

Works like a charm.

Important points in my experience:

• every resource accessed by the server must be in an executable and readable directory, hence the xx5 in every chmod in other answers.
• most of the time the webserver (apache in my case) is running neither as the user nor in the group that owns the directory, so again xx5 or chmod o+rx is necessary.

But the greater conclusion I reached is start from little to more.

For example, if http://myserver.com/sites/all/resources/assets/css/bootstrap.css yields a 403 error, see if http://myserver.com/ works, then sites, then sites/all, then sites/all/resources, and so on.

It will help if your server has directory indexes enable:

• In Apache: Options +Indexes

This instruction might also be in the .htaccess of your webserver public_html folder.

In my case apache was somehow configured wrong(?) so I had to set permissions to all parent dirs too. Just setting permission to .htaccess (and it's parent dir) didn't work.

I had this problem too. My advice is look in your server error log file. For me, it was that the top directory for the project was not readable. The error log clearly stated this. A simple

sudo chmod 755 <site_top_folder>

fixed it for me.

GoDaddy shared server solution

I had the same issue when trying to deploy separate Laravel project on a subdomain level.

File structure

- public_html (where the main web app resides)
[works fine]


- booking.mydomain.com (folder for separate Laravel project)
[showing error 403 forbidden]

Solution

1. go to cPanel of your GoDaddy account

2. open File Manager

3. browse to the folder that shows 403 forbidden error

4. in the File Manager, right-click on the folder (in my case booking.mydomain.com)

5. select Change Permissions

6. select following checkboxes

    a) user - read, write, execute
   b) group - read, execute
   c) world - read, execute
   
   
   Permission code must display as 755
   

7. Click change permissions

You need to run these commands in /var/www/html/ or any other directory that your project is on:

sudo chgrp -R GROUP ./
sudo chown -R USER:GROUP ./
find ./ -type d -exec chmod 755 -R {} \;
find ./ -type f -exec chmod 644 {} \;

In my case (apache web server) I use www-data for USER and GROUP

Just my solution. I had extracted a file, had some minor changes, and got the error above. Deleted everything, uploaded and extracted again, and normal business.

As for Apache running on Ubuntu, the solution was to check error log, which showed that the error was related with folder and file permission.

First, check Apache error log

nano /var/log/apache2/error.log

Then set folder permission to be executable

sudo chmod 755 /var/www/html/

Also set file permission to be readable

sudo chmod 644 /var/www/html/.htaccess

Every public folder makes the permission to 755. Problem solved.

I had same problem on Fedora, and found that problem was selinux. to test that it is problem run command: sudo setenforce 0

Otherwise or change in file /etc/sysconfig/selinux

SELINUX=enforcing
to
SELINUX=disabled

or add rules to selinux to allow http access

I had the same problem on a rackspeed server after changing the php version in the cpanel. Turned out it also changed the permissions of the folder... I set the permission of the folder to 755 with

chmod 755 folder_name

In linux,

find project_directory_name_here -type d -exec chmod 755 {} \;
find project_directory_name_here -type f -exec chmod 644 {} \;

It will replace all files and folder permission of project_directory_name_here and its inside stuff.

Ok, I recently met the same issue too while working on a WordPress installation using apache2 on the server on Ubuntu 20.04.

I experienced this issue when I changed file ownership to another user:

Here's what worked for me:

$ sudo chown -R www-data:www-data /var/www/YOUR-DIRECTORY

Here's a bit more context into the issue:

The above command gives ownership of all the files [in that folder] to the www-data user and group. This is the user that the Apache web server runs as, and Apache will need to be able to read and write WordPress files in order to serve the website and perform automatic updates.

Be sure to point to your server’s relevant directory (replace YOUR-DIRECTORY with your actual folder).

You could run through this insightful article on digitalocean.