Posted by korayal on April 22, 2008 at 9:35pm
| Project: | Drush |
| Version: | All-Versions-3.0-rc1 |
| Component: | PM (dl, en, up ...) |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
[ohare@hebele www]# drush -v pm install countdowntimer
Calling chdir(/home/hecatomb/public_html/sites/all/modules/)
Downloading project countdowntimer ...
Executing: wget http://ftp.drupal.org/files/projects/countdowntimer-6.x-2.17.tar.gz
E: Unable to download countdowntimer-6.x-2.17.tar.gz to /home/hecatomb/public_html/sites/all/modules/ from http://ftp.drupal.org/files/projects/countdowntimer-6.x-2.17.tar.gz
Calling chdir(/home/hecatomb/public_html)i don't know why wget is not working, i can execute wget command manually.
Comments
#1
maybe a DNS or network problem. Anyway, we can't debug this from here.
#2
I just had the same problem and solved it with option -v to show the complete output of wget.
That showed me that there was a file permission problem of the current user.
Maybe that helps you.
So no error, but it would have been helpful, if it has been written directly.
Maybe drush could show all output by default, when an error occured.
#3
I think my problem might be related to this. wget and curl seem to run as a different user than the caller. If I run drush as the non-root user that owns the drupal modules folder, I get a permission denied from both wget and curl. If I sudo it, the updates run successfully, however the new modules end up with non-existent owner and group ids (1080:1080 in my case)... Is there a way to control what user wget/curl are executed with, or am I misunderstanding the problem here?
Here's my output from the non-root fail case:
Starting to update Embedded Media Field code ... [notice]
Calling mkdir(/var/drupal/backup, 511)
Calling mkdir(/var/drupal/backup/modules, 511)
Calling mkdir(/var/drupal/backup/modules/20091102205706, 511)
Calling rename(/var/drupal/sites/all/modules/emfield, /var/drupal/backup/modules/20091102205706/emfield)
Downloading project emfield ... [notice]
Executing: wget http://ftp.drupal.org/files/projects/emfield-6.x-1.15.tar.gz [notice]
--2009-11-02 20:57:06-- http://ftp.drupal.org/files/projects/emfield-6.x-1.15.tar.gz
Resolving ftp.drupal.org... 64.50.236.52
Connecting to ftp.drupal.org|64.50.236.52|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 252853 (247K) [application/x-gzip]
emfield-6.x-1.15.tar.gz: Permission denied
Cannot write to `emfield-6.x-1.15.tar.gz' (Permission denied).
Executing: curl -O http://ftp.drupal.org/files/projects/emfield-6.x-1.15.tar.gz [notice]
Warning: Failed to create the file emfield-6.x-1.15.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
1 246k 1 2662 0 0 162k 0 0:00:01 --:--:-- 0:00:01 162k
curl: (23) Failed writing body (0 != 2662)
Unable to download emfield-6.x-1.15.tar.gz to /var/drupal/sites/all/modules/ from http://ftp.drupal.org/files/projects/emfield-6.x-1.15.tar.gz [error]
Updating project emfield failed. Restoring previously installed version. [error]
Calling rename(/var/drupal/backup/modules/20091102205706/emfield, /var/drupal/sites/all/modules/emfield)
Backups were saved into the directory /var/drupal/backup/modules/20091102205706. [ok]
Cache cleared.
An error occurred at function : drush_core_cache_clear [error]
An error occurred at function : drush_pm_updatecode [error]
Command dispatch complete [notice]
#4
I added a call to
drush_shell_exec("pwd");in the wget.inc file just to see where it was trying to dl the module and it returned my core drupal installation folder (/home/www/drupal-6.14 in my case)On a whim, I used
drush --verbose --root=./modules dl adminrolewhile in my sites/specificsite folder (we're using a bunch of multisites). This uses the modules folder as the base location where drush can download the tgz file, do its magic and then unlink the file.The enable/disable commands need to have --root set to a true drupal core folder, but dl apparently doesn't.
This is probably something that is similar to this posting about multisites and updates.
#5
I saw this behaviour today to too, so I tested by checking
getcwd()anddrush_shell_exec('pwd')at line 28 of commands/pm/package_handler/wget.inc.At this point, Drush is working in the top-level of the Drupal codebase, and will fail if the user running the command doesn't have permission to write there.
A workaround is to set +w permission for that directory, but my suggestion is for Drush to download tarballs into the directory which the module will be installed to (as we will require write permission here anyway), or to a temporary working directory (if that offers any advantage).
#6
I was having the same problem ("Permission denied" on the wget). I took xurizaemon's advice and changed my wget.inc to download the tar.gz to the top-level directory where the module will eventually be installed to ($path variable in wget.inc). I added a "cd $path" to the wget command and changed a few $filename to $fullpath and that seems to solve the problem. I'm new to drupal and drush, so I don't know what sort of side effects this might cause, but it seems to be working for now.
#7
I'm seeing the same behavior in 3.0-rc1 as well. Any chance we can get this fixed before release?
Attached is my log from 3.0-rc1 trying to install the module "multiselect" while within the target modules folder.
#8
Is #7 a vote for #6? Please be more clear, I'm not sure what you're requesting here. If there's no working patch, this should be 'active'. If #6 worked for you, then 'reviewed and tested' would be good.
#9
@edegro - just to clarify your earlier results working around using sudo; when untarring the module tarball as root, you'll get the UID and GID the tarball was made with (typically by the Drupal.org bot packaging the module), even if that UID/GID doesn't exist on your system.
Sudo allows you to blaze past permissions issues, but the real solution is to resolve the underlying permissions issue, or you may find you have different permissions issues instead (like files which are not writeable to any regular user because they're owned by a nonexistent UID).
#10
The patch in #6 is stale. I'm not sure that the cd is any better than the chdir. Unless someone can give a distinct reason why the cd is an improvement, we should pass on this patch.
#11
Sorry, yeah, I meant to set to needs work. I wasn't able to apply the patch.
#12
if someone wants to reopen this, please do so with an explanation. thx.
#13
Is there any resolution to this?
I am running Kbuntu Linux and did an apt-get install drush.... and am trying to use it.... It works great under my Mac OS but doesn't under the latest Lucid version of Kbuntu. Am getting the following errors:
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Function ereg() is deprecated [notice]
Initialized Drupal 6.16 root directory at /var/www/drupal [notice]
Initialized Drupal site default at sites/default [notice]
Including non-version specific file : [notice]
/usr/share/drush/commands/pm/package_handler/wget.inc
Including non-version specific file : [notice]
/usr/share/drush/commands/pm/version_control/svn.inc
Using destination directory /var/www/drupal/sites/all/modules/ [notice]
Downloading project token ... [notice]
Executing: wget http://ftp.drupal.org/files/projects/token-6.x-1.12.tar.gz
--2010-04-16 08:53:02-- http://ftp.drupal.org/files/projects/token-6.x-1.12.tar.gz
Resolving ftp.drupal.org... 64.50.236.52
Connecting to ftp.drupal.org|64.50.236.52|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 47427 (46K) [application/x-gzip]
token-6.x-1.12.tar.gz: Permission denied
Cannot write to `token-6.x-1.12.tar.gz' (Permission denied).
Executing: curl -O http://ftp.drupal.org/files/projects/token-6.x-1.12.tar.gz
sh: curl: not found
Unable to download token-6.x-1.12.tar.gz to [error]
/var/www/drupal/sites/all/modules/ from
http://ftp.drupal.org/files/projects/token-6.x-1.12.tar.gz
An error occurred at function : drush_pm_dl [error]
Command dispatch complete [notice]
This makes DRUSH totally unusable... Any fixes?
Stephen McConnell
#14
"Cannot write to `token-6.x-1.12.tar.gz' (Permission denied)." means that you need to give the account you're calling drush from write permissions to the folder /var/www/drupal/sites/all/modules/.
#15
I run into this problem also on a site where Drupal site root directory /var/www did not have a write access. Modules directory had permission to write. It's no a Drush issue at all, but the error message could be much more clear about what's wrong.
This is what happens, the error messages are rather confusing:
ubuntu@demo:/var/www$ drush -v dl addthis
Initialized Drupal 7.8 root directory at /var/www [notice]
Initialized Drupal site default at sites/default [notice]
Executing: wget --version
Downloading release history from [notice]
http://updates.drupal.org/release-history/addthis/7.x
There is no recommended release for project addthis.
Choose one of the available releases:
[0] : Cancel
[1] : 7.x-4.x-dev - 2011-Oct-17 - Supported, Development
[2] : 7.x-2.x-dev - 2011-Feb-25 - Development
[3] : 7.x-2.1-beta1 - 2010-Oct-21 - Supported
1
Executing: mkdir '/tmp/drush_tmp_1319610237'
Downloading project addthis to /tmp/drush_tmp_1319610237 ... [notice]
Executing: wget -P . 'http://ftp.drupal.org/files/projects/addthis-7.x-4.x-dev.tar.gz'
Executing: curl -O 'http://ftp.drupal.org/files/projects/addthis-7.x-4.x-dev.tar.gz'
Unable to download addthis-7.x-4.x-dev.tar.gz to [error]
/tmp/drush_tmp_1319610237 from
http://ftp.drupal.org/files/projects/addthis-7.x-4.x-dev.tar.gz
Error downloading addthis [notice]
Command dispatch complete [notice]