Last updated September 28, 2015. Created on September 26, 2007.
Edited by ashish_nirmohi, kenisha.lehari, ehowland, mlhess. Log in to edit this page.

The Update manager (Drupal 7) and Update status (Drupal 6) modules periodically check for new versions of your site's software (including contributed modules and themes), and alert you to available updates.

The log of available updates will indicate when new releases are ready for download, and you may configure various options, including frequency of update checking and notification options (which are performed during cron runs), at the respective module settings page if you have administration permissions.

Please note that in order to provide this information, anonymous usage statistics (consisting of a unique key and a list of versions of the software your site is running) are sent to If desired, you may disable the Update status module from the module administration page.

If you have checked out Drupal code via Git instead of installing a release tar.gz archive you downloaded from, you will need to install and enable the Git Deploy module.

Update manager (Drupal 7)

Performing updates through the user interface

The Update manager also allows users with the administer software updates permission to perform updates directly through the administration interface. At the top of the modules and themes pages you will see a link to update to new releases. This will direct you to the update page where you see a listing of all the missing updates and confirm which ones you want to upgrade. From there, you are prompted for your FTP/SSH password, which then transfers the files into your Drupal installation, overwriting your old files.

Installing new modules and themes through the user interface

You can also install new modules and themes in the same fashion, through the install page, or by clicking the Install new module/theme link at the top of the modules and themes pages. In this case, you are prompted to provide either the URL to the download, or to upload a packaged release file from your local computer. Click Install, and the files are copied into your sites/all/modules folder. See Installing contributed modules for more details.

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 (or at least sites/default) is set to the same user that runs the web server. This is often apache or www-data. An example of a command to accomplish this would be...

sudo chown -R www-data:www-data /var/www/drupal
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.

Disabling user interface code updates

If your site is relying on an external deployment system (perhaps with a staging and production workflow), you can disable all of the functionality that allows site administrators to install code through the administrative user interface by placing the following line in your site's settings.php file:

$conf['allow_authorize_operations'] = FALSE;

You will still be able to run the Update manager to check the status of available updates, but you will not be able to install those updates or new modules and themes directly via the web interface.

Update status (Drupal 6)

Additional functionality is provided by the Update status advanced settings module.

Note: In Drupal 5, this functionality is provided outside of Drupal core by the contributed Update status module.

Technical details for Drupal 7

Core module: Yes.
Dependencies: None.
Related Modules: None.
Permissions: None.
API Documentation: update.api.php,,,, update.install,, update.module,,, update_test.module,
Template files: None
Other files: update.css,, update-rtl.css
Database tables (1):
cache_update. Also see the API docs at update schema.

Looking for support? Visit the forums, or join #drupal-support in IRC.


David D’s picture

I've been attempting to use the Update Manager in the last couple D7 versions. I'm now using RC1. I've never been prompted for a password. I've been experiencing some problems and very mixed success with the Update Manager, but this is probably not the place to mention those issues. But this documentation about the password seems incorrect.

dobry’s picture

Seems that D7 Update Manager require VALID LOCAL USER - on YOUR WEB server
In other words you should use VALID User/Password when Update Manager ask you.
I try installing new module "Variable" using upload from my PC, via SSH (drop-down box) - NOT Ftp. And it Says That module was installed - BUT IT IS NOT Available under installed modules.
Not sure what happens !

I try with user that have NO root privileges.

btw. to have SSH as option in drop-down box, you need libssh2 for PHP installed.


I just try it again - using user with Root privileges. And installation was Successful.

David D’s picture

I posted here initially because this documentation seems wrong to me. I've never been prompted for a password by the Update Manager in D7. The update manager has been working fine for me for the last 10 or 11 months, and I really appreciated it, by why does this documentation page talk about passwords in the Performing updates through the user interface paragraph?

TheLioness22’s picture

I have been experiencing the same problem. I have searched for documentation on the Update Manager and everything I find says that D7 will prompt me for an FTP or SSH login in the in-site module update process. It never has. I select a module to update, it says it is downloading it, then it says it is ready to install, I tell it to use maintenance mode, it fails. Same thing, every time. Never has it prompted me for a password, and I don't know why. I've resigned myself to having to update the modules manually or using drush. If anyone knows the fix for this, please let us know. I've searched around and this is the first place I have found someone with the same issue.

oemb29’s picture

Same Problem TheLioness22 and David D. Any solution?

fuzzy76’s picture

Just be aware that if your site uses suphp, you need to change the umask in suphp.conf from 077 (the default) to 022. If not, Apache won't be able to serve your static files (they need to be readable by www-data, since suphp don't serve them).

Håvard Pedersen
Web developer at Norwegian Centre for Integrated Care and Telemedicine, working with eLearning for the health sector.

s0me0ne’s picture

How do I update from Drupal 7.2 to 7.4?

kingfisher64’s picture

1) Download the new version (7.4 in this case) from here
2) Extract it's content
3) Copy and paste the newly extracted 7.4 folder to wherever your 7.2 folder currently is.
4) Delete the sites folder from your NEW 7.4 version NOT from your current 7.2 version (as your going to copy all your existing content from your current 7.2 version in here)
5) Copy the sites folder from your 7.2 version into the 7.4 version folder
6) Delete 7.2 folder completely - you will have this named after the website your working on. (again just make sure you've copied out your sites folder)
7) Rename the 7.4 folder to whatever you previously had named for your website
8) Add /update.php when you first login to your new 7.4 site just to check to see if any module updates are available.
That's it.

All changes made to drupal are outside the sites folder. This sites folder is effectively your old 7.2 site from a perspective of content to keep.

Hope this helps


tarbour’s picture

Copy back and forth?? Makes no sense

tarbour’s picture

OK - I must be STUPID as I can't get even a minor update to work without crashing my sites. According to the directions, I put my in maintenance mode, then copy off the SITES directory. Next, I delete all of the files EXCEPT the SITES directory and upload the new stuff (except for the SITES directory). Next, I try to run the UPDATE.PHP - and yes, I have a site that no longer works!!!

If someone could break this down a little better, I would be happy. What is the definition of CORE DRUPAL Files?? EXACTLY what files are considered CORE?

Lars Bo Jensen’s picture

I followed Kingfisher64's instructions updating from 7.2 to 7.7 and have no problems. Put shortly: unpack or upload a complete new Drupal installation next to the existing one, then replace the new installation's sites folder with the old sites folder, then delete the old folder (I just renamed it, so that I might have used it for backup. Will delete after further testing) and rename the new folder from e.g. 'Drupal-7.7' to the folder name of your old, now renamed or deleted drupal site folder.

Carnix’s picture

When you download a fresh copy of Drupal -- everything you that ISN'T inside the /sites folder is considers core. If you are changing anything other than what's in the /sites folder (and sub-folders) you are hacking core and therefore in for it when you need to update.

Carnix’s picture

What FTP login? The one I use to log into the FTP server on which Drupal is running? I don't get it... why would I need to provide that if it's already downloaded the update file locally to the server?

Doesn't work anyway.

I've tried, localhost, the hostname of the machine... nothing.

ulysse68’s picture

Hi there,

I updated my modules in D7, and everything is ok for most of them. But two of them are saying that un update is available, even if the date corresponds to the last available version.

Have you seen that before?

I tried to do it again, delete the modules, run update.php, and reupload the latest version, but nothing changes for those modules (i18n and variable).

Thanks for your ideas!

kpm’s picture

I am experiencing the same issue as ulysse68, but on Drupal 6. I have three modules that are not registering as being updated even after I have updated them. These are Comment notify (status currently reporting it as 6.x-1.5 and recommending 6.x.1.6), Quick Tabs (reporting 6.x.2.0-rc5 and recommending 6.x.2.0), and the Fusion theme (reporting 6.x-1.1, recommending 6.x-1.12). I have, ftp'd and extracted all of these modules (as I usually do on crappy hosts that I can't run Drush on...), run cron, update status check, and it always reports these modules as not updating. I noticed this the other day with just the two modules, and now there are three, so I'm pretty sure it isn't the fault of the modules. Another point, the host, netfirms, recently made some hosting upgrades and changes, and now 'register_globals' is enabled (I have requested that it be disabled...) and the cron has stopped running on the hour and I need to manually kick it off... so there is certainly some issues with this shared hosting... but I didn't think any of that would impact the core update status module...

ulysse68’s picture

I found an (ugly) workaround: I set the 'datestamp' manually to a recent date (copied from another module)... and it now appears in green ;)

For the record, the updated files are [module_name].info, in each module folder.


barbarae’s picture

Anyone still having this problem - check your modules folder for extracted files relative to the modules that won't update. If you extracted the files under the parent '.../all/modules' folder directly (by mistake, manually) first, drupal looks from the bottom up for existing files. So it finds the old ones, even if the right ones have been applied in their correct folder under the "..../all/modules/module-available-for-update'' folder.

Makes sense once you realize what happened.

spade’s picture

I get the error:

* Error installing / updating
* File Transfer failed, reason: Cannot create directory /is/htdocs/wp1174125_Y2HN1MV9U4/frankspade/drupal7/sites/all/themes

even though I changed the temp file location to "temp".

Where does the update-manager get the temp folder location from?

Ali.T’s picture

Hello, I am user 1 on a D7 site I'm building for a client. I get the emails sent by Update Manager about security and module updates available. The client has admin role and naturally see the security / update notices when they appear on top of pages.

Is there a way the admins from seeing these notices so he/she doesn't panic ?

Disabling permissions for "administer software updates" and "view site reports" didn't do the job. Admin still sees "There is security update available for you version of Drupal .... "

David D’s picture

I can't test this myself as the D7 site I'm working on is up to date, but you might see if setting Error messages to display to None at admin/config/development/logging does the trick (if you aren't set up that way already).

Lars Bo Jensen’s picture

Or you might consider creating a custom role other than admin for the client?

drbeaker’s picture

I tried installing Drupal 7 using symbolic links to keep the custom stuff out of the version specific Drupal tree with the intent of making core updates easier.

The directory structure I have is

/var/www/drupal - all Drupal stuff is in here
/var/drupal-7.x/...  - Drupal core
/var/www/drupal/SITES - all local content normally in drupal-7.x/sites
/var/www/drupal/MODULES - all local content normally in drupal-7.x/sites/all/modules
/var/www/drupal/THEMES - all local content normally in drupal-7.x/sites/all/themes

the relevant directories are then replaced by symlinks (so drupal-7.x/sites -> /var/www/drupal/SITES).

I also have a symlink /var/www/drupal/current -> /var/www/drupal/drupal 7.x, so my Apache conf has that as Document Root

This seems to work (almost) perfectly and it makes installing a new version of core very simple - I only need to install the new version, change two symbolic links & run the update script.

However, the only thing it seems to break is the update manager. Updates done through the Drupal Update Manager give errors such as

Error installing / updating
File Transfer failed, reason: /var/www/drupal/MODULES/imce_mkdir/LICENSE.txt is outside of the /var/www/drupal/drupal-7.8

Is there anything I can do to make Update Manager work using my configuration?
Is there any reason I'm not aware of as to why my configuration is a Bad Idea?
Is this something that could/should be added as a feature request?

[If it's any help the errors are generated by authorize.php. I did take a look at the code, but it's way beyond my knowledge of php.]

mfeldmann’s picture

I'm using drupal 7 with a multi-site setup and set up update manager to send a notification, when new updates are available.

But unfortunately I do not get any e-mail. Is there a special trigger necessary?

flightrisk’s picture

With the way Drupal operates in the real world, with modules that are never in "release" versions, it is pretty useless to have a module that does one button updates to the latest module versions when in 95% of the cases, the modules you need are the dev versions. Is there a way to select the version you want? Can you hard code somewhere a new path to find the dev versions? Can we add this as a configuration option? I've been using Drupal for 7 months now and update modules every other day, very frustrating.

DrMiaow’s picture

This would be a very handy feature.

David D’s picture

That would be very handy indeed, especially when there are as many semi-core modules affected by this, like Views, Date, Calendar, etc.

DrMiaow’s picture

I propose adding a new attribute to the update schema 'version_stream'

This could have values of 'dev', 'alpha','beta', 'test', release' etc.

If you have a given stream installed, by default you stay on that stream unless you choose to switch to another stream.

Also, adding something like 'version_build' as well would allow a formalisation of the current defacto versions I seem to see are common place.


api_version + '-' + version_major + '.' + version_patch + '-' + version_stream + version_build

jzornig’s picture

It would be really useful if you could choose to upgrade any module, including those already at the latest release version, and then get a form like the admin/modules/install form, where you could input a url or upload a module release. This would allow for flexible installation of dev releases, module development and debugging.

flightrisk’s picture

I would think this would be one of the most important features to add to this function. I am still struggling with trying to find out what version is what. I either have to look in the uprade page or in some cases look in the modules folder and find what dates are on the files. Part of the problem is that a release is numbered rev 4.1, 4.2 etc. But a dev release in most cases keeps the same name no matter how many releases it goes through. I personally believe that the standard naming structure is incorrect also. Dev releases should not be 7.x-1.x-dev. This is a very poor and confusing naming scheme. There MUST be a build number at the end at the very least. But frankly the "x" needs to go away too. What is wrong with 7.0-1.99-dev or 7.1-1.1-dev-99?

valdir.marcos’s picture

I wil sum up what I reported on

I am using Drupal 7.10 on two environments: (1) Debian Linux test server using root for everything and (2) hosted sites on third-party companies all using Linux limited users.
Drupal 7 update manager works correctly on situation 1.
On situation 2, I got the message below:
•Error installing / updating
•File Transfer failed, reason: Unable to change to directory /sites/all/modules/pathauto.

Are limited users provided by host companies a problem to this update method?
MySQL user and Hosting/SSH/FTP user are different names/passwords. Does it matter?
www/sites/all/modules/ is drwxr-xr-x. Should it be 777?

Is it possible these scripts provide username, password, source path, source file, source path permission, source file permission, destiny path, destiny file, destiny path permission, destiny file permission, error on reading or writing and any more information to help developers to identify and solve the problem when we report here?

If any one can provide this hack, I can test on the sites where I have the problem always happening.

Since 01/07/2010, it is more than 18 months. I insist on this feature because Drupal 7 release has a focus on user experience, accesibility and usability of the system to make it easier to use.
I volunteer myself to make tests on some environments where the problem happens to provide debug info or hints.
Can you provide hacks or scripts to make those tests?
Maybe, it would also be good if the patch inform os (operacional system: Linux, Windows, MacOS, etc), total ram, free ram, free space on disk, etc.
VeryCool78, I tried both users www-data and apache, but the hosting service uses a different username and does not inform which is... they said I have to work with my own regular user since it works perfectly on any ssh and ftp program (it really works!). They also said this a Drupal's update tool problem that does not happen on Wordpress update tool.
Staratel, thanks for your help. I will check the modules you informed.

But I still believe that Update Module itself should provide more information to help administrators that are not php developers and cannot debug the sources to solve the problem or at least help those administrators to fill up bugreports with all needed information to identify and fix the problem.

I believe that important part of the problem is that I do not have control over apache, ftp, etc servers because my site is hosted on a third party hosting company.

What information could I provide to help solving this out?

David D’s picture

@valdir.marcos, you are not alone in this thread in doing this, but you are talking about a bug with the code, so you should really be posting this as a core issue here:
You should review the existing issues there to determine whether your issue has already been posted about, before creating a new issue.

I was the first to post a comment here, but I was raising an issue about Drupal documentation right here on this page, not a bug or some other issue with Drupal code. If you post in the Drupal core issue queue, there is a much better chance that core developers (who may be able to respond in a meaningful way) will actually see your post. This page is documentation only.

valdir.marcos’s picture

Thanks, David D.
After search, I have created a bugreport:

robcornerstone’s picture

Not all server environments support FTP due to security issues with anonymous users, or sending passwords in the clear for registered accounts. So in order to bypass the FTP login for Update Manager, apache must own the default folder (but nothing more!).

chown apache sites/default/

Note: the settings.php file inside the default folder contains the database connection string in clear text. This needs to be locked down:

chown rob:nobody sites/default/settings.php
chmod 640 sites/default/settings.php

This way, I can still edit the file, apache's group can read it, and "other" is denied.

By the way, one way to determine the user and group apache is running under is to go to the appropriate apache conf file and look for this syntax:

User apache
Group nobody

And as you mentioned earlier, apache needs to be able to write to the themes and modules folders:

chown -R rob:nobody sites/all/themes/ && chmod -R 770 $_
chown -R rob:nobody sites/all/modules/ && chmod -R 770 $_

I've been banging my head against the wall for the past few days, and this is the best workaround I could come up with. If this violates any best practices, please let me know.

davidcomeyne’s picture

When inserting hook_install code in my install profile I can see in my database that the property is well set (in {system} database the 'status' field is being set to '0').

 * Implements hook_install().
 * Perform actions to set up the site for this profile.
function base_profile_install()
//disable update manager

Unfortunately this is reset somewhere so I can't seem to disable this module. Probably for good reasons, but in my case I want this disabled. Anything I'm doing wrong (or real stupid)?

Thanks in advance for the replies.

akayani’s picture

The specified file temporary://fileJobHBR could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log. could not be saved to temporary://update-cache-8f010407/rate-7.x-1.6.tar.gz.
    Downloading updates failed:
        Failed to download rate from

That's the message... it started to appear after I changed the User on the server for this domain. Any clues?

hdlverde’s picture


I have D7.21 on Centos 6.3 and Apache 2.2.15 and PHP 5.3.3
Installed Drupal Commons installation profile.

This webserver is behind a network proxy used to connect to the web.

I read on many sites about D7 now being able to handle http requests through proxy, and i setup my settings.php file according.
But I cannot get updates..

It keeps failing.. need some pointers. Do I need to setup Apache to be able to handle these requests from its own sites?
Any help would be great!

Found the error!! It always bugs me that other get their error solved, but never post what solved it, so here's the solution to my problem:

The clean URL's was not working properly. Had to set the mod_rewrite corretly as shown in this post. Even if my clean URL's was set in Config->Search- Metadata->Clean URL's i set it again..

After this the HTTP request from the update manager worked!

Hope this might help anyone out there..

Daniel Leonard’s picture

Hi all,

I'm pretty new to Drupal, so excuse any naivety.

I am getting the same issue as many are posting here. I do have my FTP log in information, however at no point in the update process am I being prompted for it. The update just begins and fails.

moodth’s picture

I also new user in drupal and and my update get fails

amm’s picture

I have been unable to 'update script' lately and I don't know how to change that! Anyone??? I recently added an "Add-on Domain" and things were going just fine at first ... did I inadvertently change something? Perhaps it's that the "Add-on" is using 7.24 and my regular site is using 7.22? I really need help! Thanks!
I cannot install new modules the regular way either. When I select 'install' nothing happens on either site.

Kebz’s picture


My status report is telling me that there are important "module" updates available. For example, when I get there, it is recommending that I update to this version > 7.x-1.12 --- However, when I review ... that version has not been updated ... it is the "Dev" version that has been updated, which is what I have installed.... but it's not providing that release in the "update" section.

How come it is doing that? The "update" program knows that I have the Dev version, but it won't give me the latest Dev version to update with.

So now I have to manually update =\ .... is there an automatic way of doing this? I'm baffled why this has not been incorporated yet. I can now see why I have some compatibility issues and why some modules don't work as I have read them to be.

Can this be on some priority list??

Thanks in advance =)


Kebz’s picture

... BTW ... for those inquiring about the "FTP/SSH password" ... in my experience, that is only required on "safe" installs. For example, if a user uses their hosting company to install the Drupal app for them, it gives two options.... 1) Safe ... 2) Free mode .... (see below)

Safe Mode:
Maximum comfort and safety
Only default plugins are possible
Hosting company manages all the apps ... including safety patches and updates through to your installs automatically.

Free Mode:
Maximum flexibility
Write plugins yourself and change code at any time
Updates and security patches are not done automatically ... only informed by the hosting company and we do it manually.

Hope this info helps =)


Kebz’s picture

I'm not sure where to post this. I received the typical "there's updates" available, so I clicked on the tab, and then decide that I'll update the module later. So I then click on the "list" tab, and then pops up with these two notices. But the odd thing is that I'm not using neither of these themes. As a matter of fact, I deleted both of them. Any thoughts on this?

Notice: Undefined index: zen in theme_update_report() (line 202 of /homepages/30/d513154960/htdocs/OVLVX_com/BLove/modules/update/

theme('update_report', Array)
call_user_func_array('module_filter_update_status', Array)
menu_execute_active_handler() index.php:21

Notice: Undefined index: adaptivetheme in theme_update_report() (line 202 of /homepages/30/d513154960/htdocs/OVLVX_com/BLove/modules/update/

theme('update_report', Array)
call_user_func_array('module_filter_update_status', Array)
menu_execute_active_handler() index.php:21