A lot of new Drupal users run into issues getting Drupal to work properly on their webhost. These problems are not Drupal problems as such, they are usually the way the webserver is configured. Complex and functional web applications like Drupal will naturally require a lot more from a web server than just hosting a static HTML site would.

Note: There are webhosts that offer Drupal specific hosting for those without the time or inclination to do it themselves. A few stand out by also supporting the Drupal community. If you need a host, consider selecting one of our reviewed web hosts.

Unfortunately there is usually a knowledge gap between the Drupal installation documents and the exact environment a new user is confronted with when attempting to install and configure Drupal. For more experienced users that have a little Unix and Apache (a typical webhost setup) knowledge under their belts, bridging the gap between their webhosting environment and the general purpose Drupal installation guide is no problem. Things are more confusing for less experienced users though. The following info is intended to help newbies come to grips with the documentation and their webhosts environment.

There are a wide range of web site configuration tools (eg CPanel, Plesk, webmin etc) and near infinite number of ways a webhost could configure a webserver. What this means is that a lot of the general Drupal docs you read will have to use the lowest common denominator (ie Unix shell commands) to describe configuration steps.

Less experienced users will not fully understand what these commands do or why they should do them, and definitely won't know when to deviate from them. To make matters worse most webhosts don't even offer shell access, so the instructions need to be 'translated' to whatever control panel they offer.

The following topics will hopefully provide just enough insight into Apache and Unix that new users will be able to better understand the installation documentation and 'tune' their sites for running Drupal without too much pain. As a new user you might also gain an understanding of why most of the docs are written the way they are.

Comments

suffering drupal’s picture

I get this error when doing fresh install:
"The directory sites/default/files does not exist. An automated attempt to create this directory failed, possibly due to a permissions problem. To proceed with the installation, either create the directory and modify its permissions manually, or ensure that the installer has the permissions to create it automatically. For more information, please see INSTALL.txt or the on-line handbook."

Two things:
1 - sites/default/files DOES exist.
2 - Why does the error message only say that the permissions have to be modified, but doesn't say what those permissions should be in the same go (666, 665,...) ? So typically Drupal...

o, and still: 3 - where on THIS page is the explanation or the link to "sites/default/files permission settings"?

Install.txt says: "chmod o+w sites/default", what's that in fileZillian?

I started with Drupal in 2007 and then my life got stuck...

suffering drupal’s picture

I don't understand why there is not a clear list to the numerous basic issues that only would need their own OFFICIAL checklist. It feels all so tremendously "insider" focussed...
The only thing I found on this issue is (very long thread and only filled with doubts by the way):
http://drupal.org/node/244924#comment-2689024

This is NOT an official setting but just an interpretation of someone who too has doubts "As I read (and re-read) the instructions ...." "... I think this is what they mean". However, since I am sure he'll understand better than I, I'll give it a bet. And at least he writes it out in a very complete and plain ready to use way.

For the "files" directory inside Drupal's "sites" directory:
Path: /sites/files or /sites/default/files
Symbolic notation: rwxrwxr-x
Octal numbers: 775
Which means:
Owner: read, write, execute
Group: read, write, execute
Others: read, execute

Now I only hope this is correct and will not give us the problems that had us stuck for over 6 months on an official Drupal server who kind of just kicked us away, because "we had our site set in such a clumsy way" instead of helping us out. Later it turned out to be a major error in don't remember what core module that caused memory overload.

I started with Drupal in 2007 and then my life got stuck...

suffering drupal’s picture

Those settings worked :)

I started with Drupal in 2007 and then my life got stuck...

bevSDC’s picture

Thanks! I took the path name literally and couldn't understand why it didn't work when I created /sites/default/files and gave it the right permissions.

TimesArrow’s picture

i have mac ppc 10.5.8, mamp pro 1.9.6.1. installing drupal 7.

kept getting same as you - sites/default/files DOES exist - did change to chmod 777 - reinstall and get the same.

deleted drupal 7 and downloaded drupal 5.9 and completed install first time with no error messages on the install EDIT- now i'm getting "The following error must be resolved before you can continue the installation process:" "The Drupal installer requires write permissions to ./sites/default/settings.php during the installation process." i can't delete this post so i just quickly updated it.

--------------------------
The virtual host was set up successfully.

If you can see this page, your new virtual host was set up successfully. Now, web contents can be added and this placeholder page1 should be replaced or deleted.

Server name: localhost
Document-Root: /Applications/MAMP/htdocs

1 Files: index.php and MAMP-PRO-Logo.gif

This page in: Deutsch
---------------------------

haydenhancock’s picture

I just wanted to let people know about my experience with installing Drupal on a Rackspace Cloud Site.

I was receving the same error as mentioned above. I was able to resolve this issue by NOT changing the permissions in the first place. Leaving the default permissions seemed to work fine in my instance.

brandeeb’s picture

I've installed Drupal many times, but I've never come across this problem. I know that when you are running the install, you need to chmod the /sites/default/files and sites/default/settings.php so that apache can write to it. I usually just change it to 777, then when the install is complete, change it back to 775. But right now, this permissions error is coming up.

{[(Web server Apache/2.2.15 (CentOS)

-Error
File system
The directory sites/default/files is not writable. An automated attempt to create this directory failed, possibly due to a permissions problem. To proceed with the installation, either create the directory and modify its permissions manually or ensure that the installer has the permissions to create it automatically. For more information, see INSTALL.txt or the online handbook.

Settings file The ./sites/default/settings.php file exists.

-Error
Settings file The settings file is not writable.
The Drupal installer requires write permissions to ./sites/default/settings.php during the installation process. If you are unsure how to grant file permissions, consult the online handbook.)]}

Now I'm not sure what's wrong with the installation. I've gone so far as to chmod 777 all of the directories up to my /home . I haven't a clue. Has anyone else had this problem, and if so, how did you fix it.

Konstantin Korepin’s picture

I also encountered this problem when installed Drupal. This instruction came to my rescue and helped me
this link help you :). The problem was in SELinux.

brandeeb’s picture

I'm not root or a sudo-er. I'm actually in an IT class that we've all been given 2 databases to do whatever we please, just to learn. The mediawiki I set up worked brilliantly. But I really want a drupal site too. And it's just not working. I cannot do anything in the /var/www/html because I don't have that kind of access. I do it all in the public_html directory. Any other ideas?
Thanks!

mogmog’s picture

right click drupal directory, choose Properties. on the Permissions tab, change SElinux content from User_data to httpd_user_content_t, click Apply Permissions to Enclosed Files. if httpd_user_content doesn't exist you'll have to ask someone with root access to solve the problem.

ps: did someone notice that php 5.3.10 for fedora 16 came with dom disabled?

dRumata’s picture

You are absolutely right. Its SELinux

When dealing with SELinux we need to update context of the /var/www/html/sites/ to read and write:

# chcon -R -t httpd_sys_content_rw_t /var/www/html/sites/

If you have moved or copied Drupal installation files make sure that:

  • all files belong to Apache user
  • you set SELinux context with chcon -R -t httpd_sys_content_t /var/www/html/
  • you have changed SELinux context of /var/www/html/sites/ with the above command
RoboFish’s picture

When using some Apache web hosting environments, it's often easiest to simply change permissions of a file or folder to 777. But, I try to avoid this whenever possible as it creates a security risk. As correctly noted above, "make sure that: all files belong to Apache user". With my host (running Plesk), if Apache will be writing to a particular directory (/sites/default/), the owner and group of the directory needs to be changed to "apache". With this change, the 0755 permissions are sufficient.

Kurrent’s picture

In Ubuntu 12.04 with xampp you should have your Drupal file in htdocs.
Open your home file and in the left menu select File System > opt > lampp > htdocs. In htdocs go to (filename of your Drupal folder) > sites > default and if there is not a files folder then create a folder called "files" without the quotes . Next copy default.settings.php and paste it in the same folder and rename it "settings.php" without the quotes.
Next right click the files folder you just made and select properties. Select the permissions tab and change all three folder access settings to "Create and delete files". tick the Execute box. and close the properties. Remember what you changed them from because you will be prompted to change them back later.
Right click the settings .php file and select properties. Select the permissions tab and make sure everything has "Read and write" then tick the Execute box. Close permissions. You should be able to complete the install now.

jimbaer’s picture

Some hosts use an Apache Mod_Security filter to remove threats. Versions of this filter prevent calls to the javascript file; jquery.cookie.js , which is used by Drupal 7 for drag and drop in lists, and in menus. So, if these are malfunctioning, ask your host if they're using Mod_Security, and if so, please disable it for your domains.

If they won't, you can fix the problem by going to "performance" and select the option "aggregate javascript files"

Rosamunda’s picture

I´ve started with Drupal a long time ago. I always put 777 each time it asked me for permissions.
Now I´ve got a new Drupal 7 site to install, and thought that maybe 777 wasn´t the safest way. But since 755 didn´t worked for me, I always went for the 777 chmod instead. Up until now.
I´ve tried to stop and actually carefully read all the information that´s in the installation wizard.

After changing the settings file accordingly, I´ve read this:
"The Drupal installer requires write permissions to ./sites/default/settings.php during the installation process. If you are unsure how to grant file permissions, consult the online handbook." And there´s a link to this page.

Naturally, when you click that link you expect something like "Here´s how you do grant permissions to files and folders..."

But instead, the link points you to a page with webhosting issues, and the first thing it tells you is that you can use specific drupal hostings...
So for newbies, the first thing that you think "is there a problem with my webhost"?
Well, no. The only thing is that you should change the chmod configuration.

Why the page won´t tell you this? I´ve read the whole thing and it won´t clearly tell you how to configure the chmod. And I´m not the only person that tells you this, there are more comments wondering exactly the same. And those comments are quite older that mine.

In fact, I´m still wondering which number combination should be the safest one that works, because 777 isn´t safe, and 755 won´t work (at least in my case).

I´m a big fan of Drupal and specially the Drupal team, please, don´t take this badly, it´s just a personal feeling after reading this particular page of the documentation.

Thanks,
Rosamunda

marptr’s picture

For Windows that are using IIS, the solution is described in http://drupal.org/node/202491
and this solves both the problem of:

  • The directory sites/default/files does not exist
  • The Drupal installer requires write permissions to ./sites/default/settings.php during the installation process.

You jsut need to apply the same procedure on both the files directory and the settings.php file.
No need to restart IIS for this.

Allenb’s picture

I happened to have the same exact issue with one of my web sites. First of all putting 777 for all permissions is a big no no especially with IIS its sort of like you're begging to get hacked. You can set the permissions just for one file for example sites/default/settings.php and you can change back the permissions for that file later on once youre done programming the site so youre sure ypoure site is safe and sound. I had one site percisionbits.com that actually forgot to change back the permissions and before we knew it the entire site was messed up and don't forget you're talking about a brand new site here, so dont forget to change back the permissions.

pacific101’s picture

I've read through this thread and like so many others before me I'm getting the files not existing nag when the files do in fact exist, I've changed the permissions as suggested and like everyone else it doesn't seem to help. I'm hosting the site in question on a Linux Server and have no intention of going back to a Windows server with this particular site so saying that Drupal 7.0 isn't compatible with Linux is not a solution in my mind anyways. I thought Drupal was supposed to be be open source and not proprietary, that is why I opted to build my blog with it, not I feel like I'm being pressured in leasing a proprietary server in order for my site to function properly, and possibly having to hire the services of one of it's developers to configure my newly leased server for me? is that the underlying game plan with Drupal? If that is the case then the folks behind the Drupal programing need to cut to the chase and spit that out in black and white so that all of us who are investing our time and energy in a program that was introduced to me anyway as open source will know that it is or that it is not and so we can continue to try and work with it or so we can convert over to word press or one of the many other open source programs at our disposal. I can understand leasing server space and services from the creators of Drupal if you are wet behind the ears with no hosting experiences or resources of your own, but not for someone who has a good many years of hosting and coding experience behind them. I await direction from someone on this matter.

hamonwry’s picture

Links to "reviewed providers" and those "supporting the community" list no shared hosting providers. Are there none that support Drupal? If not, perhaps the link should open to one of the other tabs (Enterprised & managed and Platform as a service).

Kosmoseistis’s picture

Hello,

I installed drupal succesfull. I had to change te permissions from:

files map
settings.php

to 777

I know i have to change this back to something else to make my site/server safe for hackers...

But do not know to wich combination...

My geuss is 775 (translation: full access for the owner{drupal}, everyone else has read and execute access)

Can somebody confirm this and learn me something more?

Thanks for reading and your advice :-)
Kosmoseistis

grumpy_old_troll’s picture

The right thing to do probably is to set the owner to the same as the web server.

$ ps aux | grep apache2
root     17276  0.0  1.6 289640 16836 ?        Ss   19:21   0:00 /usr/sbin/apache2 -k start
www-data 17279  0.0  0.7 289900  7396 ?        S    19:21   0:00 /usr/sbin/apache2 -k start
$ sudo chown www-data:www-data $DOCROOT/sites/default/files

After that, it's not world-writable but it's writable by your web server, so the error goes away.

Cheers and hope that helps.

Yousufzai’s picture

Dear All,

You are kindly request to please help me to solve the following problems. Email me (abdulhabiby@yahoo.com)

File system
The directory sites/default/files is not writable. An automated attempt to create this directory failed, possibly due to a permissions problem. To proceed with the installation, either create the directory and modify its permissions manually or ensure that the installer has the permissions to create it automatically. For more information, see INSTALL.txt or the online handbook.

Settings file The settings file is not writable.
The Drupal installer requires write permissions to ./sites/default/settings.php during the installation process. If you are unsure how to grant file permissions, consult the online handbook.

AlbionBrown’s picture

@Yousufzai, I know your post was 8 months ago but I'll post anyway

I had the exact same issue. But, I managed to get the install working by applying 755 on the sites/default directory and then temporarily applying 664 permissions on the settings.php file. After the install was successful, I changed that back to 644.

debasisnaskar’s picture

how to access my sites folder and all other folders and sub folders when we install drupal on cloud based server?? I installed drupal on console.developers.google.com, but couldn't be able to access my drupal installed files and folder from google though there is no such cPanel or anything like that. please help me out how to recover this issue. Thanks.

Julian D Gray’s picture

I found that with Drupal 8 on Centos 7 and multiple virtual sites on Apache changes to folder permissions (e.g. 777) made no impact.

Required instead is:

chcon -R -t httpd_sys_content_rw_t /var/www/...../....../....../sites/

This fixed my setting and get Drupal up and running - no messing.

yuseferi’s picture

This worked for me on Centos 7 and Drupal 8

first cd to drupal directory then

chcon -R -t httpd_sys_content_rw_t .

I have be born to be mankind

takis’s picture

This command exactly works for my installation.
Thanks a lot.

alreaud’s picture

I've been working with Drupal 8.1.8, trying to install a multi-site on my local host before setting it up on the production host. I'm running Apache2 and MySQL on Ubuntu 16.04. I kept having the problem where it said that though ./sites/default/settings.php was present, it couldn't read them and followed the link to this thread. Permissions were 660. Going back to the sites/default directory, I noticed that the group was wrong on settings.php and services.yml for my installation of Apache2.

Apache2 on the local host has the group "www-data". settings.php had the ownership:group as localuser:localuser. That was the problem! Ownership of settings.php for my local installation has to be localuser:www-data for Apache2 to be able to read/write to it.

If you're having the problem of being unable to read and/or write settings.php on a hosting account, and permissions are correct across the directory tree and settings.php, check that when you copied default.settings.php and default.services.yml to settings.php and services.yml that the copy left them both in the proper ownership:group for that hosting service. That is hosting account dependent, BTW, depending on whether the installation is being hosted on your own servers, or on a shared server, like Godaddy, Bluehost, etc.

Sanjeevmec’s picture

installation problem

Yanivs’s picture

Apache2 on Ubuntu 18.04.4, Drupal 8.8, had the same problem.

Solution:
Changed ownership of all directories and files of Drupal installation to www-data:www-data (meaning user www-data and group www-data):

$ sudo chown -R www-data:www-data drupal_root_directory

Change drupal_root_directory to the path of your Drupal root directory.

trinadh’s picture

In my case, even with all the above-mentioned solutions, I was still having the problem of improper file permissions during the installation.
It turns out changing SELinux config to the disabled has solved the problem. Since we didn't have SELinux policies it's ok to disable it.

in Centos 7/RHEL, execute the following to get the SELinux status

getenforce

if you see 'enforcing'

go to /etc/selinux and edit 'config' file. Replace 'enforcing' with 'disabled'

Reboot the server.

Now, when you check the status, it should say 'disabled'.

Then try to install your Drupal site.

erics1337’s picture

I solved this error "The directory sites/default/files does not exist. An automated attempt to create this directory failed, possibly due to a permissions problem. To proceed with the installation, either create the directory and modify its permissions manually, or ensure that the installer has the permissions to create it automatically. For more information, please see INSTALL.txt or the on-line handbook."
by actually just deleting the settings.php and services.yml files.

rcaceres’s picture

If SElinux is active it will prevent the DRUPAL config change in ../sites/default/files/

Check status with sestatus

$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33

To set SElinux to permissive without rebooting your server use:

$ setenforce 0

$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33

Check this for other options to disable selinux (permissive)
https://www.thegeekdiary.com/how-to-disable-or-set-selinux-to-permissive...

ressa’s picture

It looks like these commands will take care of the requirements for installing a standard Composer-based Drupal 10 with a relocated document root (/web):

$ cd my_drupal_installation/web
$ mkdir sites/default/files
$ cp sites/default/default.settings.php sites/default/settings.php

Make settings.php writable during installation

$ chmod u=rw,g=rw,o= sites/default/settings.php

Return to the original permissions after installation

$ chmod u=rw,g=r,o= sites/default/settings.php

bardiuk’s picture

How to solve this issue? Seach of word "private" doesn't give me anything.

Writable (public download method)
The directory ../private is not writable. An automated attempt to create this directory failed, possibly due to a permissions problem. To proceed with the installation, either create the directory and modify its permissions manually or ensure that the installer has the permissions to create it automatically. For more information, see INSTALL.txt or the online handbook.
AppleBag’s picture

I've been holding off forever to upgrade from D5 to the latest specifically because messing w/Drupal has always been a huge headache. I'm just now giving it another go by installing D10 in the "official" container and I'm already beyond frustrated just trying to get the container up and running in an actually useful way, with bind mounts, and here I am reading 50 confusing comments simply on how to set perms properly when it should all automatically be handled for us in a polished way.

This is why Wordpress has long taken the lead; it's so much more polished and user friendly.