Last updated July 21, 2016. Created on August 4, 2009.
Edited by saurabh.dhariwal, Jaypan, progga, rdtome. Log in to edit this page.

Drupal Config File "settings.php" and "services.yml" Overview

In order for Drupal to work, you have to configure where the database is, what the database is called, and the database credentials to access the database. This information is stored in the settings.php file which is located in:


The settings.php file is common to Drupal 6, 7 and 8

When you first extract Drupal, it doesn't come with a settings.php file, instead it comes with default.settings.php. When you first install Drupal 7 or 8, it will attempt to copy and rename default.settings.php -> settings.php for you. There are some rare instances where you will need to do this manually which are covered in detail further down on this page.

New to Drupal 8 in the sites/default folder, is a file named Just like default.settings.php, has to be renamed in order to work. However, this file is designed for overriding the core services.yml file if you need to override it and 99% of sites out there, won't ever need to override the core services.yml file. It is made available if you do need to override those settings though. In early development, this file was automatically copied and renamed during install, however Stop creating services.yml by default supersedes the early method. In other words, don't ever worry about / services.yml unless something tells you otherwise.

Finally, the purpose of having default.[config-file].php is so you can easily update Drupal, without overwriting the entire configuration that runs your site. Yes, there was a time when that happened...

Automatic settings.php Overview

By default, Drupal 7 and 8 (6?) will attempt to create and populate the settings.php file automatically when you use install.php to setup the site. The script also changes the permission on the file to secure it once it is finished and then creates a sites/default/files directory for housing all of your non-core files. Unfortunately, some types of shared/local hosting are configured so PHP and Apache run as the same user. This might result in the install script failing to execute the creation and population of the settings.php file, along with setting permissions and creating the files directory. If you get errors referring to the Settings file during installation, you will have to manually create the settings.php file and do a few more tasks before you can run install.php. Once it is created with write permissions, the installation script will automatically populate the proper information for your site config. Afterwards, you will have to re-secure the settings.php file.

At this point, jump to the next page step: Step 4: Run the installation script. If you run into problems with the installation due to the Settings, come back here and follow the Manual steps outlined below.

Manual settings.php Overview

Drupal 6, 7 and 8 come with a sample settings.php configuration file located at: sites/default/default.settings.php
Before you run the installation script (install.php), you need to copy default.settings.php file as a new file called settings.php and change its permissions to be writeable. After the installation, you will need to restrict the permissions again.

Manual settings.php Detailed Instructions

Step 1 - Navigation & Creation

Navigate to sites/default of your root Drupal install.

Copy the default.settings.php file and save the new file as settings.php in the same directory (see note below about renaming). If you have shell access (command line) run the following command from the directory that contains your Drupal installation files:

cp sites/default/default.settings.php sites/default/settings.php

Note: Do not simply rename the file. The Drupal installer needs both files.

If you only have FTP access, you will have to download the file to your computer, rename it, then upload it. Some hosting providers have a file manager on the dashboard where the file can be copied and renamed.

Step 2 - Check the Permissions Are Writeable

By default, the sites/default directory and the settings.php file should be writeable. You can check that the permissions of sites/default and settings.php are writeable by issuing the following commands:

ls -l sites/

Permission on sites/default should be 755 [drwxr-xr-x]:

ls -l sites/default/settings.php

Permission on settings.php should be 644 [-rw-r--r--]:

If they are anything but writeable, you can issue the following commands:

chmod 644 sites/default/settings.php

Note: If you are in the same group as the web user, then changing the permissions to 664 will be sufficient.

Several FTP tools like Filezilla, Transmit, and Fetch allow you to change file permissions, using a 'file attribute' or 'get info' command. In this case the file permission should be set to 644. If your FTP client has checkboxes for setting permissions, check both the Read and Write boxes for "Owner", "Group", and "Others" (but leave the Execute boxes unchecked). For some situations, you may need a permission of 664. Some hosting providers allow a similar operation through the dashboard file manager.

Step 3 - Try the Install

At this point, give the install a go. See if you can get through the installation by running http://[yoursite]/install.php. If you are successful, the first page you will want to visit is Reports -> Status report (admin/reports/status)

On the reports page, look for a line that says: File system. If it says anything other than "Writeable", you will need to follow Step 4 below.

Next, look for a line that says: Configuration file. If it says anything other than "Protected", then you will need to re-secure the configuration files as described in Step 5 below.

Step 4 - Create the Files Directory

The installation should have created the sites/default/files directory for you, but in the off chance it didn't, you will need to create it manually and set the right permissions on it.

mkdir sites/default/files

Note:On most linux systems, a newly created directory is already setup with the 755 permission. In case it isn't, you can issue the command:

chmod 755 sites/default/files

This sets the files directory to 755 [drwx-rw-rw].

Depending on how your apache configuration is setup, you might have to instead run:

chmod 777 sites/default/files

This sets the files directory to 777 [drwxrwxrwx]. It is less secure than 755, but there's nothing you can do about it if that's how your server is setup.

Step 5 - Post Install Permission Check

After the installation script has run, Drupal tries to set the permissions automatically to:

555 (read-execute) [dr-xr-xr-x] for the sites/default folder.
444 (read-only) [-r--r--r--] for the settings.php

If not, you will need to manually set them:

chmod 555 sites/default
chmod 444 sites/default/settings.php

These permissions are correct, and should not be changed, because changing these opens up a security risk.

Looking for support? Visit the forums, or join #drupal-support in IRC.


lostchord’s picture

You need to do a bit more if you have SElinux enabled (a good idea):

chcon -t httpd_sys_content_rw_t settings.php

This will leave it writeable by the httpd daemon after the event as well.

We are born naked, wet, and hungry. Then things get worse.

claverfred’s picture

am getting a problem in running the installation script,every time am sticking at the second step "verifying the requirements"
i dont know what is the problem while I followed the procedures in setting.php

Steady’s picture

I'd love to know this too:

"After installing Drupal 7, what should the file permissions be for

-default folder
-sites folder
-files folder

I have ready many different things on this, and it seems everyone has a different opinion. (from 000 to 444 to 644 to 555 to 755). Can someone set the record? What should those file permissions be so that they are a) Most secure b) Will not mess anything up?

Does anyone have the final answer for this?

seniorOtaka’s picture

i installed drupal 7.8 on a server successfully but while i'm using the site like configuring modules or changing the settings of the themes the servers blocks my ip
when i tried to understand what is going on the server admin told me to adjust the files permissions and cookies usage for drupal
how can i do this?
Note: i 'm extracting the drupal files in the root directory (Public_html)

ruzer’s picture

Help me.
It is permission?

Notice: Undefined index: minnelli in /var/www/ruuser/data/www/ on line 63

Notice: Trying to get property of non-object in /var/www/ruuser/data/www/ on line 104

Notice: Trying to get property of non-object in /var/www/ruuser/data/www/ on line 452

Notice: Trying to get property of non-object in /var/www/ruuser/data/www/ on line 452

Notice: Trying to get property of non-object in /var/www/ruuser/data/www/ on line 452

Notice: Undefined index: minnelli in /var/www/ruuser/data/www/ on line 1023

Notice: Trying to get property of non-object in /var/www/ruuser/data/www/ on line 1035

Notice: Trying to get property of non-object in /var/www/ruuser/data/www/ on line 1044

Notice: Undefined index: minnelli in /var/www/ruuser/data/www/ on line 216

Notice: Trying to get property of non-object in /var/www/ruuser/data/www/ on line 216

Warning: array_keys() [function.array-keys]: The first argument should be an array in /var/www/ruuser/data/www/ on line 219

Warning: Invalid argument supplied for foreach() in /var/www/ruuser/data/www/ on line 219

Warning: include(./themes/garland/maintenance-page.tpl.php) [function.include]: failed to open stream: No such file or directory in /var/www/ruuser/data/www/ on line 1078

Warning: include() [function.include]: Failed opening './themes/garland/maintenance-page.tpl.php' for inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/ruuser/data/www/ on line 1078

pavlovt’s picture

I don't know how exactly you ware able to accomplish this :)
Please give me more details on how you did the installation otherwise I cannot help you.
There maybe a problem with permissions because it cannot load maintenance-page.tpl.php

Why don't you start with new installation - Drupal checks for it's requirements and gives warnings if something is not ok

cwhy’s picture

i have changed all the files and directories in drupal folder to 777 but why drupal still shows"The Drupal installer requires write permissions to ./sites/default/settings.php"...............

femim’s picture

I had the same problem. SELinux was running and enforced.

asesortecnologico’s picture

Please can you help?, I have installed and properly configured Drupal 6.XX permissions, folder either (755) and file (644), but when accessing the Web site throws me the following message:

You don't have permission to access / on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

thanks you...


femim’s picture

If you have SELinux running turn it off. Check the error_log for the web server. It maybe that it is not able to read the .htaccess file

lostchord’s picture

If you have SELinux running then see my reply earlier in this thread (May 2011).

We are born naked, wet, and hungry. Then things get worse.

joevansteen’s picture

This covers settings.php during the initial install process. But what about during upgrades? What is the appropriate way to update/upgrade the settings.php file when doing a Drupal upgrade which may have changed some of the content in the default.settings.php file? Is there any standard practice on this? Will Drupal "update" upgrade the file based on the new default.settings.php file, or is it a case of needing to make those changes by hand? A link to any "best practices" would be appreciated.

joevansteen’s picture

From the Drupal upgrade.txt file:

Sometimes an update includes changes to default.settings.php (this will be noted in the release notes). If that's the case, follow these steps:

  • Make a backup copy of your settings.php file, with a different file name.
  • Make a copy of the new default.settings.php file, and name the copy settings.php (overwriting your previous settings.php file).
  • Copy the custom and site-specific entries from the backup you made into the new settings.php file. You will definitely need the lines giving the database information, and you will also want to copy in any other customizations you have added.

This was from D7.14, so I guess I answered my own question. It does change, but the updates need to be made manually.

Brian Patrick Fromme.’s picture

The mark of the beast 666 is the file extension. No way. I have serious issues with this.

tgeller’s picture

If you don't want to type:

chmod 666 sites/default/settings.php can type:

chmod a+w sites/default/settings.php

instead. They do the same thing.

Tom Geller * * Oberlin, Ohio
See my videos about Drupal

kate_h’s picture

My host has the file at 555

I installed via fantastico.

bdavis113’s picture

I have installed ckeditor and finder, and it appears to have been successful.

However, when I click on the browser server button to be able to go to the area to upload an image, the next thing I see is this message:

The file browser is disabled for security reasons. Please contact your system administrator and check the CKFinder configuration file.

I have read the article, and adjusted my security settings according to what is stated. But I am still getting this message.

I am running Drupal 7, and nothing else fancy at this point. I have very little content on my site at this point other than a few pieces of test content. Because this is such a huge part of what I need for other content to be put in place.

Any thoughts? I can upload screen shots, and if necessary provide access.

Thank you,

RobKay’s picture

In fact, granting rights for "others" and the "group" is not needed, nor desirable.

In a shared hosting environment, which effectively is a single-user environment, this is ok, but as soon as you go out to a root server, where other users (that you might seem to trust) have access to, you will want to protect your installation to not see anything of it. Only the user running the webserver should be able to read the files, so I suggest to restrict the files appropriatley.

These commands, fired off on a system where drupal resides in /var/www/drupal and the running user is www-data, restrict access to all the files to that exact user and allow write access in sites/default/files:

chown -R www-data. /var/www/drupal
chmod -R u=rX,go= /var/www/drupal
chmod -R u+w /var/www/drupal/sites/default/files

Adjust to your needs, YMMV.

Do not EVER use XX4 or XX6 rights, as almost NEVER the group of "other" user need access to any of your files, nor does the group of the webserver (in most cases). To be precise: a chmod 644 something should always be a chmod 640 something to prevent anyone from reading your files.

Hope this helps.


vchen’s picture

Do we need to update settings.php with each new drupal core update/upgrade?

Usually, when I update core, the first thing I do is delete the sites folder, which contains the default.settings.php.

Until recently, I decided to look at drupal 7.20's default.settings.php and noticed some changes. Should I be updating my settings.php to the new code found in default.settings.php? What's the best practice for this?

thekurt’s picture

Securing file permissions and ownership

On the page there's a thorough explanation on permissions settings.

On that page is a comment with all the numerical values off the permissions you have to set for files and directories:

And if you're short in time you'll find a summary of that comment a wheelscroll deeper or click here:


humberto.sachs’s picture

The instructions are quite detailed and excellent if the user has access to a terminal ON THE SERVER. For most of us, we depend on popular and efficient host tools, which do not allow terminal mode. I am offering to help Drupal build a tmED type of instructions. But I need to have contact with a collaborator which is an expert on Drupal. Anyone there? We could make all the difference in the world for an easy installation and site build up.

payamf1’s picture

I tried several times to run Drupal on localhost but I have a problem.
when I create the database on root user and copy the both "default.settings" and "settings" files on the proper folder, I set "write" permission to "settings.php" file in Security tab to this names: IIS_IUSRS and IUSR afterwards.
then after writing database information down in the form (at localhost) I get "Fatal error: Maximum execution time of 30 seconds exceeded in C:\xampp\htdocs\drupal\includes\database\ on line 2168" error.

Can anyone help to solve this problem.

bawoor’s picture

find php.ini file in xamp folder (or subfolder), change maximum execution value to 300 second or more.


t@nh@. .’s picture

    • for linex users
    • open the terminal and got to /etc/php5/apache/
    • when you are in apache do ls and there is a file named php.ini
    • edit the file (it may have the non writable permissions)
    • you may edit using sudo vim php.ini
    • then go to line number 444
    • the default execution time is 30 seconds (max_execution_time = 30)
    • change 30 seconds to 300 seconds
    • now it will never show the error
    • for windows users
    • go to c/xamp/php/
    • in php folder there is a file named php.ini
    • edit that file and set maximum execution time to 300 sec
    cricket’s picture

    I have just installed DRUPAL 7.34 and I found the instructions very useful. But because of the recent security fix, there is a need for an additonal .htaccess file under /settings/default/files/

    It would have been easier to add this when I first created the files directory, rather than to go back and create it after an error on the Status Report page.

    zaza2015’s picture

    where should i run these instruction? cmd?

    kop524’s picture

    Hi I'm new to drupal and when I want to make a copy of sites/default/ I'm getting File or DIrectory not found and when I check all the folder oin the Drupals dir I cant find it :( I have tried to download about 4-5 times and everytime i cant get this file. Im installing version 7.34 and tried 9.x dev on ElemetaryOS Luna(Debian/ubuntu based os) and both have same issue :(

    Webgirl’s picture

    Hi kop524

    Am also new to drupal but I see you are using Debian/ubuntu.
    On windows I didnt make the changes to services.yml.
    Am not sure though, I thought it was for Version 8.
    Ok things might be different for you as you are using a different OS to mine.

    See the copy
    Those permissions should be set as:
    chmod 644 sites/default/settings.php
    chmod 755 sites/default

    For Drupal 8 also set
    chmod 644 sites/default/services.yml

    ...end of copy

    Hope you get some help.
    All the best

    Jaypan’s picture

    See the copy
    Those permissions should be set as:
    chmod 644 sites/default/settings.php
    chmod 755 sites/default

    This was incorrect, and the page has been edited.

    After installation, the permissions should be:
    sites/default: 555
    sites/default/settings.php: 444

    The Drupal organization has shut down discussion on improvement of the forums:

    It's time to start a new forum somewhere else. The Drupal organization does not care about the forums.

    Ebube1995’s picture

    In step 3 of the installation process, when it was said that http://[yoursite]/install.php .i do not know what yoursite should be

    Jaypan’s picture

    It's whatever domain name you used to install Drupal.

    The Drupal organization has shut down discussion on improvement of the forums:

    It's time to start a new forum somewhere else. The Drupal organization does not care about the forums.

    Ebube1995’s picture

    in the section for database support, it is writing disables , "Disabled
    Your web server does not appear to support any common PDO database extensions. Check with your hosting provider to see if they support PDO (PHP Data Objects) and offer any databases that Drupal supports."

    Jaypan’s picture

    That means you need to enable the PDO extension.

    The Drupal organization has shut down discussion on improvement of the forums:

    It's time to start a new forum somewhere else. The Drupal organization does not care about the forums.