Whenever I try to update Drupal modules, I /always/ get the error messages shown below. I've tried updating modules together, individually, with certain ones disabled, all to no avail. I've got the proper FTP information set, and I'm not quite sure what I've done wrong.

Update failed! See the log below for more information. Your site is still in maintenance mode.

token

Error installing / updating
File Transfer failed, reason: Cannot remove directory /homepages/24/d451754577/htdocs/profiles/openenterprise/modules/token/..

filefield_sources

Error installing / updating
File Transfer failed, reason: Cannot remove directory /homepages/24/d451754577/htdocs/profiles/openenterprise/modules/filefield_sources/..

ctools

Error installing / updating
File Transfer failed, reason: Cannot remove directory /homepages/24/d451754577/htdocs/profiles/openenterprise/modules/ctools/..

Comments

VM’s picture

updating modules and upgrading drupal core are two different animals. Consider moving the opening post to the post installation forum.

What are the server level permissions on the following folders:

/sites/
/all/
/modules/

Magicmann-1’s picture

The access level for the three folders is 775.

VM’s picture

I meant to add /profiles/ as that is the folder where it the update can't delete the old folder.

Magicmann-1’s picture

That folder also has it's permissions set at 775.

VM’s picture

profiles/openenterprise/modules/ctools/

^ every folder in that chain should be checked, and perhaps 777 tested. I'd also check the openenterprise issue queue for similar reports with regard to using the core update system with installation profiles.

Magicmann-1’s picture

Even with the permission value set to 777, it still fails to update. Haven't checked OpenEnterprise yet.

Edit: Other OpenEnterprise users don't seem to have this problem...

VM’s picture

does it work for any modules not stored in the profiles/folder?

ie modules stored in sites/all/modules

Magicmann-1’s picture

Every module I have attempted to update has failed with the same error being displayed.

VM’s picture

beats me. I'm out of ideas, and I don't see mass reporting of the same issue.

Magicmann-1’s picture

I was afraid of that.

But regardless, I do appreciate your willingness to try and help!

Magicmann-1’s picture

Error still persist without me having found a fix. shamefulbump.

madratrace’s picture

Same here, with xampp test installation. What i did:
Xampp is at c:/xampp
Moved the site to various locations (desktop, documents etc)
Changed current user settings (777 equivalent in windows)
Add "Everyone" user to "sites" folder again with 777 access
Tried to do the same with a second live site (copied it locally, set it up and see if it's working then attempted to update some modules)
Started trying some crazy stuff like starting xampp and firefox as admin and such.

Still getting "update failed" no matter what module i'm trying to update -it's driving me crazy.

Let's hope someone has another idea.

ps @ magicman : Have you by any chance changed your account name before this problem, because that's what I did a few days ago (did the proper procedure). Maybe that's causing this but I can't rule it out or confirm it.

niccottrell’s picture

I'm suddenly having the same problem. I've always updated via the web interface and only now had this problem. Permissions on the /sites/all/modules folder look fine. I upgraded to 7.19 recently and suspect that may have been when the problems started...

madratrace’s picture

I upgraded to 7.19 recently and suspect that may have been when the problems started...

My fresh test site was 7.19 . The second live site I downloaded is 7.17 . Both produce the same error the OP mentioned.

Also the downloaded site (7.17) was originally developed in acquia locally then uploaded (It's been more than a year) while the fresh one is plain drupal.

So I don't think there's any correlation between version or installation profiles, at least in my case.

Also, is this a live or local site? In case of live could you download any site you have problem with and test with a local stack?

Seems this problem will be solved with pure trial and error :/

rosewoodmarketing’s picture

I don't know why, but I'm also suddenly having this issue as of the last couple weeks...I updated my version of PHP on my webserver and figured that could be the issue but maybe that isn't the problem...

rosewoodmarketing’s picture

...it does seem like it has something to do with permissions, I guess.

One thing I started doing recently is maintaining a folder on my desktop with all the modules I normally use. Rather than downloading them every time I just upload the whole sites/all/modules folder and I get them all. It seems like my grief must be coming from file permissions created somewhere in that upload. Some of my newer sites I've been uploading with Coda rather than using the cPanel File Manager or Filezilla. Not sure where the weak link is.

I just deleted some of the sites/all/modules folders I was having issues with, downloaded from Drupal the older versions of the modules again, uploaded them to sites/all/modules, then re-ran the admin/modules/update script on those modules.

Now everything works. No errors.

mimor’s picture

We encountered the problem several times now.
Only occurs on PHP5.4

el1_1el’s picture

In my instance, I had accidentally upgraded to php 5.4 using remi.repo and got this same problem. Went back to 5.3 with webtatic.repo and the problem went away

madratrace’s picture

Thanks a lot to both mimor and el, tested it with wamp that uses 5.3 and works with no problems.

Jorge Campo’s picture

Yes, same issue and solution!
Downgraded my php 5.4 to 5.3 and now I can upload the new module versions.
Thanks @el

millionleaves’s picture

I can confirm that I have this issue in these configurations (iterations of the same Drupal/PHP instance):

PHP 5.4.10 and Drupal 7.18
PHP 5.4.10 and Drupal 7.19
PHP 5.4.10 and Drupal 7.21
PHP 5.4.13 and Drupal 7.21

[edit]
I then applied the patch in #10 as described in this issue and the problem was resolved: http://drupal.org/node/1915088

If you're not familiar with patching files, fear not (I used to stop reading issue threads the moment I realised I'd have to patch something) - it's pretty straightforward (on Linux - not familiar with the process on Windows):

  • Log in to the server using the command line.
  • At a command line on the server, navigate to the location of the file to be patched. In this case it is:
  • [drupalroot]/includes/filetransfer, and the file to be patched is filetransfer.inc.

  • Download the patch file by typing (replace [file_URL] with the full URL path to the patch file)
  • wget [file url]

  • Type the following command (replace [patchfile_name] with the full name of the patch file you just downloaded)
  • patch filetransfer.inc < [patchfile_name}

That should do the trick.

I provide Drupal, Drupal Commerce and CiviCRM development services for customers in New Zealand and beyond

presslock’s picture

This sounds like what I need, but I am in a cpanel environment and have no access to these tools (wget, patch, or even command line). Any suggestions on a solution for this arrangement?

Thanks,

VM’s picture

install a local environment and patch on your own machine.

mjcarter’s picture

The patch is simple enough you could add the new lines of code to the file manually

VM’s picture

based on the issue thread and the release of 7.22 there is no need to perform a patch. Update core to the latest release which includes all fixes between 7.21 and 7.22.

Rodney N’s picture

Upgrading from 7.21 to 7.22 fixed the problem for me too. Thanks.

Also worth noting that after the upgrade one of my sites had trouble retrieving update information from the drupal.org website. Emptying the cache_update table using PhpMyAdmin solved that problem.

All is well.

dunwich42’s picture

Thanks very much, that fixed this issue for me.

YodaRocks’s picture

I too was vexed by this issue, but after reading this thread, simply downgraded from PHP 5.4.x to 5.3.x. Doing so solved this for me too.

Krizalys’s picture

This issue is caused by a bug in Drupal 7' SkipDotsRecursiveDirectoryIterator class, which is currently inhibited by a PHP 5.3 bug. PHP 5.4 is not affected by this bug, but this also means that using it will not inhibit the Drupal bug and cause the issue described here.

Note that the PHP bug is scheduled to be fixed as of PHP 5.3.23, so Drupal should be fixed accordingly or users will experience the same issue with latest PHP 5.3 versions. A patch has been proposed for Drupal 7 here: http://drupal.org/node/1915088. I tested it succesfully on PHP 5.4.11, and it should also work on PHP 5.2 and 5.3, although I did not test it.

sparlez’s picture

This fixed the problem for me. Thank you very much.
Drupal 7.20
PHP 5.4

Tech-2’s picture

This patch also worked for me on Drupal 7.21 , as I experienced the same problem after upgrading to php 5.4.12 from whatever's running on Ubuntu 10.04. I hope they put it into Drupal's next release.

michellepace’s picture

Views did an update a few days ago (20th March) and I had the same problem when trying to do an update via the frontend. I attempted the update via the drush command "drush pm-update" and it worked. Drupal 7.21, MAMP 2.1.2, DRUSH 5.8

michellepace’s picture

Views did an update a few days ago (20th March) and I had the same problem when trying to do an update via the frontend. I attempted the update via the drush command "drush pm-update" and it worked. Drupal 7.21, MAMP 2.1.2, DRUSH 5.8

dueron’s picture

I am having the same problem, but 1and1 Hosting only allows choices PHP 5.4 OR 5.2 (See my other post).

dueron’s picture

I have been having the same problem for weeks (While at the same time increasing my 1and1 hosting account from "Ultimate" to "Business" level).
1and1 Hosting only offers 2 choices for Global PHP version: 5.2 and 5.4 I am trying to add "Course" modules to my site, which REQUIRE 5.4
I also hope this is resolved in Core update: 7.22!

VM’s picture

it won't be fixed in the next version of drupal unless those having the issue test the patch at http://drupal.org/node/1915088 (mentioned in this thread) and report back whether the fix works or not!

phenpdrupal’s picture

Problem solved with patch http://drupal.org/node/1915088, which I have now applied to 4 sites.
Thank you!

stilblütler’s picture

Problem solved with patch applied to filetransfer.inc as provided at comment #10 http://drupal.org/node/1915088#comment-7139886

Drupal 7.21
PHP 5.3.23
www.cyon.ch Single Webhosting

But: Don’t forget to empty all caches and run cron!
Patched filetransfer.inc, cleared all caches -- and update worked once for me (for only one module). Afterwards got
"Fatal error: Class 'FileTransfer' not found in /home/example/public_html/drupal-7.21/includes/filetransfer/local.inc on line 6"
for every other module I tried to update.
After also running cron, everything worked fine …

Thank you very much!

mjcarter’s picture

Works great

dadderley’s picture

I had this problem with Drupal 7.19 running on PHP 5.3.24
I updated Drupal to 7.22. The problem went away.

hockey2112’s picture

Same here. Upgrading from 7.19 to 7.22 fixed my issue.

mburnette’s picture

I was having the same issue and the solution is the same for me.

Upgrading to 7.22 did the trick!

Greenman77’s picture

Legend, thanks so much guys. Upgrading 7.22 worked a treat.

We migrated a site from a development machine running 5.3 to a newer 5.4 instance without knowing there was a difference between the two boxes. Started getting errors downloading updates on 7.19. I also had some extra errors upgrading core to 7.21 the error messages didn't get me far and wasted the last couple of days. "Strict warning: Only variables should be passed by reference in include()"

Started with a fresh install of 7.19 on the new box. Used backup and migrate to bring across the data. Then started getting the errors MagicMan mentioned. Upgraded to 7.22 and cleared the cache and now everything is updating and working perfectly.

Again thanks so much for your contribs made my day.

intile’s picture

sudo chmod 777 -R /path/to/file/