I have created a simple app using AngularJS. When I tried to host that project in my website http://demo.gaurabdahal.com/recipefinder it shows the following error:
Forbidden
You don't have permission to access /recipefinder on this server.
Server unable to read htaccess file, denying access to be safe
But if I go to http://demo.gaurabdahal.com/ it displays "access denied" message as expected, that I have printed. But why is it unable to open that AngularJS projects "recipefinder". If I tried to put a simple HTML app there, it opens just fine.
The same AngularJS project works fine when I host that in github (http://gaurabdahal.github.io/recipefinder)
I can't understand what's wrong.
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.
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.
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
Every public folder makes the permission to 755. Problem solved.
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
go to cPanel of your GoDaddy account
open File Manager
browse to the folder that shows 403 forbidden error
in the File Manager, right-click on the folder (in my case booking.mydomain.com)
select Change Permissions
select following checkboxes
a) user - read, write, execute
b) group - read, execute
c) world - read, execute
Permission code must display as 755
Click change permissions
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.
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.
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.
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
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.
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.
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
"Server unable to read htaccess file" means just that. Make sure that the permissions on your .htaccess file are world-readable.
What's the correct file owner to use locally for a joomla project, which is under svn?
When all my files are owned by apache user, I cant update my project from svn (& I cant edit these files with my normal user).
And when my files are owned by my normal user, joomla administration (Information tab) shows that some directories are read-only. Should I change only the owner of these directories (plugins, tmp...) to apache user, and let the other files owned by my user?
I have to find a compromise between the two users (apache & normal user).
Ideally you should use a different user for each site, and use the same user for svn/git.
But assuming that's not possible, keep in mind that Joomla needs to write to the folders below. Additionally, without a write access to images, you won't be able to upload images.
So the list of files/folders to assign to the apache user is:
administrator/cache
cache
logs
tmp
configuration.php
images
All the other files can be owned by the svn user; however you'll need to chmod / chown when you want to update Joomla from the backend, and install new extensions.
An easier approach is to keep only your component under svn (you can checkout only the paths you want with svn easily) and leave the rest to apache.
Finally, consider putting your svn user and Apache in the same user group, and chmod to 775.
I've done this complete differently because this is really a pain, pushing files from a Joomla installation back to a repo. Assuming you're local,
change in /etc/passwd for apache or www-data the shell from bin/sh to bin/bash.
fix the permissions of the home directory (usually /var/www ) for www-data, so that www-data can create its .svn directory. thats done by # chown -hR www-data /var/www
as root change to www-data : # sudo su www-data
go to the joomla installation/folder with the svn meta files
call svn info or whatever, so that it can store the svn credentials in .svn
you're done here, now you can call via php/system svn update in whatever folder
i've written this here www.xappcommander.com also for Joomla for exactly for this purpose which allows you to change code in an active joomla installation push back the changes to a repo without all the pain of the alternatives (sftp/ftp). Through its shell extension, you simply write #svn ci --message="whatever".
this works well also in a live stage, under plesk PHP is running with your user account, so you skip step 1-4.
I wanted to copy my Drupal site to another location (VDS), I got full backup from my provider, (in tar.gz), untarred and ungzipped it, deleted some folders, zipped it again in 7zip format, then copied it with sftp to /var/www on VDS and unzipped, but all permissions now are read-only and so Drupal doesn't work at all cause it cannot acess files.
Can anyone tell when I lost my permissions, the right way to migrate to my VDS or (and) how can I manage with my corrupted-permission Drupal now (maybe I just can change them?)
Read only permission is generally fine for a Drupal site, except for the upload folder (it's nomally called files and in can be in sites/default or in sites/YOUR_SITE_CONFIGURATION_FOLDER or wherever you set it to be in admin/config/media/file-system). The files folder, and every subfolder it contains must be writable from the web server, so if your web server is running as the www-data user (the standard user for Apache in Ubuntu, other systems may differ) you can for example do
chmod -R o+w sites/default/files
chown -R www-data sites/default/files
I have a windows machine for development. When code is working I ssh and copy files from developmnet to production which is /var/www.
Is this copy and paste safe? I see that some files are marked for read/write and some others only for read. Should I be concerned when transfering files from dev to prod this way?
What should be the output of the files when I do >ls /var/www?
If somebody can give some hints. Thanks
/var/www/ is the default documentroot and as such should / would have root folders of your web sites. ls would list them out while ls -ltr would give you all the property info on those folders / files.
You can ssh into Dev and transfer files to prod, but a better way would be to setup secure ftp and a specific user account that only has access to specific directories under var/www/ and then you button it up to all others. That way only one user has access to Prod at the filesystem level and it is very limited access and logged.
Simple question, but for some reason I couldn't find the exact answer on Google:
I have a fresh Ubuntu install on Slicehost, and would like to make a public directory in my home dir for a simple website containing a bunch of static HTML files. How do I do this? Is it just a matter of typing mkdir public_html and setting the permissions, or is there a cleaner way? (I remember in the past I've had issues where every time I copied a file into my public_html directory, I would have to manually set its permissions, which was quite frustrating.)
Assuming you've already installed apache, do the following:
sudo a2enmod userdir
sudo service apache2 reload
The first command enables the userdir apache mod, which does exactly what you want. The second reloads apache configurations so that it starts using the new configuration.
To install apache2:
sudo apt-get install apache2
Of course, you'll also need to make sure that the permissions on your public_html folder allow the www-data user to see the files in there -- 755 usually works well. To do this:
mkdir ~/public_html
chmod -R 755 ~/public_html
This will recursively (-R) go through your public_html and set the permissions to 755 (owner rwx, and both group and other r-x, r-x).
The other answers are on the right track with mod_userdir, but using that will give your website the base URL http://www.yourdomain.com/~username/ - for instance, a file /home/username/public_html/index.html would be accessible as http://www.yourdomain.com/~username/index.html. If you want your files to be accessible under the domain root, as http://www.yourdomain.com/index.html for example, then you'll need to put the directive
DocumentRoot /home/username/public_html
in the Apache configuration file.
You need to use mod_userdir for Apache, otherwise you need to set up symlinks from /var/www/ or wherever.
Your permissions issue is because Apache does not have read access to your files. You need to allow read access to www-data (or whatever the user is; distro-specific).