Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By anewman1980 on
Can I prevent module installation needing to connect to my FTP server?
Comments
I think I saw on the Drupal 7
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.
That's why I ask. I enter the
That's why I ask. I enter the link, then I am directed to a request for FTP details within Drupal.
Well, just fill up the
Well, just fill up the details. Drupal makes the rest, no?
True but I was hoping there
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.
FTP itself is unencrypted
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.
Solution for unwanted question about credentials
I have been fighting this problem several times, without success.
Now I have been able to pin down the problem.
The wanted behaviour is:
What I have seen on several installations, and this is what you don't want:
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.
I've just done a minor
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.
subscribed. hi there femrich!
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! :)
_
Is there a reason to use the install feature in Drupal? I always just ftp the files into sites/all/modules.
well i do that for now,
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. :)
manual installation is my final decision
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.
Worked for me
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.
works but also need to add the module folder and chown
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.
Thanks
Thanks, it works for me and your tip saved me a lot of time :)
But it is strange !!
chown www-data sites/default - worked
Thanks, Optimizer, this worked fine for me. Appreciate the help.
Solution for unwanted question about credentials
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
Solution for unwanted question about credentials
This works for me. :)
Thanks!
cheers did struggle a bit
cheers did struggle a bit
Works!
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
Works on Ubuntu 14.04
Thank you so much.
I've tried the scripts and it worked perfectly!
Many Thanks
Exactly what I was looking for. Thanks for posting this.
Change the folder owner
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.
Error installing new theme
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
Had the same problem with
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.
A million thanks!
Rootnl, a huge thanks for your code line. You saved me time and gray hair. :)
Official answer
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.
User for OS X
This worked for me on OS X: sudo chown -R _www sites
This worked for me
Thanks, this command worked for me:
Worked for me
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
Adaptation for linux Mint >17 and Ubuntu>12.04
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
works
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.
Drupal on servers with Apache mod_ruid
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.
This fixed it for me
Open terminal and type
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!
This is still the case in Drupal8
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.
This worked for me.
This worked for me.
For ubuntu server will be www-data.
thus,
sudo chown www-data sites/default
It works with "upload"
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
=-=
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.
Drupal 8, Ubuntu, XAMPP, still forces FTP
Ownership issues maybe... used Nautilus to change to current user (and www-data)... gave everyone read/write... still goes to FTP
The drupal8's file system is
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
Mint 19 / Lampp 7.3.8 / Drupal 8 still asks for FTP
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.
Module installation requires FTP access? (Perfect Solution)
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.
Best regards,
Omprakash Mankar
Senior Drupal Developer
An Alternative
You can the following to your settings.php:
$conf['allow_authorize_operations'] = FALSE;
https://www.drupal.org/project/issues/1377512
Module installation requires FTP access?
You can follow this link :
https://stackoverflow.com/questions/4632779/drupal-7-is-unable-to-instal...
Try to give permission to sites/default folder
This command works for Ubuntu.
sudo chown www-data sites/default -R
Centos 7
For centos 7 in apache, you should use
Bruno Mateus
first thanks i just ran into
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.