WordPress File Permissions

WordPress File Permissions

Different files and directories in Linux-based file system use permissions to indicate who and what can read, write, modify and access them. WordPress file permissions matter because it might want access to write to files in your wp-content directory.

Permission Modes

7 5 5
user group others
r+w+x r+x r+x

4+2+1  4+0+1  4+0+1 = 755

WordPress file permissions modes are computed by adding up the following values for the user, the file group, and for everyone else. The diagram illustrates this.

  • Read 4 – Allowed to read files
  • Write 2 – Allowed to write/modify files
  • eXecute 1 – Read/write/delete/modify/directory
7 4 4
user group others
r+w+x r r

4+2+1  4+0+0 4+0+0  = 744

Example Permission Modes

Mode Str Perms Explanation
0477 -r–rwxrwx owner has read only (4), other and group has rwx (7)
0677 -rw-rwxrwx owner has rw only(6), other and group has rwx (7)
0444 -r–r–r– all have read only (4)
0666 -rw-rw-rw- all have rw only (6)
0400 -r——– owner has read only(4), group and others have no permission(0)
0600 -rw——- owner has rw only, group and others have no permission
0470 -r–rwx— owner has read only, group has rwx, others have no permission
0407 -r—–rwx owner has read only, other has rwx, group has no permission
0670 -rw-rwx— owner has rw only, group has rwx, others have no permission
0607 -rw—-rwx owner has rw only, group has no permission and others have rwx

Permission Scheme for WordPress

WordPress file permissions will vary between hosts, so we can only outline general principles here and can’t cover all scenarios. This guide is relevant to servers that run a standard setup (note, for shared hosting using “suexec” methods, see below).

Usually, all files should be owned by your user (ftp) account on your web server and should be writable by that account. On shared hosts, files shouldn’t ever be owned by the webserver process itself (sometimes this is www, or apache, or nobody user).

A file that needs write access from WordPress should be owned or group-owned by the user account used by WordPress (which may be different from server account). For instance, you might have a user account that lets you send files to your server via FTP, but the server itself may run under a separate user, in a separate usergroup, like dhapache or nobody. If WordPress is running as the FTP account, that account must have write access, meaning it must be the owner of the files, or be in a group that has write access. If that’s the case, it would mean permissions are set more permissively than default (for example, 775 rather than 755 for folders, and 664 instead of 644).

The file and folder permissions for WordPress will probably be the same for most users, depending on how you installed it and the umask settings of your system environment at the time of installation.

You probably won’t need to be changing file permissions if someone with experience installed WordPress for you. It’s best not to alter his unless you’re having problems with permission errors, or you know what you’re doing. If you installed WordPress yourself, you probably WILL need to change WordPress file permissions permissions. Some files and directories should be “hardened” with more strict permissions, in particular, the wp-config.php file. To start with, this file is created with 644 permissions, but it isn’t safe to leave it like that.

In most instances, all essential WordPress files should only be writable by your user account (or the httpd account, if it’s different). ( Sometimes though, numerous ftp accounts may be used to manage an installation, and if all ftp users are known and trusted, meaning not shared hosts, it may be okay to assign group writable. Ask your server admin about this. ) However, if you make use of mod_rewrite Permalinks or other .htaccess features you should ensure that WordPress can also write to your /.htaccess file.

If you’re going to use the built-in theme editor, all files need to be group writable. It’s best to use it before you go changing file permissions. (This may hold true if different users uploaded the WordPress package and the Plugin or Theme. This wouldn’t be a problem for Plugin and Themes installed using the admin panel. When you upload files with different ftp users, group writable will be needed. On shared hosting, ensure the group is exclusive to users who you trust… an apache user shouldn’t be in the group and shouldn’t own files.)

Some plugins need the /wp-content/ folder to be made writeable, but in cases like this, you will be informed about it during installation. In some instances, you may need to assign 755 permissions. This is also true for /wp-content/cache/ and possibly /wp-content/uploads/ (if you’re using MultiSite setup you may also have to do this for /wp-content/blogs.dir/)

Additional directories under /wp-content/need to be documented by whichever plugin / theme requires them. Permissions will vary.

|- index.php
|- wp-admin
|   `- wp-admin.css
|- wp-blog-header.php
|- wp-comments-post.php
|- wp-commentsrss2.php
|- wp-config.php
|- wp-content
|   |- cache
|   |- plugins
|   |- themes
|   `- uploads
|- wp-cron.php
|- wp-includes
`- xmlrpc.php

Shared Hosting with suexec

This may not apply to shared hosting systems that use the “suexec” approach for running PHP binaries. This is a popular approach which many web hosts use. With these systems, the php process runs as the owner of the php files themselves, which simplifies configuration and provides a more secure environment for shared hosting.

Do not use suexec methods on a single-site server configuration. They are only the most effective option for shared hosting.

With suexec configuration, the correct WordPress file permissions scheme is easy to understand.

  • All files should be owned by the actual user’s account, not the user account used for the httpd process.
  • Group ownership is not relevant unless there are particular group requirements for the web-server process permissions checking. This doesn’t usually happen.
  • All directories should be 755 or 750.
  • All files should be 644 or 640. Exception: wp-config.php should be 440 or 400 to stop other users on the server from reading it.
  • Directories should never be given 777, not even upload directories. As the php process is running as the files’ owner, it gets the owners permissions and can even write to a 755 directory.

With this particular type of setup, WordPress detects that it can directly create files with the proper ownership, and so it will not need to request FTP credentials when it has to install or upgrade plugins.

sysadmins use these popular methods are set up:

  • suPHP: runs through php-cgi, currently unmaintained since 2013.
  • mod_ruid2: apache module, currently unmaintained since 2013.
  • mpm_itk: apache module.
  • mod_fcgid: an Apache module and FastCGI server with more extensive configuration.

PHP-FPM, an alternative FastCGI server with shared OPCode, for use with Apache and Nginx.

How to Use the Command Line

If you have shell/SSH access to your hosting account, you can use chmod for changing file permissions, which is the preferred method for experienced users. Before you start using chmod it’s recommended that you go through some tutorials to ensure you understand how it works. If you set the wrong WordPress file permissions you could end up taking your site off-line, so it’s best to be safe rather than sorry.

You can make all the files in your wp-content directory writable in two steps, but before you do, consider safer options like modifying just the directory first. Give each of these commands try first, and if they don’t work then go recursive. This will even make the image files of your themes writable. Replace DIR with the folder you want to write to

chmod -v 746 DIR

chmod -v 747 DIR

chmod -v 756 DIR

chmod -v 757 DIR

chmod -v 764 DIR

chmod -v 765 DIR

chmod -v 766 DIR

chmod -v 767 DIR

If those don’t let you write, try each of them again in order, only this time put-R instead of-v, which will recursively modify each file that’s in the folder. If that still doesn’t work then try 777.

About Chmod

chmod is a Unix command which means “change mode” on a file. The -R flag tells it to apply the change to every file and directory inside wp-content. 766 is the mode we are changing the directory to, and it makes the directory readable and writable by WordPress and any and all other users on your system. At last, we have the name of the directory we are going to modify, wp-content. If 766 doesn’t work, then try 777, which makes every file and folder readable, writable, and executable by all users, groups, and processes.

If you use Permalinks then remember to change WordPress file permissions of .htaccess to ensure that WordPress can update it when you change settings, like when you a new page, redirect, category, etc. which requires updating the .htaccess file when mod_rewrite Permalinks are being used.

  1. Go to the main directory of WordPress
  2. Enter chmod -v 666 .htaccess

From a WordPress security point of view, even a little protection is better than a directory that’s wide open to anybody to rewrite. Start with low permissive settings like 744 and work your way up until your successful. Only use 777 if you have to, and hopefully then only for a short while.

The dangers of 777

The root cause of this permission situation is the manner of your server configuration. The username you use to FTP or SSH into your server is probably not the username that the server application itself uses to serve pages.

7 7 7
user group others

4+2+1  4+2+1  4+2+1  = 777

The Apache server is frequently ‘owned’ by the www-datadhapache or nobody user accounts. These accounts have limited access to files on the server, and with good reason. If you set your personal files and folders owned by your user account to be World-Writable, that’s exactly what you are doing. It means that the www-data, dhapache and nobody users that run your server, serve pages, execute php interpreters, and so on, can get at all of your user account files, and they can do this using any process on the server.

That’s why it’s best to only change WordPress file permissions when you are forced to, and even then with great care. We’ve never come across a situation what warranted more than 767, so it’s hard to imagine why 777 would be required.

If you do use 777 permissions, what’s the worst that could happen? Well, a nefarious individual could upload a harmful file, or inject malicious code to gain total control of your blog, its database and password info.

You can easily get the enhanced features that WordPress plugins can provide without exposing yourself to risk. The Plugin author or your server support should be able to give you a workaround.

Finding Secure File Permissions

The .htaccess file is one that’s accessed by the owner of the process that runs the server. So, if your WordPress file permissions are set too low, your server will be denied access to the file and return an error. It shows you the way to find your best settings. Start with greater restriction and then relax it until it works.

The example below has a custom compiled php-cgi binary and a custom php.ini file located in the cgi-bin directory for executing php scripts. To stop a web browser directly accessing the interpreter and php.ini file they are protected by a .htaccess file.

Default Permissions (umask 022)

  • 644 -rw-r–r–  /home/user/wp-config.php
  • 644 -rw-r–r–  /home/user/cgi-bin/.htaccess
  • 644 -rw-r–r–  /home/user/cgi-bin/php.ini
  • 755 -rwxr-xr-x  /home/user/cgi-bin/php.cgi
  • 755 -rwxr-xr-x  /home/user/cgi-bin/php5.cgi

Secured Permissions

  • 600 -rw——-  /home/user/wp-config.php
  • 604 -rw—-r–  /home/user/cgi-bin/.htaccess
  • 600 -rw——-  /home/user/cgi-bin/php.ini
  • 711 -rwx–x–x  /home/user/cgi-bin/php.cgi
  • 100 —x——  /home/user/cgi-bin/php5.cgi

.htaccess permissions

644 > 604 – The bit giving the group owner of the .htaccess file read permission was got rid of. 644 is normally recommended and needed for .htaccess files.

php.ini permissions

644 > 600 – Before, all groups and all users with access to the server could access the php.ini, even just by requesting it from the site. The difficulty is that because the php.ini file is only used by the php.cgi, we only needed to ensure the php.cgi process had access. The php.cgi runs as the same user which owns both files, so that single user is now the only user which can access this file.

php.cgi permissions

755 > 711 This file is a compiled php-cgi binary used in place of mod_php or the default vanilla php which the hosting company provides. The default permissions for this file are 755.

NoSQL vs SQL: Examining the Differences and Deciding Which to Choose


At 74, Larry Ellison, co-founder and CTO of Oracle has amassed a fortune of $66.1 billion. He got going in 1966 and in the seventies took an idea from IBM’s Edgar F. Cobb for a SQL relational database. This became the Oracle Database rdbms (relational database management system). With no free software competitors, Oracle totally dominated the market. Everything else, like DB2 was running on IBM mainframes, and even it couldn’t oust Oracle from its top position. Mainframes remained popular until the 1990s, when PCs started to be used as servers, as they still are today. Oracle is still in the top spot for the majority of transactional business applications used by the richest companies. It bought the commonest opensource, MySQL, along with opensource Java, but both are still free to use. The big choice for all companies is still SQL vs NoSQL – between relational (SQL) or non-relational (NoSQL) data structure. Both are great in their own way, and both come with pros and cons of course, which we’ve listed for you here.

What is SQL?

SQL (Structured Query Language) organizes information in relational databases. It’s used in Oracle, Sybase, Microsoft SQL Server, Access, and Ingres. SQL uses relations (usually referred to as tables) to store and match data using shared features within the dataset.

It was Cobb’s notion that you could have a database that could be queried using a structured query language. He used SQL to create data in objects known as tables, along with the schema for that data, which describes fields in columns. One SQL record is known as a row.

What is NoSQL?

A NoSQL database describes itself, so it doesn’t need a schema. It also doesn’t mandate relations between tables in all scenarios. It only uses JSON documents, which are self-contained and easy to understand. NoSQL means high-performance, non-relational databases that use many different data models. They are known to be easy to use, have scalable performance, are resilient, and also widely available. NoSQL database examples include MongoDB, MarkLogic, Couchbase, CloudDB, and Amazon’s Dynamo DB.

NoSQL vs SQL: Major Differences

When choosing a data management system for your organization, you need to take into account the many and varied differences between SQL and NoSQL. There are differences in:

  • Language
  • Scalability
  • Community
  • Structure


Use of a Structured Query Language makes any SQL-based database very versatile and helps to explain why it is used so widely. On the downside though, this also restricts it. You have to use predefined schemas to set out the structure of your data before you can even get started. Your data has to use the same structure too, structure as well, you may have to invest considerable time into pairing your data to make it ready.

A NoSQL database has a dynamic schema for unstructured data which can be stored in a lot of different ways, including graph-based, document-oriented, column-oriented, or organized as a KeyValue store. Being highly flexible like this means you won’t be burdened with the same amount of preparation. You’re free to add fields as you go and vary the syntax from database to database. Every document can have its own individual structure, so have a great deal of latitude.


Another significant difference between SQL and NoSQL is how scalable they are. With the majority of SQL databases, can scale them vertically, meaning individual servers can be boosted through the addition of more RAM, SSD, or faster CPU. But NoSQL databases scale horizontally, meaning that they can handle increased traffic simply by adding more servers to the database. NoSQL databases have the ability to become larger and much more powerful, so they are great for handling large or constantly evolving data sets.


SQL has been around for long enough now that its community is large and well developed. If you need a query answered or want to pick up new skills, there are seemingly endless forums full of experienced users who will be glad to help you out. NoSQL can’t match this level of peer support yet because it’s the new kid on the block, so unfortunately, you’ll have to come back in a few years.


SQL databases use a tables approach which makes them better suited to handling apps that ask for multi-row transactions. Accounting systems or legacy systems that were originally created for a relational structure are examples of these. NoSQL databases can be key-value pairs, wide-column stores, graph databases, or document-based.

SQL or NoSQL: Which One is Going to Fit Your Business?

The best way to determine which database is right for your business is to look at what you need it to do. If you need a predetermined structure, multi-row transactions and set schemas then SQL is the one to go for. It’s also highly consistent, which makes it an ideal choice for accounting systems.

If your company is growing rapidly and doesn’t need clear schema definitions, then NoSQL is what you want. A relational database won’t offer as much flexibility as NoSQL, which is great for companies that need to churn through large amounts of data that comes in varying structures.


We can see that the first field is teacher and the second field is subject.

{ teacher:  "James Smith", subject:  "literature" }

With SQL, you create this schema before adding it to the database:

CREATE TABLE teacherSubjects (
teacher varchar,
subject varchar

Varchar is variable character length. To add data to that table, you would:

INSERT INTO teacherSubjects (teacher, subject)
VALUES ("James Smith", "literature");

With a NoSQL database, in this example using MongoDB, you would use the database API to insert data like this:

db.teacherSubjects.insert( { name: "James Smith", subject: "literature" } )

Now you can create the union (all elements from two or more sets) and intersection (common elements of two or more sets) of sets using SQL.

This was such a big deal because all this could be programmed using simple SQL syntax. Then Oracle added indexing fields and caching records to improve performance and make sure that the database could complete referrals with integrity. (Referential integrity is about the completeness of transactions, so you aren’t left with orphaned records. For instance, a sales record with no product to go with it. This is what enforcing the relationship between tables refers to in Oracle.)

Note that in the above MongoDB example, Oracle programmers would call the teacherSubjectes table an intersection. It tells you what subjects a teacher has and also which teachers are in which subject. So you could also add things like subject room number and teacher email address to both records.

The Oracle database is known as a row-oriented database because that’s how it’s organized. There’s no need to turn our attention to column-oriented databases like Cassandra here, because they have different architecture. So, they are not so fundamentally different as SQL vs NoSQL. In particular, the Cassandra NoSQL database columns with similar data near to each other for the fastest possible retrieval. Cassandra and NoSQL databases do away with the concept of database normalization, which is fundamental to Oracle, as we outline below. And they don’t keep empty column values, so the rose can be different lengths.

Normalization and Efficiency

Something which Oracle emphasized was the relationship between objects, insisting that all data should be normalized, and nothing should be stored twice. In practical terms, instead of repeating the school address in every teacher record, it would be more efficient to keep a school table and put the address there. This constraint is largely absent in NoSQL databases, so it wins out here in the SQL vs No SQL debate.

Storage space and memory were costlier in the 1970s, so normalization was necessary. These days though, assembling a record that is split between different tables takes more of both, not to mention the fact that you also need to maintain index files, which can slow everything down.

Fans of NoSQL databases say memory and storage are so cheap and processing power so exponentially faster now that none of that really matters. The computer can handle it and it’s easier for programmers to code.


SAP is Oracle’s biggest business competitor and has its own database, Hana. Oracle keeps all its records in memory (flushing them to disk as necessary) for the speed advantage it brings, but apart from that, they work in pretty much the same way.

NoSQL has been around for so long that it’s hard to argue a business case for changing to a newer one. When firms already understand rdbms, why switch? Oracle has solved management issues like data replication, which might leave someone using, ElasticSearch, for instance, unsupported with a compromised system on their hands. To avoid this, some businesses support opensource databases, like ElasticSearch, in-house, so you can buy in the help you need from them.

There’s been a big shift towards transactional systems. The addition of a sale to a sales database is an easy-to-understand concept. Once it’s done, Oracle calculates on-hand inventory using a saved SQL operation called a view. For MongoDB, a program would have to go through inventory items and takeaway the sales to work out the new on-hand inventory.

NoSQL Databases in Action

Looking at MySQL vs NoSQL, it’s interesting to note that NoSQL databases tend to be used in niche rather than enterprise systems. Uber is a good example as it uses Cassandra to keep tabs on its drivers, but it has unique needs, like writing millions of records a second across many data centers. The company wrote its own version of Cassandra in order to have it run on Mesos. Mesos is an orchestration system that resembles containers.

Amazon markets is a DynamoDB database which has “millisecond latency.”

DynamoDB, like MongoDB, has a JavaScript interface, which makes it simple to use. To add a record, for instance you open the database, then add a JSON item like this:

var docClient = AWS.DynamoDB.DocumentClient()
docClient.put("{JSON … }"}

One implementation detail is that you can use Node.js to run these operations in MongoDB and DynamoDB. Which means JavaScript running in the middle tier, so you don’t have to create JAR files or middleware servers like Oracle Weblogic.

So, which of the two is best for you? You could still run your accounting system on a RDBMS system. But don’t necessarily need to pay licensing fees to Oracle. You could use MySQL instead. But will it use MongoDB? That is unlikely in the short term, as huge numbers of programmers across the globe use Java and Oracle, which project managers and users understand. Use ElasticSearch for logs and Spark for analytics. With the others, look at them individually to see if they will fit in with your resources, skills, tolerance for suffering lost transactions, etc.


Whatever your field, selecting the correct database for your firm is a crucial decision. NoSQL databases are rapidly establishing themselves as a significant force in the database landscape. They bring many benefits: they are cheaper, are open-source, and easily scalable, which makes NoSQL more appealing for anyone who needs Big Data integration. It’s a new technology though, which can bring its own problems.

SQL databases, in contrast have had more than four decades to establish their well-defined. A mature community offers almost limitless possibilities for collaboration and support.

In the end, the choice of SQL vs NoSQL for business will come down to the individual needs of the companies concerned. Only through extensive research comparing their abilities to your needs will you find the one that is the best fit.

What is LAMP? LAMP stack basics to get you up and running fast

LAMP stacks

The LAMP stack has nothing to do with lighting, but it’s still a pretty bright idea (sorry, couldn’t resist!) It underpins many of the world’s most widespread open source web apps, like WordPress and Drupal, but its history goes back further than just being the bedrock of those currently popular platforms though. It’s one of the web’s original open source software stacks, and many developers still turn to it today when they are working on new custom web apps. As a developer you’ll find yourself running into it a lot too because it’s everywhere, and you’ll appreciate the fact that its uncomplicated and robust.

What is LAMP?

Glad you asked. LAMP stands for Linux, Apache, MySQL and PHP, and each one of them adds something unique to the development of high-performance web applications.

  • Linux: the LAMP Stack’s operating system. Linux started life in 1991. It’s an open source operating system and its free. It’s endured partly because it’s flexible and other operating systems are harder to configure. It’s used around the world and has proved itself in lots of different industries. So, it has a loyal fan base willing to shout its praises and help new users get up to speed.
  • Apache: the LAMP Stack’s web server. Apache HTTP Server is a free web server software package made available under an open source license. It used to be known as Apache Web Server when it was created in 1995. It offers a secure and extendable Web server that’s in sync with current HTTP standards.
  • MySQL: the LAMP Stack’s dbms. MySQL is a relational database management system used to store application data. It’s open source, and it lets you keep all your data in a format that can easily be queried with the SQL language. SQL works great with well-structured business domains and it’s a great workhorse that can handle even the largest and most complicated websites with ease.
  • PHP: the LAMP Stack’s programming language. PHP is an open source scripting language. It fits hand in glove with Apache to make building dynamic web pages a breeze. For instance, it steps into do what HTML can’t: enabling dynamic processes that involve pulling elements out of a database. PHP makes it easy to do tasks like this. You can add your code to the page at the part that you want to be dynamic, and hey presto! Job done. It’s an efficient and flexible language, and you can see the results of your new code as soon as you’ve written it. Just add it, hit refresh and it’s there. But if you’d prefer to use Perl or Python instead then you can, no problem. (Isn’t it handy that they both begin with the P?)

What is LAMP architecture like?

LAMP architecture is layered in the classic style, with Linux at the bottom, followed by Apache, MySQL, then PHP. Although PHP sits on the highest layer, it’s actually inside Apache.

How do the elements work together?

It all begins when someone’s browser sends a request for a web page to the Apache web server. If it’s for a PHP file, the request is forwarded to PHP, which loads the file and runs its code, then asks MySQL to fetch any information that the code may have referenced.

The code and the data it pulls up are used to create the output that lets browsers display webpages. The LAMP stack is good at delivering both static and dynamic pages, which is good because this is slightly more difficult to achieve because as the name suggests, dynamic content can change every time the page is loaded.

Once the file code has been run, PHP sends the data it produces back to the Apache web server, which then shunts it on to the browser, and this new data can also be stored in MySQL.

We haven’t mentioned Linux, but it’s the base on which all of this rests.


As the name suggests, the LAMP stack is based on Linux, but you could also use Windows if you needed to, which would give it the equally attractive title of a WAMP stack. You can swap in Mac OS to get a MAMP stack, or there’s even WIMP, which uses Windows and the Internet Information Services web server from Microsoft.

But the beauty of the LAMP stack is that all its components are free and open source, so you’re not tied in to use or pay for any of them. You just use what you need, when you need it.

The LAMP stack is flexible in other ways too. Apache has a modular design, so it’s possible to add on custom modules to extend functionality.

It’s also worth mentioning that the LAMP stack features enterprise-level encryption and security, so it’s “as safe as houses,” as they say.

Improving Efficiency – LAMP vs LEMP

The LAMP stack is a veteran that has been around for more than 10 years now, which means there are plenty of users who’ve been building modules for it for ages. The advantage of this is that whatever you might need to build for your own project, a lot of the work will have been done already. It’s great knowing that whatever you need, the work of others is waiting to help you cut down on your development time.

Another way to gain efficiency is by replacing Apache with NGINX, which is an is  an open-source high-performance web server is a web server which can also be used as a reverse proxy, mail proxy, load balancing solution and HTTP cache. NGINX focuses strongly on high concurrency, high performance and low memory use. Nowadays NGINX powers variety of high-load sites including Pinterest, Cloudflare, Airbnb, Netflix, Hulu, WordPress.com and GitHub.