Correct file permissions for WordPress on Apache

By Abhineet Mittal | WordPress
Published on: August 14, 2019
Last updated on: August 17, 2019

File permission is a simple yet complex issue. If you manage a website, you need to ensure that the file permissions are adequate so as to allow users to perform operations on the file and at the same time, you need to ensure that file permissions are strict enough to prevent security and hacking incidents.

Wrong permissions will break your automatic updates. Also, if you run composer, you may struggle as composer should not be run as root or sudo user, and non-root user would need read/write permissions to run composer.

This situation usually arises when you run a website on a self-managed server like the one provided by DigitalOcean or Amazon AWS Lightsail. However, the permissions are equally valid for managed or shared hosting where the host has provided you the SSH access to your files.

In this article, I have provided simple file permissions for your Wordpress website hosted on Apache server. These permissions should be sufficient for most of your websites, including those which are not built on Wordpress.

Giving the correct file permissions to your Wordpress website

To begin with, Apache server runs all the processes requires to read/write the website files & directories. So, we need to provide the ownership of the website files & directories to Apache. As Apache runs as www-data, following command is appropriate to give ownership of your entire website folder to www-data user and group.

In your SSH terminal, run the following command.

sudo chown -R www-data:www-data /var/www/wordpress

Here, I am assuming that your wordpress website root is /var/www/wordpress. You can change it to the directory in which your website is hosted.

Now, we need to give all file permissions (read, write, execute) to owner (Apache server) because server needs to perform read/write operations on files & directories. It will ensure that our website runs smoothly without error.

Giving read/write permissions to www-data is fine for your website to run and auto-update without any errors. But, if you try to SSH into your server as a non-root user, you will not be able to read/write your files inside the wordpress directory.

Also, if you use composer, you need read/write access to website files. As per composer's official documentation, it is recommended that you should NOT run composer as root or sudo user. You should run composer as non-root user. Same is true for other utilities as well which require read/write permissions in your wordpress directory. This means we need more permissions.

For this, I am assuming you have already created a new user with sudo privileges and have logged in through that sudo user (not root use).

First, add you to the www-data group using the following simple command in your SSH terminal. Remember, you must be logged in as a non-root user, with sudo privileges, as whom you want to run composer.

sudo adduser $USER www-data

Above command adds you to www-data group.

Now give read/write/execute permissions to all the files and folders to both owner and group.

sudo find /var/www/wordpress -type d -exec chmod 770 {} \;
sudo find /var/www/wordpress -type f -exec chmod 660 {} \;

You need to log out and log in again for the new permissions to take effect.

That's it. You now have the correct permissions.

How to check if your Wordpress website has correct file permissions

After setting up file permissions, you must validate the new file permissions. To check this, try the following two things-

  • Run composer and check if there is any permission error.
  • Try uploading a file in the WordPress media library.

If you are able to execute the above two operations successfully without error, your WordPress website has the correct file permissions.

Share this:
FacebookTwitterWhatsapp

Abhineet Mittal
Abhineet is an entrepreneur by profession and programmer by heart. He loves to write about WordPress. He is the Founder of popular Digital Publishing Platform, Sahityapedia.