I would really like to be able to install module updates through the web interface or run update.php when needed without changing settings.php, but something seems to be broken in my setup because it tells me I am not authorized to do so when I try.

In all attempts to make this work, I am using UID1, which besides any special properties that user has, it is an administrator which has the "Administer software updates" permission. In settings.php I have: $settings['allow_authorize_operations'] = TRUE; set explicitly, but I have also tried it in the default, not set, state which is also TRUE.

If I set $settings['update_free_access'] = TRUE; then I can run update.php, but that doesn't seem to help with the module updates and I would rather not have to change that setting every time I need to do an update.

I have tried all of the usual things I have seen mentioned including:

  • Rebuild the user permissions
  • Cleared the session table in the db
  • Verified correct permissions on relevant files/directories
  • Looked through various server logs for any obvious failures

My first real clue came from looking at the log an noticing that the "access denied" entry is tied to the anonymous user instead of the user I was logged in as. I have tried digging through the code a bit to see if I could track down where it is losing track of my user, but I am in a little over my head at that point. Obviously, the authentication is working in general because I am able to log in the admin site and do most things.

Has anyone had any idea why Drupal would lose knowledge of the logged in user just while trying to do update type operations?

Version: Drupal 8.7.6

Note: I have looked a little more into the code to try to track down my problem. As seen from the logs, the problem is not that my user doesn't have permission but rather that when I run those specific actions, drupal momentarily doesn't see me as being logged in. In the file core\authorize.php there is a method that gets called: authorize_access_allowed(Request) which is mostly checking to see if the logged in user has the 'administer software updates' permission. In that method, it doesn't believe I am logged in. As far as I can tell, there are two ways it might pull the user out of that passed in Request (reading PHP_AUTH_USER out of the get headers or getting the UID out of a cookie). The get headers are definitely not there, and while there is a session cookie, it doesn't seem to be able to pull a UID out of it. I have not been able to find the code that parses the Session string.

1 Answer 1


update.php does not update modules. It updates the database state if needed (after installing module updates, aka db-update).

Did you check the permissions of your /modules/contrib/* filesystem? When you update your modules with the admin UI, your webserver's user (apache or www-run...) needs to have write permission there.

Did you install your instance with composer? If so, do not use the admin UI.

Maybe, check the docs again: https://www.drupal.org/docs/user_guide/en/security-update-module.html

  • I realize now my wording wasn't particularly clear, but I am aware that update.php is not related to modules. Those are two separate actions that appear to be broken for me in the same way. Whatever my problem is, I don't think it is associated with file permissions. I have gone through all of the recommended permissions and confirmed they are correct. This site was not installed using Composer. Without the web interface, I am not sure how to update modules. I can replace the files on the server, but presumably something needs to run within Drupal to actually install the updated module.
    – JGoforth
    Aug 27, 2019 at 4:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.