File Upload Problems

Using Softaculous, a new CMS(Content Management System) such as WordPress, Joomla, or Mambo has been installed on your website.  It does not matter which CMS is installed, they all need to be able to write files on the server. However, they could show “permission denied” errors during the first-time setup or the first time an upload is attempted via their built-in web interface.  This can happen when using DSO or CGI as the PHP handler. With either handler, php scripts by default run as the Apache user “nobody”, and the webserver software (usually Apache) needs to have write access to a user’s files to avoid this error.

This was a fairly common issue for CMS sites before the PHP handlers suPHP and FCGI were widely used. Below, several of the more common solutions are discussed and compared.

777 Permissions

Unfortunately, this is one of the first methods most people attempt to resolve the issue.  Setting a given file directory (for example, WordPress templates) with 777 permissions resolves upload errors very quickly.  The problem is, it not only allows the webserver access to the user’s files — it gives all users access to those files, which could allow a compromised site to be used to compromise any other sites on the server as well.  These permissions are inherently insecure, and are the root cause of a significant number of site hacks and site defacements each day.  This method should not be used, ever, regardless of CMS or plugin installation instructions which suggest it.

775 Permissions and Use of Groups

Instead of granting full read/write access to everyone, groups may be used.  The default user that Apache runs as in Liquid Web’s fully-managed hosting environments is the user “nobody”.  In this example, with Apache running as user “nobody, there is a directory called “templates” that needs to be writeable by the webserver.

drwx------  2 josh josh 4096 Aug 24 17:34 app
drwx------  2 josh josh 4096 Aug 24 17:34 otherfiles
drwx------  2 josh josh 4096 Aug 24 17:34 templates

The first thing we do is set the group for that directory to “nobody” with the “chgrp” command:

chgrp nobody templates

Now the file list will show that directory as having group “nobody,” unlike the others which are still in the “josh” group:

drwx------  2 josh josh   4096 Aug 24 17:34 app
drwx------  2 josh josh   4096 Aug 24 17:34 otherfiles
drwx------  2 josh nobody 4096 Aug 24 17:34 templates

Next, we grant group-write permissions on the directory using the “chmod” command:

chmod 775 templates

Now we see the templates folder is writeable by group, compared to the others which are only writeable by owner:

drwx------  2 josh josh   4096 Aug 24 17:34 app
drwx------  2 josh josh   4096 Aug 24 17:34 otherfiles
drwxrwxr-x  2 josh nobody 4096 Aug 24 17:34 templates

This has the benefit of not allowing world access to the directory.  However, there is still the risk that a compromised account could gain access by running scripts as the “nobody” user.  To mitigate that risk, there is another option.

suPHP or FCGI

The Liquid Web recommended method for solving this issue is to enable suPHP or FCGI.  With either PHP handler, scripts are executed as the user which owns them instead of the user Apache is running as.  This allows the webserver to write files in directories owned by the user, and prevents other users from writing scripts which can do the same.

If for some reason you need to keep DSO or CGI as your PHP handler, modules are available for both that will allow them to execute scripts as the user. Under DSO, enabling mod_ruid2 is all that is needed and with CGI, suEXEC simply needs to be enabled. To enable the appropriate module or switch your php handler, feel free to contact our Support team.