In the past I’ve often run into trouble with permissions and ownership of Joomla files/directories on linux systems.

Problems included

  • Not being able to transfer files to the server using programs such as WinSCP.
  • Not being able to install Joomla extensions, plugins etc.
  • Insecure files and folders due to dangerous permissions and ownership settings.

What are the recommended best practices for setting permissions and ownerships in Joomla on linux systems?


There are a few potential causes for file and folder permission issues on Linux hosting.

1. File and Folder Permissions

Check folder permissions are set to 0755 and file permissions are set to 0644. Note that file and folder permissions can be reset to these standard secure settings on a site wide basis using the free or the paid version of Akeeba Admin Tools.

2. PHP Parameters

Check the upload_max_filesize parameter in the PHP Information tab in the System Information is sufficient. You can often override the default setting in a shared hosting environment via the PHP settings in cPanel or a custom php.ini file.

3. Incorrect Paths in configuration.php

You may have incorrect paths specified for the tmp and logs folders. These are specified in the System Configuration or can be updated directly in the configuration.php file if you are comfortable editing system files directly. If you are unsure of what the path should be, create and upload a file whereami.php (or similar) to the root folder of your website with the following content:

  print 'Current folder is ' . dirname(__FILE__);

Browse to [mywebsite].com/whereami.php to see the path to the root folder.

Once you have the correct path, remember to delete the whereami.php file.

4. Unsuitable PHP File Handler

Your web hosting may be configured with the default PHP file handler but should ideally be using suPHP or FastCGI or similar so that Joomla can upload and execute files using secure file permissions.

You can see what PHP handler is being used at System -> System Information -> WebServer to PHP Interface.

There is a good article on the relative merits of PHP file handlers at: http://boomshadow.net/tech/php-handlers

In a shared hosting environment you don't usually have access to change which PHP file handler is enabled but your web hosting company may be able to change this for you.

Sometimes as a work-around, file and folder permissions are changed to 0777 but this puts your website in a vulnerable state and 0777 file permissions should generally be avoided.

If your web hosting company can't enable suPHP or FastCGI, the only other option might be to find a new web hosting company.

5. Disk Space

Check you have not exceeded your disk space quota.


What are the recommended best practices for setting permissions and ownerships in Joomla on linux systems?

See 1 and 4.

Not being able to transfer files to the server using programs such as WinSCP.

See 1, 2, possibly 4, and 5.

Not being able to install Joomla extensions, plugins etc.

See 1, 2, 3, 4 and 5.

Insecure files and folders due to dangerous permissions and ownership settings.

See 1 and 4.

  • 1
    In my case, I think PHP handlers were a big part of the problem. – TryHarder Apr 24 '14 at 0:13
  • 1
    +1 Your answer didn't actually fix my issue, but I got inspired to check my servers PHP settings - Safe Mode and it turned out it was ON - enabled. Therefore by turning it off was the solution. So for future readers if none of the above fixed it, check your Safe Mode as well :) – Mohammed Joraid Jan 1 '15 at 9:50

Please check the permission levels, it should be 644 and 755 for files and folders respectively.

Many times the permission levels are just fine, even when some issues are faced. It means that you will have to check the the ownership and group of the specific files and folders. Normally the group and ownership can be changed to www-data for apache (used in ubuntu based web servers).

Feel free to check out this interesting Joomla document based upon verifying the file permissions.

  • Does Joomla usually belong to group www-data ? – TryHarder Apr 23 '14 at 5:15
  • 1
    Along with Shyam's answer, we use the SuPHP Apache module. We found that when an extension was installed, we could not then modify those files over FTP and visa versa (file ownership issue). SuPHP fixed this for us by ensuring that PHP scripts run with the permissions of their owners. – Zachary Draper Apr 23 '14 at 5:26
  • 1
    apache process is run under 'www-data' an unix-group. Its not only joomla, all apache based applications. – Shyam Apr 23 '14 at 5:26
  • Is it possible to develop and run a shell script to automatically fix all file permissions? – NivF007 Apr 23 '14 at 5:59
  • 1
    Yes. gist.github.com/ssv445/11204300 You can run the script in cron. – Shyam Apr 23 '14 at 6:09

An easy solution for me is to often let PHP run in (Fast-)CGI mode and to set the ownership of the Joomla directory to the FTP user. So you will be able to upload and overwrite files via FTP and Joomla will be able to write files too.

A way to do this on a shared hosting environment (if it is allowed), is to add something like this to your .htaccess file:

AddHandler php53-cgi .php

Also see an overview about the different modes.


Permissions should be 644 and 755 as explained by Shyam.

In Joomla you can avoid all the problems you mentioned ,with following methods.

Not being able to transfer files to the server using programs such as WinSCP.

  • This may happen due to permission of (444) like Joomla configuration.php have this permission its doesn't allow by default(for security).
  • Another situation for this same error is when you transfer a site or folders from one server to another.

Not being able to install Joomla extensions, plugins etc.

  • This will happen due to temp/log folder bad permission.(It required 755)

  • Or another reason is temp/log path is wrong in configuration.php

Insecure files and folders due to dangerous permissions and ownership settings.

  • This is most important Joomla always recommend do not use 777 for file and folder if you are not aware of this.

Hope its helps..


Permissions should be 644 and 755 as explained by Shyam.

The problems you are facing are most likely related to the way your server is set up. Most of the time this happens on shared hosts where Apache runs under a different user than your FTP account. Since you usually upload Joomla using FTP, Apache isn't the owner of the file and thus doesn't have the needed permissions to change it.

There is a FTP mode within Joomla which allows you to bypass this problem. You can enable it in the Joomla global configuration. It will then do all file accessing using the FTP user instead of the regular Apache user.

A better way however is to ask your host to fix the issue. They can set up PHP (Apache) to run under a special user, which in such a case should be your FTP user. Then everything will work fine.

  • The user/group is the answer, as you said having the special user for the PHP solves this especially if it coincides with the FTP user. – jackJoe Apr 23 '14 at 7:49

Yes, the permissions should be 644 and 755 as explained by Shyam, but the other posters forget to mention that this is if the file is owned by your webserver, and the group is the group you belong to.

For instance, in FileZilla you will see permissions something like this:

Filename      Size   Filetype  Last Modified          Permissions   Owner/Group
somefile.txt  11KB   txt file  2014-04-23 3:43:00 AM      www-data myGroup 

The permissions drwxr-xr-x are 755 (just ignore the leading dr so it's wxr-xr-x). Read permissions are worth 4, Write permissions are worth 2 and execute permissions are worth 1.. so having them all add up to 7, and that's what the owner of this file has. The group has read and execute permissions but not write, so they have 5, and everyone also has 5.. making the permissions 755.

754 would be owners having read, write, execute. Group having read and execute, and everyone only having read permissions.

In the example above, you can see that the file owner is www-data (which is the default web server group for many Apache servers) and the Group is the group myGroup, which is the Group (admins) that I belong to.

The first number is the owners permissions, the second is the groups' permissions, and the third number is everyone's permissions. Obviously, you have to be careful to give the web server the permissions it needs... and make sure the files that need to be locked down can't be written or executed by just anyone (the third number). Below is what the numbers mean:

Assuming the Webserver owns the files, your admin is in the group, and of course, everyone is the third number.

644: Files with permissions set to 644 are readable by everyone and writeable only by the file/folder owner.

755: Files with permissions set to 755 are readable and executable by everyone, but only writeable by the file/folder owner.

777: Files with permissions set to 777 are readable, writeable, and executable by everyone. Don’t use this set of permissions, for security reasons, on your web server unless absolutely necessary, and only temporarily. It's a disaster waiting to happen, especially if a directory has those permissions.. it means anyone can upload files and execute them.

Here are the Linux commands to setup the Joomla! recommended permissions from the command line. Recommended Joomla File Permissions

Set ownership:   sudo chown -R www-data:myName /path/to/your/domain.com
Set Directories: sudo find /path/to/your/domain.com -type d -exec chmod 755 {} \;
Set files :      sudo find /path/to/your/domain.com -type f -exec chmod 644 {} \;

NOTE - many people will show you these commands without the path, but I prefer to ALWAYS use the complete path, because if you forget to change directories to the root Joomla! installation directory and run them without the path, you have just changed permissions for every file and directory in that top directory, and created a huge mess.

After you run these commands, you will need to fix permissions for any directories that need more permissions... for instance...users uploading images etc.

IF YOU ONLY USE THE JOOMLA! interface, and you don't have admin or FTP access to the server, then USE THE OWNERSHIP and PERMISSIONS ABOVE.

STOP HERE IF YOU ARE A NOVICE.. the Below is only for people that truly understand what permissions and ownership do.

However, I find having the ownership and permissions that way very unhandy because I like to use FileZilla and a Terminal session command line most of the time, and I upload a lot of files manually. But I can't overwrite any files because I don't own them and I don't have permissions to write. I could have FileZilla log in under the web server account, BUT... I want FileZilla to log in under my account, so I can browse other directories also, not just the files the webserver has access to... SO... I change the ownership and permissions to this:

Filename      Size   Filetype  Last Modified          Permissions   Owner/Group
somefile.txt  11KB   txt file  2014-04-23 3:43:00 AM  drwxr-xr-x    myName www-data

I make myself the owner, and put the web server in the Group... and I change the permissions for directories to 775, and for files to 664. Makes my life a lot easier... but I don't recommend it for everyone.

If you do it my way, these are the commands:

 Set ownership:   sudo chown -R myName:www-data /path/to/your/domain.com
 Set Directories: sudo find /path/to/your/domain.com -type d -exec chmod 775 {} \;
 Set files :      sudo find /path/to/your/domain.com -type f -exec chmod 664 {} \;  
  • "drwxr-xr-x are 755" - this would be 751 (missing read perm for public), not 755. (Although 755 would be more "normal" for directories.) – MrWhite Apr 28 '14 at 13:48

The other answers provides a good explanation of what should be done, I only want to add a script to fix the permissions if you already uploaded a component and can't access the files with ftp.

In this case I would upload this file as fix.php to the FTP server and open it in the browser: http://example.com/fix.php


function file_fix_directory($dir, $nomask = array('.', '..')) {
  if (is_dir($dir)) {
     // Try to make each directory world writable.
     if (@chmod($dir, 0777)) {
       echo "<p>Made writable: " . $dir . "</p>";
  if (is_dir($dir) && $handle = opendir($dir)) {
    while (false !== ($file = readdir($handle))) {
      if (!in_array($file, $nomask) && $file[0] != '.') {
        if (is_dir("$dir/$file")) {
          // Recurse into subdirectories
          file_fix_directory("$dir/$file", $nomask);
        else {
          $filename = "$dir/$file";
            // Try to make each file world writable.
            if (@chmod($filename, 0666)) {
              echo "<p>Made writable: " . $filename . "</p>";



This script sets all the file's permissions to 666 and all directory's to 777. World writable is not the best set of permissions for a shared host but you will be able to access your files again and can then set it to the correct values with FTP.


Late to the party. I came here looking as well as other places for a definitive guide on what folders need to be writeable for joomla.

Sorry folks to be the harbinger of bad news.

The advice to use the permissions 755 for all directories and 644 for all folders is irresponsible at the very least.

Making all your folders and files owner writeable is fine as long as the owner is not the web server (apache et al).

I know this is common recommended practice but I can assure you its not good practice. The last piece of software you want to give the ability to write to folders is the web server itself. Its the web server that is used by hackers to take advantage of that exploit that hasn't been patched yet (or even found).

Do you think .htaccess will save your Kevin? Forget it because you allowed the web server write access, our dear hacker friends can create their own .htaccess files giving them whatever permissions they want! like Oh I don't know Umm make .jpg files executable by the server. And you thought protecting against .php execution was going to cover your A.

But make sure only the folders requiring write access actually have it. 755 and 644 for the following folders.


And make sure you turn OFF .htaccess files with AllowOveride none for all writeable folders (like those above)

For those of you on shared hosting good luck as this is a configuration element you cannot control.

Dont think making the .htaccess file read only will help. If our hacker friends can create a new folder (they can) then they can create their own .htaccess.

For those of you running shared hosting for all that is sacred please get a clue about security.

If you do not understand security please get out of the hosting business you are making it tough for the rest of us.

Now back to my search for the definitive guide on folders needing write access...

  • Thanks Chris but I'll probably be sticking with the standard 755 and 644 file permissions while this is recommended by the official Joomla website and security experts such as Sucuri: docs.joomla.org/Security_and_Performance_FAQs blog.sucuri.net/2015/09/… – Neil Robertson Sep 7 '16 at 11:47
  • Yes I know its the "recommended" but once you have been exploited and work out why you were exploited I can assure you you throw the "recommendations" out the window and start from scratch. The recommendations are the path of least resistance. Not the most secure. – DeveloperChris Sep 8 '16 at 2:16
  • Steps 1 to 10 of the "Keeping a Joomla Website Secure" list at joomla.stackexchange.com/a/180/120 together with the standard file permissions has been working fine for the 50 or so websites I've been looking after for the last few years. Your mileage may vary of course. – Neil Robertson Sep 8 '16 at 3:11
  • @NeilRobertson I agree with that list but if there is an exploit which is not trapped by that, your last line of defence is to not give write permissions to the web server (apache et al). That's not a joomla specific piece of advice by the way. Also most people cannot implement many of the recommendations in that list. They simply do not have the resources or are using cheaper (not the cheapest) hosting. – DeveloperChris Sep 8 '16 at 5:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.