I've seen closed issues about this (http://drupal.org/node/429744) for D6 but nothing for D7. I'm not really sure where to start.

I have a site that is constantly displaying the following system messages:

The content access permissions have not been properly rebuilt.
The content access permissions need to be rebuilt.

Every time I try to rebuild it fails with:

An AJAX HTTP request terminated abnormally. Debugging information follows. Path: /examplecom/batch?render=overlay&id=246&op=do StatusText: error ResponseText: ReadyState: 0

I've tried different browsers, cleared caches, etc. I even get the message with the Content Access module disabled. There's not a lot of content on the site so I doubt it's a memory issue. Can anyone give me some insight into what's going on here?

CommentFileSizeAuthor
#15 modules_list.txt1.78 KBvideographics
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

good_man’s picture

hmm the permissions rebuilt is a core function, it mostly display such errors when you have a low-RAM available for PHP, try increasing it, restart apache, then rebuild access again. Also make sure no other module is causing this error (try also on fresh site), then update this issue with your results :)

videographics’s picture

Priority: Normal » Critical

Really stuck. Most roles have very little access to anything on the site and all of the access control modules are disabled. The only thing that gets anyone but an administrator access to any content is the "Bypass content access control" permission. Am I going to need to go directly to the database to fix this?

videographics’s picture

Sorry, I didn't respond to your memory suggestion. I'm at 768MB and it's still failing. There is VERY little content on this site and the number of modules isn't unusual. My fresh sites on this server don't have this issue but I still have a problem with this one. What other module might be affecting this? I've disabled ACL and Content Access.

I'll continue trying it with increasing the memory limit but I have similar sites using 256MB without these problems.

videographics’s picture

It's still failing with 1024MB.

videographics’s picture

Status: Active » Closed (works as designed)

Got it!!! I tracked it down to an Organic Groups permission module. Thanks for your help! Sorry to trouble you.

videographics’s picture

Status: Closed (works as designed) » Active

It's back. Rebuilt permissions once without a problem but then I reenabled Content Access and the problem is back. Still struggling...

good_man’s picture

Well, different access modules can *sometimes* be collapsed with each other, anyhow as I said there is nothing to do with Content Access since core do this, unless you give me a how-to reproduce this, so then I can be sure it's this module's problem. Otherwise, your problem is not clear at all.

videographics’s picture

I understand the rebuilding permissions is handled by core, but isn't it still possible for other modules to create a situation that would cause core to have a problem like this?

While I can't say for sure that Content Access is responsible for the problems, I can say that it's involved enough to keep core from doing it's job when it's enabled. I CAN rebuild my permissions with the module disabled and once I enable the Content Access module I can no longer rebuild permissions.

Even if it's not the Content Access module itself, it seems like it's involved in some way.

Whatever it is, I think it's possible that I have some type of data corruption but I can't be sure of the source or how to address it. Any insight anyone has on this would be most appreciated.

videographics’s picture

Would it be too risky to try to just clear out any database tables related to permissions so I could "start from scratch"? I have no critical permissions related setups on this site yet.

good_man’s picture

You didn't provide clear steps on how to reproduce this "bug". Unless I can't replicate it on my dev machine, I can't fix it. That's said, I need you to replicate it on clean site, then write the series of steps you made to get to that situation.

videographics’s picture

Category: bug » feature

I'm sorry for not being able to present you with a reproducible bug. Even though I can't be sure one way or another, my suspicion now is that this may NOT be reproducible from a clean install in which case I'll change this to a support request. What I can verify is that enabling the Content Access module prevents ME from rebuilding permissions on this one particular site. For one reason or another, when I enable the Content Access module, I cannot rebuild permissions and when I disable it, I can rebuild permissions without a problem.

I brought up this issue because I need some perspective on my situation -- regardless of the cause -- and would really appreciate some assistance digging myself out. Even if it's not considered a bug, I thought this would still be of interest here and, in the best case, I can imagine there being some interest in figuring out what kind of corruption (if that's what it is) would cause this module to affect the core rebuilding capability in this way.

videographics’s picture

Category: feature » support
good_man’s picture

First I want you to list what are the enabled modules on your site. Second try:
drush ws
in terminal (note: you need drush module), to see what's going on under the hood.

Hopefully with those information we can figure out the problem.

Note: Also, try Content Access dev version.

good_man’s picture

Status: Active » Closed (cannot reproduce)
videographics’s picture

FileSize
1.78 KB

Module list attached.

drush ws get me:

119347  30/Nov 10:55  notice  php  Notice: Undefined offset: 0 in views_handler_field_field->option_definition() (line 293 of /example.com/sites/all/modules/views/modules/field/views_handle                      
 119346  30/Nov 10:55  notice  php  Notice: Undefined offset: 0 in views_handler_field_field->option_definition() (line 293 of /example.com/sites/all/modules/views/modules/field/views_handle                      
 119345  30/Nov 10:55  notice  php  Notice: Undefined index: commerce_line_item in views_handler_field_field->access() (line 78 of /example.com/sites/all/modules/views/modules/field/views_ha                        
 119344  30/Nov 10:55  notice  php  Notice: Undefined index:  in views_handler_field_field->access() (line 78 of /example.com/sites/all/modules/views/modules/field/views_handler_field_field.        
 119343  30/Nov 10:55  notice  php  Notice: Undefined index: reverse_field_order_reference_node in views_handler_field_field->get_base_table() (line 97 of /example.com/sites/all/modules/view                                                  
 119342  30/Nov 10:55  notice  php  Notice: Undefined index:  in views_handler_field_field->access() (line 78 of /example.com/sites/all/modules/views/modules/field/views_handler_field_field.        
 119341  30/Nov 10:55  notice  php  Notice: Undefined index: reverse_field_order_reference_node in views_handler_field_field->get_base_table() (line 97 of /example.com/sites/all/modules/view                                                  

So it seems "Undefined index: in views_handler_field_field->access()" is of most interest all but I have been unable to find any guidance in addressing Undefined index issues. The fact remains that I can rebuild permissions without a problem until I enable the Content Access module. If you can't help me with this, could you at least point me in the right direction. I'm feeling really stuck.

videographics’s picture

...just tried the current dev version with no joy.

good_man’s picture

I tried to guess what the problem might be, but I couldn't. The log of drush ws you pasted is irrelevant to this problem (other bugs, notices). I have to keep this issue closed unless you provided steps on how to reproduce (my best guess for your problem is an error in config).

P.S. Uninstalling module doesn't remove the files, don't remove things from your reply, as they might be useful for someone else ;)

videographics’s picture

good_man, please do not confuse this SUPPORT REQUEST with a bug report. I do not expect this problem is reproducible from a clean install. I just need help making sense of this mess I'm in. Closing an unresolved support request seems to me to be nonsensical. I think it only makes sense to close this issue when I'm able to figure out why I can't rebuild permissions with the Content Access module enabled. With that said, I'm not suggesting there is any problem with this module that would necessarily require a change to the code. I just need some help with my particular implementation. If I can't resolve this, I'm seriously faced with completely rebuilding this fairly complex site from scratch just to be able to manage permissions on it. It's easily a month of work involved.

I'm hoping someone can provide some insight so I can figure out what kind of configuration error is involved or which tables to go clear out to get this working again. The reason I'm in this queue is that the Content Access module is the closest piece of code I can confirm is related to this problem. I'm NOT saying the code is responsible. I'm just hoping you have more insight on this that someone reading the issue queue for the Unicorn Ponies Theme (http://drupal.org/project/unicornponies).

Any insight into what config might be affecting this or which tables are involved would be appreciated.

BTW, if a config issue on it's own is able to kill this module and we can identify the problem, it might be worth investigating whether it would be worthwhile to include some error checking in the code to prevent this from being a problem for others in the future. Essential modules like this need to be as robust as possible. In this case, this does become relevant to the code of this module. I can confirm, one way or another, for my implementation, something related to this module is preventing me from rebuilding permissions on my site.

BTW, I removed my comment about the removed files because it was completely irrelevant to the thread and something that was working as it should.

good_man’s picture

My friend, I know that this is a real bug, but problem is, I can't figure out how to find it. That's why I needed help from you, but seems you are not able to figure out how it did happen too.

I want you first to take backup, then check {content_access} table and {node_access} table. If you really want to wipe out all the access rules, then empty those tables. It's a risky operation, that's why you should have backup + do it on a mirror dev of the site not production one (note: uninstalling content access will remove data from {content_access} table). Then try to re-activate the module, rebuild permissions and check if it works. I doubt this will work, but this is as far as I can get from your comments. I'm not responsible for anything happen when doing this, if you can't do it, try looking for some consultation.

videographics’s picture

Thanks for sticking with me on this. I know full well not to do any of this on a production site. I also know that I'm ultimately the only one responsible for any issues with my site. I'm just looking for ideas to get this working.

I have cleared the content_access table and reactivating the module and it had no effect. The problem persists.

Is the node_access table the only other one involved here? I'll try clearing the node_access table just to see what happens... I'll report back.

At this point, I'm actually preparing for the possibility that I may need to rebuild the site from scratch. (It's currently the only sure path to being able to launch this site.) If I do move ahead and if your hunch is that this is indeed a bug, I'll still following through with trying out any ideas anyone has for resolving this. We do need to the bottom of this. It'd be best not to have such an important function in such a fragile state.

HyperGlide’s picture

Hi -- I had what I thoug was a similar problem this past weekend and was able to solve it. Perhaps thei can help you. Please have a read of this node anda those I referenced. In the nd my problem was one corrupt node in my db that views help me detect and drop. Then it all worked like a champ.

http://drupal.org/node/1360034

Good Luck!

tanius’s picture

Issue summary: View changes

Sorry for bringing this old issue up, but want to leave a hint for anyone with a similar issue and similar difficulty finding it: it's in many cases some "bad node" (missing content type, non-loading author object etc.).

A very simple way to see which node is causing this: open modules/node/node.module, look up function node_access_rebuild there, and insert a debug instruction like this at the start of its foreach loop:

echo("going to process node $nid ...\n");

Then run the "rebuild permissions" task on the command line with drush php-eval 'node_access_rebuild();' and look up the last printed node ID before it crashes. Fix or delete this node and repeat the drush step until the task runs through. Don't forget to clean up node.module again.

geefin’s picture

I had come across stalling/stuck content rebuild permissions. This can happen with orphaned nodes - nodes that are only partially created (for example through a content/feed import) yet still leave parts of them about.

If you run :-

SELECT n.nid FROM node n LEFT JOIN node_revision nr ON nr.nid = n.nid WHERE nr.vid IS NULL ORDER BY n.nid ASC;

Through the database via PHPMySQL or your db program, it will then list the 'dead' nodes.

You can then simply run

DELETE FROM node WHERE nid IN (*insert comma seperated list of nids*);

To clear them and then (in my case) the content permissions rebuild smoothly.

hanksterr7’s picture

Thanks for all the great tips in this thread.

I too have had the failure rebuilding content access permissions. For me, the display stops at 48%.

I found that I had seven nodes that were corrupt in some way (haven't figured out what). I deleted them from the node table (via executing:
delete from node where nid=X
against the database once I knew all the nid's to delete.

I found the bad nodes by creating a page node and putting this php into the node body:

  db_delete('node_access')->execute();  // do this only once
  for ($i=3001; $i<4000; $i++) {  // pick your desired start and end range
    $node = node_load($i, NULL, TRUE);
    if (!empty($node)) {
      node_access_acquire_grants($node);
    }
    else
          //echo $i . ' no node';
      ;
  }
  echo $i;

and then previewing the page node

This first deletes all your entries from the node_access table. It then loops through all your nodes trying to load the node and then if it can be loaded, getting the access grants and writing them into the node_access table

If this fails, it will run forever (or timeout). To see where it stopped, query the node_access table via

select nid from node_access order by nid desc

and you'll see the last node that was processed.

Now the fun begins of trying to figure out what's wrong with the failing nodes (whatever is the next nid in the node table after the last one written to node_access). Missing content type? No matching node_revision record? Language mismatches vs field records? I spent hours trying to solve this but finally gave up and just deleted the bad nodes (actually, I saved them into a different table via

insert table node_save select * from node where nid in (X,Y,Z)

where X, Y and Z are the nid's of the nodes you want to make go away. Then do a
delete from node where nid in (X, Y, Z)
to remove them from the node table

With these changes, content access permissions could be rebuilt.

Good luck!

dibyadel’s picture

pls check your dblog under report and check which modes are giving trouble. Fix the modules. It should work

chunty’s picture

If you're on windows I found that when doing #22 you need to use double quotes on PHP command so

drush php-eval 'node_access_rebuild();'

becomes:

drush php-eval "node_access_rebuild();"