Common AWS WordPress Upgrade Errors and How To Fix Them

More and more people are choosing to self-host their WordPress site, and Amazon Web Services EC2 is a great place to do it. There are some very good resources to help get you get started and you can be up and running in a short period of time.

Whats more, its easy to create a snapshot of your site or create a new image, which you can use for backup purposes or to create a parallel development site to test out your changes before putting them live.

In this post I’m going to look at some of the issues you can encounter when trying to upgrade your WordPress site on AWS EC2.

Before you follow any of the steps below, I strongly advise you to back up your WordPress installation first. You can do this in many ways, but on EC2 you can always take a snapshot or create a new image from the one you’re using. If I’m going to try something I haven’t done before, I create a new image from the live one, launch it and test the change there first.

1.0 Automatic Update

So when I saw that a new version of WordPress was available for my site, the first issue I encountered was that in my control panel, WordPress prompted me to enter my FTP credentials in order to perform the upgrade. Now on EC2 I’m using SSH/SCP to connect to my instance and I don’t have FTP or SFTP enabled and neither do I want it. Instead I’d just like to be able to update my site in the same way I do my plugins, pretty much automatically or with one click.

1.1 Find and edit wp-config

So to do this it turns out you just need to edit your wp-config.php file in the WordPress root folder. Normally the root folder is /var/www/html/ or a subdirectory off this folder if you chose that option when you installed WordPress.

1.2 Insert the FS_METHOD

Firstly, back up your wp-config.php file.
cd /var/www/html/wordpress (or wherever your WordPress install root is located)
cp wp-config.php wp-config.php.orig
vi wp-config.php (or use whichever editor you prefer)

Then you just need to add the following line to this file, ideally as the very last line:


1.3 Save and re-run

After you save the change to your file and go back to your control panel, now when you try to upgrade WordPress again, the FTP prompt should have disappeared, to be replaced with an ‘Upgrade’ button.

At this stage your upgrade might work perfectly. Luck you! You’re all done.

However, you might get an error. Let’s see how to fix that.

2.0 The ‘Unable to Copy some files’ error

So I guess this is a pretty common error judging by all the posts about it. Trouble is they all referred to changing file permissions and I did check that but still got the error. So the error usually looks something like this:

The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php

2.1 Check file permissions

So the first thing to try is to indeed check your file permissions. Now the important point is that the owner of your Web Server process should be able to write to the WordPress folder. I’m using Apache2 and my user/group for the Apache httpd processes is apache/apache.

To find your process user, at the command line type ps -ef | grep httpd.

Basically ‘ps’ looks for processes running on your server, the ‘-e’ means find all processes and the ‘-f’ means do a ‘full format listing. The | (pipe) means ‘pipe’ this output into the next command. In this case it is the ‘grep’ command, which basically matches all the lines from the ‘ps’ command with the given pattern. In this case we ant to find the httpd processes of Apache.

The output should look something like this:

‘ps’ output with process user (apache in this case) highlighted in red.

Now, to make sure your httpd process can access the files, you need to check/update your file permissions. Here is what I run to do that:

sudo chown -R apache /var/www
sudo chgrp -R apache /var/www
sudo chmod 2775 /var/www
find /var/www -type d -exec sudo chmod 2775 {} \;
find /var/www -type f -exec sudo chmod 0664 {} \;
sudo service httpd restart

Let’s quickly go through the above commands.

So in the above we’re assuming that WordPress is installed under /var/www and that the web server user is apache

So the first command (chown) changes the owner, recursively, of all files under /var/www to the apache user.

The second command does the same for the group.

The chmod command changes the file access permissions. In this case we’re using the find command to find all files (-f option) and all directories (-d) and changing their permissions accordingly. Here we are setting the permissions in octal mode. You can also use symbolic mode if you wish. Basically we’re setting every file in every directory to be user and group writeable, which in this case will mean our apache/apache user/group. You can find out more about the chmod command here.

Finally we are restarting the Apache web server service.

Again, at this stage your upgrade might now work perfectly. Excellent – you can stop here.

However, you might still get the same error. There is a further fix you can do on EC2 CentOs/RHEL to try to fix that.

2.2 Switch off SELinux

Security-Enhanced Linux (SELinux) is a Linux kernel security module that provides a mechanism for supporting access control security policies. If you’re using EC2 it might be enabled by default. In order for the upgrade to work you might need to (temporarily) disable it.

To do that, edit the SELinux config file:
sudo vi /etc/selinux/config

Change the line that has:
And restart your server.

After you restart your EC2 instance, check that SELinux is disabled by running this command:


Once again, attempt the upgrade from within the WordPress console. Hopefully now it will work. After the upgrade has completed, change the SELINUX value back to ‘enforcing’ and restart your EC2 instance again.

One thought on “Common AWS WordPress Upgrade Errors and How To Fix Them

  1. Hey, nice article, just wanted to add one thing.
    You might need to do:
    sudo chown -R apache:apache /var/www/html
    at the end of part 1.2 in case your website becomes unreachable.


Comments are closed.