Fatal error: Call to undefined function user_access() in /home/xxxxx/public_html/includes/menu.inc on line 449

Hi
I have exactly the same problem.
Does somebody have a solution ?

Function http://api.drupal.org/api/function/user_access/6 is defined in modules/user/user.module (http://api.drupal.org/api/file/modules/user/user.module/6/source). Either this file is missing, or perhaps it was missing and as a result has been disabled in the {system} table in the DB. The value of status should be 1. Same goes for node.module which is where node_load lives, and also block, filter and system modules. Hopefully that will fix the form.inc error too.

Function http://api.drupal.org/api/function/user_access/6 is defined in modules/user/user.module (http://api.drupal.org/api/file/modules/user/user.module/6/source). Either this file is missing, or perhaps it was missing and as a result has been disabled in the {system} table in the DB. The value of status should be 1. Same goes for node.module which is where node_load lives, and also block, filter and system modules. Hopefully that will fix the form.inc error too.

cog.rusty - October 19, 2008 - 02:13
Was that an upgrade from Drupal 6.0?

"undefined function user_access()" means that Drupal
- either didn't find the user.module file at the place where it should be (under /modules/user/)
- or it couldn't read it (because it was damaged, or because its permissions were less than 644, or because the permissions of it directory were less that 755, or for some other reason).

The error message from update.php does not say that some code is wrong, it says that it received a wrong value.

Don't access your site with the updated Drupal files before running update.php. Upload again, make sure that the modules have been placed at the right directories, make sure that Drupal's directories have permissions at least 755, and run update.php again.

Thanks. Rusty Cog, You were rigtht for me. I had to do your fix and gdk said the same thing, being those modules were disabled.

I tried to update to 6.8 and ran into that user access problem.

First:
I had to turn back on the user module, set to 1 from 0. Also the user module somehow had 750 permissions, I changed it to 755.
The system module was disabled for me. I set it to 1 and the site came back alive. Thanks.

For others, load up phpmyadmin, log into your database, scroll down to where it says system. Look for your modules, and the status, 1 is on 0 is off.

I'm posting this on all the pages I found that people had this problem.

I have this problem: http://drupal.org/node/347495
Is the same problem?
system table and files permissions seem ok.

UPDATE:

347495 CLOSED

@stormseeker, @pacifico: Can you confirm your problems were resolved using the provided info ?

- Arie

Looks like stormseeker and pacifico won't be posting any feedback so I'm setting this to fixed.

Feel free to reopen if you think that is wrong.

- Arie

I've had the similar problem after transferring a local site to a hosting server. You should check:
1) Is a database transferred successfully. Check the system table - it should contain data. I had an issue of php timeout while importing a sql file with phpmyadmin - it said that in the case of timeout you should resubmit your sql file; I did that and it worked.
2) Does a theme set in the database as a current theme actually exist on the server (sites/all/themes/)

I've just had this problem.

What had happened was along with a whole series of module updates, I'd used wget to download them into my sites/default/modules directory.

I'd them extracted them to replace the various modules I was updating. This also had the side effect of extracting the new drupal release into sites/default/modules/drupal-6.10. I'd then checked the available updates page and run the update.php script.

Then I moved the contents of the drupal-6.10 directory and replaced the main drupal files with it. This was a mistake, because for some reason the {system} table now had a location of 'sites/default/modules/drupal-6.10/modules/user/user.module', rather than the correct 'modules/user/user.module'. The confusing bit was it all worked fine (apparently) until I moved the update into it's correct location.

The reason the for the "undefined function user_access()" error is because the {system} table is has a incorrect "filename" set for the user.module

To fix it, I used mysql to connect to the database and entered the following:

update system set filename='modules/search/search.module' where filename='sites/default/modules/drupal-6.10/modules/search/search.module';

For each of the rows were "drupal-6.10" existed in the filename field (obviously substituting the correct module name).

Something in drupal causes it to rescan the locations on disk of the modules, and if it finds them in sites/default/modules, it will swap to using that module rather than the original. The real morale of this though, is don't extract a drupal update along side your modules.

I had a similar problem. I'm not sure where people are learning to put their core modules inside of the sites/all directory - quite interesting.

One slightly more general solution to fix this is to use a query like:

update system set filename = replace(filename, 'sites/all/modules/drupal-6.10/', '');

Which will do the update by replacing the string dynamically instead of having to do it for each module.

I fixed it by copying all files again and it seems the ftp copy was not correct. So in case you have this error, check your files and maybe your copy of you database.

Katasun

I have same problem after I wrongly put the code update under site/all/modules ..I follow steps above

in phpmyadmin -> run SQL

step 1)
update system set filename='modules/search/search.module' where filename='sites/default/modules/drupal-6.10/modules/search/search.module';

step2)
update system set filename = replace(filename, 'sites/all/modules/drupal-6.10/', '');

step3)
run the update.php (xxx.yourweb.com/update.php)
and then roll back the core modulus

web fixed

Yep, for some reason the user module was turned off. Turning it back on in the DB fixed this problem for me.

Thank you for this solution.

I have accidentally had an old version of the drupal codebase in my modules directory for the previous 2 installs (must have done the same as you). When I found it and removed it I got the WSOD.

1. I used your solution to update the "filename" column of the {system} table.

2. Also there were incorrect paths in the "file" column of the {menu_router} table, so I followed your example above for this table too.

Now it is working again! Thank you very much.

I actually had a slightly different symptom --Fatal error: Call to undefined function node_load() in xxxxx/includes/menu.inc on line 410--but I was able to trace it back to the removal of some Drupal 6.19 core files in my sites/all/modules folder. No idea how those got there.

My problems seemed similar to the ones in this thread, so I tried the solution in #12. It appears to have worked splendidly. Thanks! Saved me a large headache. I owe someone a beer!

I have this problem on a fresh install
Fatal error: Call to undefined function user_access() in /........../includes/menu.inc on line 449

Same problem here. Started when the admin account was unable to log-in, installed a fresh install of Drupal 6.20 (previously it was 6.13) and restored from backup.
Now the whole site is unstable, Clean URLs are also disabled and couldn't be re-enabled.

I have the same problem, But the difference is i didn't make any updates or any change in the site. It was working fine and suddenly it show this error. and system, node, and node access tables are empty. How can it go empty suddenly? can any body help to fix this.
(im using ubercart in the site)

I resolved my issue by adding the following section in my PHP.ini file:

RewriteEngine off
<IfModule mod_suphp.c>
suPHP_ConfigPath /home/wwwunise/public_html/php.ini
<Files php.ini>
order allow,deny
deny from all
</Files>
</IfModule> 

also the rewrite rules at the bottom should be added to the .htaccess file:

RewriteEngine off
<IfModule mod_suphp.c>
suPHP_ConfigPath /home/wwwunise/public_html/php.ini
<Files php.ini>
order allow,deny
deny from all
</Files>
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine on

# Rewrite URLs of the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>

My issue came out to be related to the fact that I used my ISP's QuickInstall feature for Drupal and it had installed the wrong php.ini and .htaccess files.

The other day I had the exact problem, because I did a drush dl drupal and not drush upc, did a database update and after a while decided I didn't need sites/all/modules/drupal-6.22 directory and deleted it! I got the error because there were many refereances to the folder I have removed, and I had to clear them all. I followed greggles' advice from #10 with a minor fault; I did update system set filename = replace(filename, 'drupal-6.10/', ''); instead of his advice, and the table was filled with many /sites/all/modules//.module. So, I had to import the same table from another database for which I did the same mistake, and then properly followed greggles' advice. I finally ran update.php and that saved my site from being totally wrecked.

Hi,
Here is the solution:
1) Go to Database.
2) Go to the table "system" (with any prefix if you have applied)
3) Search for following records (DB field is filename):
system.module
node.module
user.module
filter.module
block.module

4) After you find them, please check whether their "status" is "1".
5) If it is "0", make it "1".

And the fatal error will go.

Thanks.

BTW: This can also happen (D6) if the name of your database is wrong in your settings.php file.