Can I prevent module installation needing to connect to my FTP server?

Comments

LordOmega’s picture

I think I saw on the Drupal 7 tour video, that you could just enter the link to the Drupal module page, and then Drupal would automatically install it.

anewman1980’s picture

That's why I ask. I enter the link, then I am directed to a request for FTP details within Drupal.

LordOmega’s picture

Well, just fill up the details. Drupal makes the rest, no?

anewman1980’s picture

True but I was hoping there was some magic way of making it work like changing permissions, then I can miss out that step each time and do not have to send ftp password unencrypted.

tekkitan’s picture

FTP itself is unencrypted anyways unless you use SFTP, but I doubt Drupal supports that.

I have no idea why they warn you that you are not in an SSL session is FTP is unencrypted anyways. I'd really love a way to not use FTP at all to install modules because I don't use it. Full of security risks.

TheOptimizer’s picture

I have been fighting this problem several times, without success.
Now I have been able to pin down the problem.

The wanted behaviour is:

  • You paste the url of the module or theme you want to install
  • You click install
  • Your module or theme gets installed

What I have seen on several installations, and this is what you don't want:

  • You paste the url of the module or theme you want to install
  • You click install
  • It asks for some FTP (or SSH) credentials. WTF??????

To avoid this, make sure the folder /sites/default is OWNED by the user that executes the drupal scripts. On most Ubuntu installations, this is the apache user: www-data.

Don't ask me why this works. I don't know if this is intended or not. It doesn't make so much sense to me, but there might be an explanation. For me it would be OK that the temporary directory is writable by the apache user and the themes or modules folder is writable as well.

So this should do the trick when the user is www-data:
chown www-data sites/default

I hope this works. Please let me know.

femrich’s picture

I've just done a minor upgrade to version 7.8 and seeing this, but don't quite understand the solution here: How would I make sure sites/default is "owned" by the user executing the scripts? Is this something to do with permissions? Or do I need to write the code into a file? And how do I find out who the user is?

Thanks.

bensoi’s picture

subscribed.

hi there femrich! i use the same version of drupal. and i have the same questions as you. have you find solution to this? i also don't quite get the above solution.

many thanks ahead! :)

RKS’s picture

Is there a reason to use the install feature in Drupal? I always just ftp the files into sites/all/modules.

bensoi’s picture

well i do that for now, manual installation. but it would be better to use the automatic installation feature of D7. after all, it was put there to make life easier. :)

srikanth.g’s picture

i am using ubuntu 17.04 with xampp and drupal 8/7..tried all the chmod/chown commands but nothing is working.manual installation is finally Ok.

jcanfield55’s picture

Thanks very much for posting this fix. It worked like a charm and has saved me a lot of time using the Install module as it is intended.

ozozgur’s picture

Hi,
TheOptimizers soln. helps to go to the next step, where I faced another "not able to create folder" error.
If I create the folder in modules folder, and chown also to www-data, then the automatic installer can extract into that folder.

for example if I am to install views, I get:
"can not create directory ....sites/all/sites/modules/views"
I create it and chown to www-data and try again, and it works.

gagoo’s picture

Thanks, it works for me and your tip saved me a lot of time :)

But it is strange !!

pjmcghee’s picture

Thanks, Optimizer, this worked fine for me. Appreciate the help.

raulteixeira’s picture

Worked for me, with one minor change. I had to change ownership of the sites directory and all sub-directories (including default). I think this is because in my installation Drupal tried to create sub-directories that did not exist.

Anyway, here's the command I used:

sudo chown -R www-data sites

magixstar’s picture

This works for me. :)

Thanks!

andrezstar’s picture

cheers did struggle a bit

Fredsvanelli’s picture

Thanks, TheOptimizer
It worked perfectly! On linux, just do this:

1) Open terminal
2) "cd" to your drupal root directory
3) ~$ sudo chown www-data: sites/default
(there is a space between "www-data:" and "sites/")

That should do. If you have another problem with directory creation, try this:

4) ~$ sudo chmod 777 sites/all/modules

rmfranciacastillo’s picture

Thank you so much.

I've tried the scripts and it worked perfectly!

tompotter’s picture

Exactly what I was looking for. Thanks for posting this.

AlexNuvek’s picture

By changing the owner of the folders you eliminate the FTP requirement as described by TheOptimizer.
Be sure that you use www-data. Then you get the magic!
However you have to do the same for the target folders (modules, themes) otherwise Drupal is not able to create the folders for the new modules or themes, and you get an error message.

pjmcghee’s picture

On Drupal 7.16 (LAMP, Ubuntu 12.04 LTS) I had to use the chown command using the following syntax to allow the installation of new themes.

chown www-data themes

from /var/www/drupal/sites/all dir. i had received an error that was very similar to the one I received when i tried to install modules.

unable to create directory

rootnl’s picture

Had the same problem with Ubuntu 12.04. The Ubuntu package uses a symbolic link from /usr/share/drupal7/sites to /etc/drupal/7/sites. Therefor you have to do a chown on /etc/drupal/7/sites instead of use/share/drupal7/sites.

So try this:
sudo chown www-data:www-data /etc/drupal/7/sites -R

Hope it works for you.

GmanBB’s picture

Rootnl, a huge thanks for your code line. You saved me time and gray hair. :)

tovstiadi’s picture

From here: http://drupal.org/documentation/modules/update

Using Update Manager Without FTP

FTP is not required to install new modules or themes. If you have access to ssh for your web host you can enable Update Manager by ensuring that file ownership for your Drupal site is set to apache or www-data. An example of a command to accomplish this would be...

sudo chown -R www-data:www-data /var/www/drupal
or
sudo chown -R apache:apache /var/www/drupal

depending on your distribution.

There are security issues with doing the above. Please check with your system administrator first.

jayhaase’s picture

This worked for me on OS X: sudo chown -R _www sites

dskanth’s picture

Thanks, this command worked for me:

sudo chown -R apache:apache /var/www/html/drupal7

bhatmahesht’s picture

This worked for me for apache webserver running on CentOS. No need of any ftp details. Just change the ownership of drupal installation directory and its subdirectories to apache using chown command

--
Passionate about Drupal

ulnvo’s picture

For LinuxMint >17 (derivated from Ubuntu) your code has to be adapted because drupal is installed at /var/www/html/drupal

so you must write : sudo chown -R www-data:www-data /var/www/html/drupal

de_chris’s picture

Changing the owner of the default folder to www-data works like charme. Thanks
Tested with owner root and permission 777 doesn't work, don't know why.

svouthi’s picture

I've got my Drupal sites on a server with Apache ModRuid2 installed and enabled, which changes all site requests to the site owner and its permissions (rather than the Apache user and its) and therefore does away with the need for nobody or data-owned files/folders and provides for a more secure installation. Since moving my sites to this server setup the FTP credentials page is skipped when installing new modules.

Anonymous’s picture

Open terminal and type

$ sudo chown www-data sites/default
$ sudo chmod 777 -R sites/all

I know chmod 777 is very hardcore....but desperate situations call for desperate measures.

the 2nd command is to let Drupal create its own directories in Themes and Modules after downloading them.

WARNING! Don't try this in production. This is only meant for development environments.

Cheers!

Abelito’s picture

The folder containing the settings.php file must be owned by the server.
In most cases the folder is "sites/default"

Use this command to set it.
sudo chown _www sites/default

"_www" is typically the owner in OSX Server. Replace this if your server is different.

There is no need to set some crazy permissions like 777.

FerCamp’s picture

This worked for me.

For ubuntu server will be www-data.

thus,

sudo chown www-data sites/default

vcouver’s picture

Believe it or not, I had the same error message during "upload a new module".
I mean, without internet, because I only can use "Upload a new module" .
I must use a downloaded module, and not install from an URL.
Changing the owner of the default folder to www-data works

But I wonder how I can upgrade or update it, in the same conditions ?
https://www.drupal.org/node/2651368

VM’s picture

I no longer have any D7 sites to comment specifically to D7. However, in D8 go to your 'extend -> update' menu link. You will then be presented with a list of modules and themes to be updated when there are updates to be installed. Click on the download button and follow the instructions that follow.

Dstrider’s picture

Ownership issues maybe... used Nautilus to change to current user (and www-data)... gave everyone read/write... still goes to FTP

tiikeri’s picture

The drupal8's file system is different from drupal7. In drupal7 everything that is not part of the core goes under /sites folder; In drupal8 you need to fix permission issue also in *your-drupal-folder*/themes and *your-drupal-folder*/modules

I'm on debian and maybe for most debian derivates the commands are (supposing your root folder is called "drupal"):

chown www-data drupal/sites/default
chown www-data drupal/themes
chown www-data drupal/modules

Jorgas’s picture

Changing owner of these folders to www-data works not for me. Still looking for  a solution to this issue, any assistance will be appreciated.

UPD: Installed LAMP instead of LAMPP and all worked, thx.

omrmankar’s picture

Make sure the folder /sites/default is OWNED by the user that executes the Drupal scripts.

On most Ubuntu installations, this is the user Apache user www-data.

Goto Drupal Root File Path Then Run This Command 

chown www-data sites/default

Best regards,

Omprakash Mankar
Senior Drupal Developer

fultonchain’s picture

You can the following to your settings.php:
$conf['allow_authorize_operations'] = FALSE;

https://www.drupal.org/project/issues/1377512

gurcharan’s picture

This command works for Ubuntu.

sudo chown www-data sites/default -R

bmateus’s picture

For centos 7 in apache, you should use

sudo chown apache [dir to your drupal installation]/sites/default

Bruno Mateus

genfoch01’s picture

first thanks i just ran into this issue on drupal 8.9.2  and the chown did fix the issue for me.  Interesting note, when following the drupal security guidance ( ref: https://www.drupal.org/node/244924 ) which comes down to 
a) directories should be 750
b) files should be  640 
c) file owner should NOT be the apache(webserver id) 
d) special case for the files directory  ( and its sub folders 770 ) and files in it (600 ) to allow uploads from the web ui 
             and files and directories SHOULD be owned by the web server

this means the web ui has no permissions to write to or update drupal files which breaks updating or installing a new module via the ui

consequently,  you can't use drupal best practice (for dir and file permissions ) or you have to change them when you do an update and change them back when you're done.  ( have a script for this now). it does mean to run and update via web ui, I also must have command line access to run the script before and after. 

based on the security discussion (above ) it seems they (drupal ) want to move to using composer to manage all module installations and updates ( which would avoid this permissions issue we all encountered ) but still at the same time they still support the update via web ui,  i have not found anything to say they are going to remove such support either. 
Drupal seems to be in a strange place where following their best practices breaks supported functions. I'd really like to see a road map depicting how they plan to address this issue in the future.  That being said, i am not an expert so maybe there is some existing doc that does address this, i just haven't seen any.