2

enter image description here

As the above screen shots, from Drupal 7 shows, the updates are downloaded! However, it still says Updating modules and themes requires FTP access to your server.

I have tried the ownership of sites directory as whole sudo chown www-data sites. I also tried chmod -R 777 sites. Is there any other way beside having to configure an FTP server, and if it must need a FTP, what is the directory I should set it to files?

2
  • I wouldn't recommend to use FTP, it's not Secure. Rather use FileZilla with SFTP to transfer the updated module files.
    – No Sssweat
    Jul 13 '20 at 1:53
  • @NoSssweat I already have installed Filezilla, but I don't know how to configure it to do the task!
    – SaidbakR
    Jul 13 '20 at 1:56
4

I sometimes have seen that message with Drupal 7, and I always got confused about why Drupal was asking for FTP access to save files in the same server it was running, and why I didn't get that message in some Drupal 7 installations.

Looking at the code used from Drupal to updates the modules, I then discovered Drupal first checks if local file transfers are allowed. If they aren't allowed, that message will be shown.
In particular, this is the code Drupal uses. (See update_manager_local_transfers_allowed().)

  // Compare the owner of a webserver-created temporary file to the owner of
  // the configuration directory to determine if local transfers will be
  // allowed.
  $temporary_file = drupal_tempnam('temporary://', 'update_');
  $local_transfers_allowed = fileowner($temporary_file) === fileowner(conf_path());

In other words, if the account owning a temporary file created in the temporary directory set up for the site isn't the account owning the directory containing the settings.php file used for the site, Drupal will show the message you saw.
Setting the temporary directory and the directory containing the settings.php file to be owned from the same account will make updates from the user interface possible via local file transfers. In this case, Drupal won't show any message about the FTP access being required.

update_manager_local_transfers_allowed() is called from _update_manager_check_backends(), which contains the following code. (The comments explain what is happening and why.)

  // If file transfers will be performed locally, we do not need to display any
  // warnings or notices to the user and should automatically continue the
  // workflow, since we won't be using a FileTransfer backend that requires
  // user input or a specific server configuration.
  if (update_manager_local_transfers_allowed()) {
    return TRUE;
  }

  // Otherwise, show the available backends.
  $form['available_backends'] = array(
    '#prefix' => '<p>',
    '#suffix' => '</p>',
  );
  $available_backends = drupal_get_filetransfer_info();
  if (empty($available_backends)) {
    if ($operation == 'update') {
      $form['available_backends']['#markup'] = t('Your server does not support updating modules and themes from this interface. Instead, update modules and themes by uploading the new versions directly to the server, as described in the <a href="@handbook_url">handbook</a>.', array(
        '@handbook_url' => 'http://drupal.org/getting-started/install-contrib',
      ));
    }
    else {
      $form['available_backends']['#markup'] = t('Your server does not support installing modules and themes from this interface. Instead, install modules and themes by uploading them directly to the server, as described in the <a href="@handbook_url">handbook</a>.', array(
        '@handbook_url' => 'http://drupal.org/getting-started/install-contrib',
      ));
    }
    return FALSE;
  }
  $backend_names = array();
  foreach ($available_backends as $backend) {
    $backend_names[] = $backend['title'];
  }
  if ($operation == 'update') {
    $form['available_backends']['#markup'] = format_plural(count($available_backends), 'Updating modules and themes requires <strong>@backends access</strong> to your server. See the <a href="@handbook_url">handbook</a> for other update methods.', 'Updating modules and themes requires access to your server via one of the following methods: <strong>@backends</strong>. See the <a href="@handbook_url">handbook</a> for other update methods.', array(
      '@backends' => implode(', ', $backend_names),
      '@handbook_url' => 'http://drupal.org/getting-started/install-contrib',
    ));
  }
  else {
    $form['available_backends']['#markup'] = format_plural(count($available_backends), 'Installing modules and themes requires <strong>@backends access</strong> to your server. See the <a href="@handbook_url">handbook</a> for other installation methods.', 'Installing modules and themes requires access to your server via one of the following methods: <strong>@backends</strong>. See the <a href="@handbook_url">handbook</a> for other installation methods.', array(
      '@backends' => implode(', ', $backend_names),
      '@handbook_url' => 'http://drupal.org/getting-started/install-contrib',
    ));
  }
  return TRUE;

As side note, the temporary directory is the one set on admin/config/media/file-system, which by default is set to /tmp.

screenshot

Note also that, as 4k4 said in a comment, updating modules or themes from the user interface is a security risk. In fact, it requires the system account used to run PHP to be able to write files in the directory containing the modules. For example, with that permission, a malicious script could alter the submission callback used for the user login form, and add code that sends the login credentials to a remote server.
For a general discussion see Should PHP run as www-data or as the user who owns the website? where one of the comments says:

PHP should NEVER have write access to or ownership of the files it executes, or the directories they reside in. I cannot emphasize this strongly enough. It just takes one security vulnerability, and now you're phishing, hosting a reverse shell, spamming, participating in an outbound DoS, or otherwise compromised, because an attacker used PHP to write a malicious script into a place where it could be executed. #3 is the best solution, best implemented by changing the group of the upload directory to www-data and giving group write access. Also ensure that nginx will not ask PHP to execute scripts stored in that directory.

6
  • 2
    Great answer, I didn't know that Drupal was able to update its own PHP files. To be on the safe side, it is not advisable to change the file ownership only to use this update method. Better keep the ownership separate, see drupal.org/docs/security-in-drupal/…
    – 4k4
    Jul 13 '20 at 11:38
  • What reported in drupal.org/docs/security-in-drupal/… is compatible with what the update code expects, as long as MYUSER:www-data is the user account and the group used to run PHP. Differently, Drupal would not be able to write files in the module directory. Note also that those recommendations aren't valid for the /tmp directory, which is outside the Drupal root directory.
    – apaderno
    Jul 13 '20 at 12:35
  • I totally agree that updating/installing modules from the user interface should be avoided, at least on production servers. The risk is that a hacker installs a script that is able to write in the directory containing the modules. If the user account running PHP doesn't have access permission to files (which means that user account doesn't own the files), there isn't that risk.
    – apaderno
    Jul 13 '20 at 12:39
  • 2
    I found the following: In the tmp directory, all modules are downloaded and extracted there. So, just copying them to sites/all/modules and allowing override, then running update.php will do the update.
    – SaidbakR
    Jul 13 '20 at 14:45
  • 1
    @SaidbakR Yes, that works too.
    – apaderno
    Jul 13 '20 at 14:47

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.