By drump on

Hi,

I am newbie to Drupal and trying to install it on Gentoo/Linux with nginx web server.

However installer found an error of  "Requirements problem" - "The directory sites/default/files is not writable."

Please inform how to grant permissions to web server?

If any additional information is needed please let me know.

Comments

hiramanpatil’s picture

hiramanpatil commented

Go to the path - sites/default/ and execute below command.

chmod -R 777 /files

[Check if you required root user permission to execute this command)

drump’s picture

drump commented

hiramanpatil Hi,

First I have done chmod -R 755 /files command as a root and got 2 errors:

"X  File system

Writable (public download method)
The directory sites/default/files is not writable"
And:
"X Settings file
The Settings file is not writable.
The Drupal installer requires write permissions to ./sites/default/settings.php during the installation process."
After your tip command chmod -R 777 /files I get only one error:

X Settings file

The Settings file is not writable.
The Drupal installer requires write permissions to ./sites/default/settings.php during the installation process. The webhosting issues documentation section offers help on this and other topics.
Please advise if need to change permissions to  /sites/default/settings.php as well,
and if granting 777 is not too open to the world, in terms of security issues?
Thanks
hiramanpatil’s picture

hiramanpatil commented

Yes, settings.php requires 777 permission while installation. Once you have set up Drupal site, you can reset settings.php file permissions to what is it now.

Thanks

mchplumber’s picture

mchplumber commented

how can we set in ngnix server? it's not working. 

mmjvb’s picture

mmjvb commented

When you can't figure out why security setting don't do what is expected you are probably running SELinux. It is an additional layer of security.

mabho’s picture

mabho commented

It has happened to me several times. I have seen experienced Linux server administrators scratching their heads, puzzled that the permissions set aren't actually working. Disabling SELinux is something to always keep in mind when installing Drupal.

sealionking’s picture

sealionking commented

after change the selinux config

with

sudo setenforce 0

the installation program works fine

https://wangjueju.cn

kuhan’s picture

kuhan commented

It's work for for Apache/2.4.6 (CentOS) PHP/7.3.20

Thanks

VivekDubey’s picture

VivekDubey commented

SELinux is there for a reason. It enforces access restrictions above the standard file system permissions and really makes your server more secure. You should try to make this work with SELinux enforced. The following commands can be used if SELinux is blocking the read/write operations:

chcon -Rv --type=httpd_sys_rw_content_t /var/www/html/sites/default/files/ (if your website is installed at root of Apache)
chcon -Rv --type=httpd_sys_rw_content_t /var/www/html/tmp/ (if your website is installed at root of Apache and tmp is at root)

chcon -Rv --type=httpd_sys_rw_content_t /path_to_your_drupal_root/your_drupal_folder/sites/default/files/ (Or if drupal is installed to any other path)

However, to change the mode from enforcing to permissive type:

sudo setenforce 0

And, to turn the enforcing mode back on, enter:

sudo setenforce 1

drump’s picture

drump commented

After chmod 777 the installation was finished and then chmod back to 755.

However now I get the first screen but can not log in - get 404 error??

Here my nginx.conf:

user nginx nginx;
worker_processes 1;

error_log /var/log/nginx/error_log info;

events {
    worker_connections 1024;
    use epoll;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main
        '$remote_addr - $remote_user [$time_local] '
        '"$request" $status $bytes_sent '
        '"$http_referer" "$http_user_agent" '
        '"$gzip_ratio"';

    client_header_timeout 10m;
    client_body_timeout 10m;
    send_timeout 10m;

    connection_pool_size 256;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 2k;
    request_pool_size 4k;

    gzip on;
    gzip_min_length 1100;
    gzip_buffers 4 8k;
    gzip_types text/plain;

    output_buffers 1 32k;
    postpone_output 1460;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

        server_tokens off;

    keepalive_timeout 75 20;

    ignore_invalid_headers on;

    index index.php index.htm index.html;
        #index index.php; 

    server {
        #listen 127.0.0.1;
        listen 0.0.0.0;
        # listen 192.168.1.6;
        server_name localhost;

        access_log /var/log/nginx/localhost.access_log main;
        error_log /var/log/nginx/localhost.error_log info;

    #    root /var/www/localhost/htdocs;
        #       root /var/www/localhost;
               root /var/www/localhost/htdocs/drupal;
                autoindex on;
        
        location ~ \.php$ {
                       # Test for non-existent scripts or throw a 404 error
                       # Without this line, nginx will blindly send any request ending in .php to php-fpm
                       try_files $uri =404;
                       include /etc/nginx/fastcgi.conf;
                       fastcgi_pass unix:/run/php-fpm.socket;
           }
        
    }

    # SSL example
    #server {
    #    listen 127.0.0.1:443;
    #    server_name localhost;

    #    ssl on;
    #    ssl_certificate /etc/ssl/nginx/nginx.pem;
    #    ssl_certificate_key /etc/ssl/nginx/nginx.key;

    #    access_log /var/log/nginx/localhost.ssl_access_log main;
    #    error_log /var/log/nginx/localhost.ssl_error_log info;

    #    root /var/www/localhost/htdocs;
    #}
}

ronimh’s picture

ronimh commented

I'm running into the issue with /sites/default/files under RHEL9 on AWS EC2. 

I have mariadb, php 8.2. and apache, and I've run the CHMOD 777 commands for the entire /sites folder and sub-folders (will change back later, BUT, despite this, I am still receiving the error below)

I at this point am stuck, can't get beyond it. Any ideas out there ?

Here's the ls of /var/www/html/drupal/sites/default

-rwxrwxrwx. 1 apache apache  9180 Mar  6 08:57 default.services.yml
-rwxrwxrwx. 1 apache apache 36101 Mar  6 08:57 default.settings.php
drwxrwxrwx. 2 apache apache     6 Mar 19 13:01 files
-rwxrwxrwx. 1 apache apache 36339 Mar 19 13:20 settings.php

Writable (public download method)

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.

texas-bronius’s picture

texas-bronius commented

@ronimh - You've stumbled upon the most irksome of irksome things: `./sites/default/` itself needs write/execute permissions. Tip: You can `ls -ld ./sites/default` to see folder permissions (without worrying cluttering with files within)

(sorry @drump - I d.o login had me redirected to the wrong comment to reply to ¯\_(ツ)_/¯)

--
http://drupaltees.com
80s themed Drupal T-Shirts

texas-bronius’s picture

texas-bronius commented

(edit - I removed my misplaced reply)

--
http://drupaltees.com
80s themed Drupal T-Shirts

ronimh’s picture

ronimh commented

Thanks ! 

Here's what I've got though at each level. 

Maybe I am misunderstanding something ? I've got it wide open just to try to get it to install but keep getting stuck.

I do like the word irksome regardless. 

Here's some listings at each level

[ec2-user@xxxxxxxxxxxx drupal]$ pwd
/var/www/html/drupal
 

[ec2-user@xxxxxxxxxxxx drupal]$ ls sites -l
total 20
drwxrwxrwx. 3 apache apache  120 Mar 19 13:20 default
-rwxrwxrwx. 1 apache apache  310 Mar  6 08:57 development.services.yml
-rwxrwxrwx. 1 apache apache 5586 Mar  6 08:57 example.settings.local.php
-rwxrwxrwx. 1 apache apache 2358 Mar  6 08:57 example.sites.php
-rwxrwxrwx. 1 apache apache  515 Mar  6 08:57 README.txt

[ec2-user@@xxxxxxxxxxxx drupal]$ ls -l
total 236
-rwxrwxrwx.  1 apache apache    312 Mar  6 08:57 autoload.php
-rwxrwxrwx.  1 apache apache   3551 Mar  6 08:57 composer.json
-rwxrwxrwx.  1 apache apache 173941 Mar  6 08:57 composer.lock
drwxrwxrwx. 12 apache apache   4096 Mar 19 23:54 core
-rwxrwxrwx.  1 apache apache   1495 Mar  6 08:57 example.gitignore
-rwxrwxrwx.  1 apache apache    549 Mar  6 08:57 index.php
-rwxrwxrwx.  1 apache apache     87 Mar  6 08:57 INSTALL.txt
-rwxrwxrwx.  1 apache apache  18092 Nov 16  2016 LICENSE.txt
drwxrwxrwx.  2 apache apache     24 Mar  6 08:57 modules
drwxrwxrwx.  2 apache apache     24 Mar  6 08:57 profiles
-rwxrwxrwx.  1 apache apache   3205 Mar  6 08:57 README.md
-rwxrwxrwx.  1 apache apache   2027 Mar  6 08:57 robots.txt
drwxrwxrwx.  3 apache apache    130 Mar  6 08:57 sites
drwxrwxrwx.  2 apache apache     24 Mar  6 08:57 themes
-rwxrwxrwx.  1 apache apache    804 Mar  6 08:57 update.php
drwxrwxrwx. 17 apache apache   4096 Mar  6 08:57 vendor
-rwxrwxrwx.  1 apache apache   4039 Mar  6 08:57 web.config
[ec2-user@xxxxxxxxxxxx drupal]$ cd sites/default

[ec2-user@ip-172-31-92-203 default]$ ls -l
total 84
-rwxrwxrwx. 1 apache apache  9180 Mar  6 08:57 default.services.yml
-rwxrwxrwx. 1 apache apache 36101 Mar  6 08:57 default.settings.php
drwxrwxrwx. 2 apache apache     6 Mar 19 13:01 files
-rwxrwxrwx. 1 apache apache 36339 Mar 19 13:20 settings.php

ronimh’s picture

ronimh commented

Ok. Once I finally got time from my day job...(ha ha) I went to the extreme step of grep-ing the code for the message I was receiving. I found the message in /core/modules/system.install. I then examined the call which as was simply an is_writable($directory) inside a loop of directories the installer checks. As shown in my last message, the files directory exists, and has full permissions, and so do the folders containing. I messed with the $directory value a bit still no success. 

I then searched for is_writable fails (without any mention of drupal) and came across various instances of this occurring. I also found in the php_manual that is_writable has a footnote in the doc that says "Keep in mind that PHP may be accessing the file as the user id that the web server runs as (often 'nobody')." 

I then thought maybe it was running the command as 'nobody', but that was not the issue. 

The issue in my case was that more than just the permissions are being considered. There is something called security context in the linux manual. 

Here's the brief explanation from the manual. 

Processes and files are labeled with an SELinux context that contains additional information, such as an SELinux user, role, type, and, optionally, a level. When running SELinux, all of this information is used to make access control decisions.

To update the context for the file path, run the chcon command, supplying the absolute path to files.  My system is just a proof of concept install attempt in EC2 with an RHEL9 AMI on AWS so I could verify it works, so my path was just /sites/default/files (within /var/www/html/drupal)

sudo chcon -R -t httpd_sys_rw_content_t /var/www/html/drupal/sites/default/files

I then refreshed the installer page and it advanced to Step 4 where the DB is to be configured. 

So.......Success !!!!

Rather than to move on through step 4, as I write this, I've decided to quit while I am ahead for the evening so that perhaps, I might just sleep !

Thanks everyone, I hope this helps anyone who runs into this. And thanks Texas-bronius, I believed your suggestion would work and I thank you for it !