E: Unable to download ...

maybe a DNS or network problem. Anyway, we can't debug this from here.

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.

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]

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 adminrole while 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.

I saw this behaviour today to too, so I tested by checking getcwd() and drush_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).