欢迎各位兄弟 发布技术文章

这里的技术是共享的

You are here

首页

RESOLVED: "Rebuilding content access permissions" hangs 错误 error drupal 6 rebuild permissions an http error 0 occurred

星期日, 2017-01-01 03:53 — adminshiping1

RESOLVED: "Rebuilding content access permissions" hangs

 

 
Posted by Avaya on 

I've been trying to get various access control modules to work; all require the content access permissions to be rebuilt

The content access permissions need to be rebuilt. Please visit this page.

After starting the rebuild, it hangs at:

Rebuilding content access permissions

Remaining 1 of 1.

I've let this run for as long as 9 hours, and still nothing. I do not have a big site either.

When I click on a different link to interrupt the rebuild, I get the following error:

An HTTP error 0 occurred. /drupal/?=batch&id=22&op=do

Looking for any advice on how to resolve this issue.

⋅ Categories: Drupal 6.x

Comments

 

dipen chaudhary’s picture

 

dipen chaudhary commented 

In node.module this piece of code, is setting time limit to 240 secs which might be still low than ur php.ini. You can try increasing set_time_limit arg to 1000 and then changing it back to 240 to keep code consistent.


 if (!ini_get('safe_mode')) {
        set_time_limit(240);
      }
      $result = db_query("SELECT nid FROM {node}");
      while ($node = db_fetch_object($result)) {
        $loaded_node = node_load($node->nid, NULL, TRUE);
        // To preserve database integrity, only aquire grants if the node
        // loads successfully.
        if (!empty($loaded_node)) {
          node_access_acquire_grants($loaded_node);
        }
      }
    }
  }

If anyone knows a more non core hackish way then I'll like to know as well.

--------------------------------------------------------
Dipen Chaudhary
www.qed42.com ( Drupal development services specialize in social networks and other user generated content platforms )
www.dipenchaudhary.com

trailerparkopera’s picture

 

trailerparkopera commented 

It came down to a combination of a specific module and malformed data. We resolved it by turning off all modules except core, and seeing if we could trigger the problem at that point. Then, we slowly enabled modules until the problem appeared. Then isolated the module, and looked at both it and it's related config and content data until we found/fixed the problem. Took a day or so (we use a lot of modules), but we found it (it was a sub-module of Domain Access that somehow got messed up during a transfer to a new sit).

trailerparkopera’s picture

 

Avaya commented 

I've disabled all modules except the "Core- optional". The "The content access permissions need to be rebuilt. Please visit this page." goes away, but I don't have any access control list.

I've tried turning on each access control list one by one, and only one at a time:
Organic Groups
Book Access
Content Access
Taxonomy Access Control

Each one requires the "rebuild" and each hangs. I even changed the 240 to 1000 in node.module (and repeating the above) and it still hangs...

What could be wrong?

dipen chaudhary’s picture

 

dipen chaudhary commented 

Time to check your apache error log.

--------------------------------------------------------
Dipen Chaudhary
www.qed42.com ( Drupal development services specialize in social networks and other user generated content platforms )
www.dipenchaudhary.com

trailerparkopera’s picture

 

Avaya commented 

This is sounds crazy, but every time I interrupted the build I got the

An HTTP error 0 occurred. /drupal/?=batch&id=22&op=do

error.

I though maybe it had problems with a node. So I deleted that node (after making a backup of it). The next time I ran the rebuild the id would change; I then deleted that node. I started noticing that all these nodes had a status of 0 (zero). I also noticed (through my recollection) that these were nodes that were originally from Wordpress, imported into another another Wordpress and then imported into Drupal.

I did a

DELETE * from `nodes` WHERE status=0;

I activated one of the access control modules and it rebuilt in about 3 seconds. I disabled one and activated another access control module and that works.

I'm thinking something was "funky" with those nodes maybe.

Either way. This has been resolved.

trailerparkopera’s picture

 

shivnibble commented 

Removing the 0 status content also resolved my problem with v6.14

trailerparkopera’s picture

 

JBack commented 

I just have to reply to this suggestion, as this is the worst suggestion that you could perform.

You are basically asking people to delete all unpublished content from your node table which is a HORRIBLE and POTENTIALLY DANGEROUS suggestion.

If you have any sort of workflow process for generating content, you will delete all content that is unpublished.

The reason you are getting the "You are not authorized to access this page" message is due to the fact that the content you are trying to access has a status = 0. Anonymous users cannot access nodes in this state.

You need to publish the node in "Publishing Options" when editing a node to fix this problem.

Unless a module supersedes the permissions system of drupal core.

I would highly suggest NOT executing this query against your database.

trailerparkopera’s picture

 

monotaga commented 

Not sure why this is happening to me, but I've found that I can just force node_access_rebuild() to not use batch mode by changing line 2314 of node.module from:

if ($batch_mode) {

to:

if (FALSE) {

trailerparkopera’s picture

 

easytech commented 

It solved my problem. I was hitting rebuild for whole day finally I set $batch_mode to FALSE. after that my content permission rebuild was successful
Thanks monotaga

trailerparkopera’s picture

 

LEternity commented 

Monotaga,

This hack doesn't seem to work for ver 6.14. Also in this version, the correct line would be 2310.

In my case this appeared after updating OG.

trailerparkopera’s picture

 

easytech commented 

OG seem to make that problem for me too. but It worked for me. I am using 6.14 ver.

trailerparkopera’s picture

 

vallab444 commented 

Thanks a ton, monotaga. I have spent two days cracking this, including a shot at Simple Access. But, my surprise was that this happened only after we moved the site from shared to VPS. Never faced this issue on the shared host. DOes this have anything to do with the host?

-Vallab

trailerparkopera’s picture

 

patrickfrickel commented 

Good thinking there....after waiting a 1/2 hour for it to rebuild...your solution worked great...did you reset the script back to original?

trailerparkopera’s picture

 

pavlosdan commented 

thank you so much, this was a lifesaver!

trailerparkopera’s picture

 

johnmmarty commented 

Resolved and rebuilt in 10 secs thanks dude.

trailerparkopera’s picture

 

barbietunnie commented 

It worked for me. Thanks

trailerparkopera’s picture

 

kpojeta commented 

monotaga - thank you, this worked. My permissions rebuilt in TWO seconds after this.

trailerparkopera’s picture

 

lyosef commented 

Where is node.module located?

DrunkMunki’s picture

 

DrunkMunki commented 

module/node/node.module

trailerparkopera’s picture

 

tribsel commented 

this worked for me too, and im using pressflow 6.20. But i'm not sure if this is a correct solution. Have no clue what is the source of this problem at first place.

trailerparkopera’s picture

 

shivnibble commented 

Also didn't work for me using v6.14. Not using OG. Did just migrate site from VM platform to our own server though.

Currently investigating the other fixes.

trailerparkopera’s picture

 

BeaPower commented 

worked for me too. Do I need to change it back after the batch processing has finished?

drupalshrek’s picture

 

drupalshrek commented 

As I understand the code, the hack of putting FALSE in basically means that the code will try and do the rebuild in real-time, which has a time limit of 240 seconds set. If your site uses only a few seconds to rebuild (or anything less than 240 seconds), then it should be fine to leave the code change in place. The only time when this would start to be a problem would be if the code genuinely requires more than 240 seconds to complete.

drupalshrek

trailerparkopera’s picture

 

fender177 commented 

I owe you a beer, sir, or mam be that the case. Thank you for posting this. Saved the day.

For those interested - I'm running Drupal 6.26 - the change is on line 2335.

Also - I just figured out that I can remove the above fix, by disabling the Secure Pages module.

drupalshrek’s picture

 

drupalshrek commented 

I had exactly the problem of seemingly infinite loop on permissions rebuild, and your little fix did the trick. It rebuilt in a couple of seconds. So, big thanks!

For me, it was in Drupal 6.26 with line 2335 of node.module:

function node_access_rebuild($batch_mode = FALSE) {
  db_query("DELETE FROM {node_access}");
  // Only recalculate if the site is using a node_access module.
  if (count(module_implements('node_grants'))) {
//  	if ($batch_mode) {
  	if (FALSE) {
      $batch = array(
        'title' => t('Rebuilding content access permissions'),
        'operations' => array(
          array('_node_access_rebuild_batch_operation', array()),
        ),
        'finished' => '_node_access_rebuild_batch_finished'
      );
      batch_set($batch);
    }

drupalshrek

supriyarajgopal’s picture

 

supriyarajgopal commented 

I was struggling with this issue since quite some time..
Thanks for the solution monotaga! :)

trailerparkopera’s picture

 

JeffTY commented 

My 6.14 site broke last night. Rebuild would hang on Initializing forever. I tried this hack and it worked beautifully. Permissions are rebuilt and site is back up and running in seconds. Thank you so much for discovering this hack! Long live Drupal 6!

Shabbir’s picture

 

Shabbir commented 

Hi monotaga,

I have tried your solution, but apparently i have a huge site (online e-learning site) that is currently developed in D6 and I am migrating it to D7, update script is clear but the only issue is "content access rule rebuild". Every time i try to run the rebuild permission, it takes me to the progress bar screen and after 59% it hangs, for hours it shows 59%. I tried your solution, but in D7 it doesn't work, rather if I try your solution after migration to D7, the progress bar screen never shows and from where it asks for confirmation (i.e. are you sure you want to rebuild screen) the page loads and then it shows error message. Please help as i am badly stuck.

Regards,
Shabbir

trailerparkopera’s picture

 

tanisharbaap commented 

I was having problems after install Organic Group and related modules. Once I put this hack in, permission was rebuilt quickly. I then put the old code back.

Thank you!!!

Shabbir’s picture

 

Shabbir commented 

Hey tanisharbaap,

I didnt have Organic Groups installed but the problem still prevails, it seems the progress bar doesn't progress after 59% and the hack doesnt work for me at all in Drupal7, any help would be much appreciated.

Regards,
Shabbir

Shabbir’s picture

 

Shabbir commented 

@monotago,
Thanks your solution worked just fine for me. I disabled ACL and content access modules and then re enabled them and tried your hack.

@tanisharbaap,
Sorry was having some different problem, i figured out i didn't migrate my cck fields that were used by content types.
It works with D7 and D6 to D7 migration.

Thanks alot, I owe you big time Monotago ;)

Stephen Ollman’s picture

 

Stephen Ollman commented 

Thank you heaps!!!

Finally found a solution that allowed me to rebuild.

Reverting code back to normal and rebuilding however ends in the same original hang issue.

Certified Drupal Site Builder
OPC IT
Web Application and Development Services

Stephen Ollman’s picture

 

Stephen Ollman commented 

I also tried disabling (not uninstalling) all access related modules. In my case the modules concerned were:

  • Organic groups access control
  • Organic groups field access
  • Taxonomy Access Control Lite

When disabled the rebuild went through without any error or hang.

I then re-enabled the 'Taxonomy Access Control Lite' module only and ran the $batch_mode version of the update again....HANGS WITH PROGRESS BAR AT 99%

I then re-enabled the 'Organic groups field access' module only and ran the $batch_mode version of the update again...PASS WITH NO PROGRESS BAR SHOWN

I then re-enabled the 'Organic groups access control' module only and ran the $batch_mode version of the update again...HANGS WITH PROGRESS BAR AT 99%

CONCLUSION

I've checked all the node tables and cannot find any blank or NULL entries in the 'group_type' or 'field_name' fields.

Hanging only occurs when the progress bar is shown. SO may either be a JS or AJAX issue.

Investigating further.

Certified Drupal Site Builder
OPC IT
Web Application and Development Services

epavlov’s picture

 

epavlov commented 

Strange enough, it's 2015 outside and I'm migrating from Drupal 6 to recent 7.34 and your solution to change if ($batch_mode) to FALSE still resolving this issue. Thank you.

trailerparkopera’s picture

 

joshnykamp commented 

This worked for me after I upped the execution time higher than 240.

mpruitt’s picture

 

mpruitt commented 

If you have the devel module installed and enabled, you can go to Development->Execute PHP Code, and then do this:

$status = node_access_rebuild(FALSE);

dpm($status);

trailerparkopera’s picture

 

hash6 commented 

The above trick/hack did work and node permissions were successfully rebuilt. Please try the above hack with increase in drupal_set_time_limit() set to higher value.
Thanks

trailerparkopera’s picture

 

Milkrow commented 

I had installed String Overrides module and then enabled that and Node Privacy Module when I got the "The content access permissions need to be rebuilt. Please visit this page." message. At first it hung up and then the screen went blank (white). I used the Back button, then read a few strings on this issue, then returned to start turning off/on modules, but thought I'd try and see what node it might be handing up on. It dutifully performed the rebuild in under a minute. I'm not sure what the hangup was, but it could have been some other server issue I suppose. I hope this may be helpful in some way.

trailerparkopera’s picture

 

salvis commented 

When the browser hangs (i.e. stops loading without displaying the progress bar), I reload the page (i.e. I click into the address field and hit Enter, NOT refresh), and this has always allowed the batch to proceed.

mikebrooks’s picture

 

mikebrooks commented 

This worked for me. Progress was stuck at 84% for 1 hour. Clicking into the address box and pressing enter "unstuck" the progress. I did need to do this twice.

trailerparkopera’s picture

 

protoplasm commented 

This is really scary when it happens. Each time it seems like there is a different issue to tackle. This time it took all Thanksgiving day to figure out the issue. ACL & Forum Access & even User Relationship Access would trigger the dreaded 'your content permissions haven't been built properly' error and batch errors. This time I found that I had eliminated some content types and not the nodes with them. Still, once I fixed this issue, this did not cure the problem (but probably was adding to the problem). I found that an old UID of 0 that I had was associated with some 100 nodes I created. When I would click on those old node UID links they triggered a 'page not found' response. So, I just changed them all to a non-0 UID for another of my usernames on the site and bingo. No ACL, Forum Access, or User Relationship Access problems. Everything works. Let me tell you, I thought 3 years of drupal was down the drain because everything was seeming to come apart at once with all kinds of pink warnings of so many different kinds. Bad enough an active website had to be down all day. Yet, I am so relieved that fixing this one problem has cleared up everything.

protoplasm

trailerparkopera’s picture

 

hbevan commented 

@protoplasm

No idea what went wrong with mine in the first place but the replacing UID method worked a treat! phew!

trailerparkopera’s picture

 

1timer commented 

i believe this is a legacy issue, but surely there should be some core fix for the possibility that a user is deleted but nodes remain - or am misinterpreting this?

kenorb’s picture

 

kenorb commented 

My problem was with Computed_field module and Search module, where rebuilding node cause loop by loading the same nodes again and over again, so even cron was not working correctly.

trailerparkopera’s picture

 

husztisanyi commented 

Maybe, there are some nodes, which is not in use, cause the problem. If you removed a node-type, but didn't delete that nodes, you should do it!
http://drupal.org/node/432938#comment-2667862

trailerparkopera’s picture

 

Oleksa commented 

I had the same problem. My reason was that I deleted users on user administration page, and after it I had problem with rebuilding access permissions.

I checked tables 'node' and 'node_revision' - even after I deleted user 72 , the node created by this user still had uid=72 , I changed it
UPDATE `node_revisions` SET uid = 64 WHERE uid = 72
UPDATE `node` SET uid = 64 WHERE uid = 72
for another user.
And after it I was able to rebuild access permissions.

trailerparkopera’s picture

 

carillonator commented 

monotaga's reply from above, that is. This reply didn't end up in the right place, sorry.

trailerparkopera’s picture

 

afdiaz commented 

I've changed FALSE instead of $batch_mode in modules/node/node.module and it works.

Thank you!

trailerparkopera’s picture

 

Dirk commented 

Seems to have saved me as well, worked for Openatrium beta7, based on Drupal 6.17

jtwalters’s picture

 

jtwalters commented 

I was using jQuery update module with jQuery 1.4. This causes the batch to not update.
To fix it, you have to prevent newer jQuery from loading when the URI contains "batch".

This is my function replacement:

function jquery_update_jquery_path() { 
  $curr_uri = request_uri();
  if (strpos($curr_uri,'admin')>0 || strpos($curr_uri,'edit')>0 || strpos($curr_uri,'add')>0 || strpos($curr_uri,'batch')>0 ){
    $jquery_file = array('none' => 'jquery.js', 'min' => 'jquery.min.js');
    return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
  }
  else {
    $jquery_file = array('none' => 'jquery-latest.js', 'min' => 'jquery-latest.min.js');
    return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
  }
}
trailerparkopera’s picture

 

tngcas commented 

For those of you who are wondering how to use multiple versions of jquery I've been using the following code located at the end of the jquery_update.module, this is definetely a hack but it's worked painlessly for me, especially since views won't work with any of the new jquery's

/**
 * Add whatever conditions you need to if list for pages which should use an older version.
 */  
function jquery_update_jquery_path() {

    if (arg(0)=='admin'||arg(0)=='batch'||arg(2)=='edit')) {
     $jquery_file = array('none' => 'jquery-1.3.2.js', 'min' => 'jquery-1.3.2.min.js');
      return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
    }
    else {
     $jquery_file = array('none' => 'jquery.js', 'min' => 'jquery.min.js');
      return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
    }
}
trailerparkopera’s picture

 

fuzzyjared commented 

Here is the code that I am using for the jquery update fix. It is basically the same as above, just a bit cleaner.

function jquery_update_jquery_path() {
$jquery_file = preg_match('/(admin|edit|add|batch)/', request_uri()) ?
array('none' => 'jquery.js', 'min' => 'jquery.min.js') :
array('none' => 'jquery-1.4.2.js', 'min' => 'jquery.min.1.4.4.js');
return JQUERY_UPDATE_REPLACE_PATH . '/' . $jquery_file[variable_get('jquery_update_compression_type', 'min')];
}

trailerparkopera’s picture

 

teedave commented 

I tried all of the things in this list and none worked - I never got past initializing!

I checked the settings for jquery update and had "minified" instead of "none", once set to the correct setting, it worked within seconds.

What a relief after many hours searching. Hope this helps someone else.

trailerparkopera’s picture

 

kulonlz commented 

Every time I tried to rebuild permissions, it never got past "Initializing". I tried every solution here and nothing worked. It turns out I needed to switch out of my custom theme. Both were sub-themes, using Zen. Another theme I created never had this issue. I can't quite figure out what the problem was, but it's another thing to try if anyone else is having issues.

alexmoreno’s picture

 

alexmoreno commented 

in my case, i had a problem in my custom template. I activated root candy or any of the core and repeated the operation... i even did not arrive to see the percentage progression. After the change and very slowly, but it worked: 1%... 10%... 75%... and worked fine :-). It can be simply a problem with your theme and js.

alexmoreno’s picture

 

alexmoreno commented 

the problem use to be the jquery.js file. If you are using a different one, custom, etc... you can have problems in functionalities like that.

Imaaxa-Cory’s picture

 

Imaaxa-Cory commented 

Check your node table for content without a content type. This fixed my problem.

I had a single node created when I had the OG Example feature enabled. Later I turned off the feature , the node stayed, and caused the permission rebuild to hang. I removed the node and the permission rebuild ran smoothly.

jsequeiros’s picture

 

jsequeiros commented 

For these situations sometimes works cron module, this usually solve these problems.
ajedrezutea.com

trailerparkopera’s picture

 

CobraMP commented 

was hanging at 99.9% and finally found the culprit. I'm no hacker so it took awhile but I finally made myself a view and sorted all my nodes by nid,vid, author id etc and found 3 that did not have a vid value. sadly i couldn't load the nodes and delete them from admin so I had to go to phpadmin and manually delete them.

trailerparkopera’s picture

 

joel_osc commented 

Thanks for posting this idea - helped me quickly track down and fix four vid mismatches between the node and node_revision that caused the permissions rebuild to fail.

www.openplus.ca

dadderley’s picture

 

dadderley commented 

Thanks.
Your insight on this fixed my problem as well.

muhammad.tanweer’s picture

 

muhammad.tanweer commented 

This worked for me. I was running Drupal 7 and didn't know which module was having a problem so I just did this change and it worked.

chidosoft’s picture

 

chidosoft commented 

Man you are awesome, in Nigeria, when some one had done such a great Job as you had done, we use to say "Give Him Three Kpozaa!" and every other person will shout in Chorus "KPOZAA! KPOZAA!! eeeKPOZAA!!!". So i give you three Kpoza. you are the man. you have just save me an embarrassment.

Thanks a million Times

trailerparkopera’s picture

 

Arun Murugadoss - Drupal Geeks commented 

In my case, the culprit was og_access. After upgraded the site to Drupal core 7.41 and Organic Groups to 7.x-2.7, the 'content access rebuild permission' was started to hang up and throw batch op error.

Also when I tried the same via Drush in the server (i.e: drush php-eval 'node_access_rebuild();'), it reported the below error saying that the 'entity_info' was missing.

Error: Class name must be a valid object or a string in includes/common.inc  in Line no: 7998
/**
 * Gets the entity controller for an entity type.
 *
 * @return DrupalEntityControllerInterface
 *   The entity controller object for the specified entity type.
 */
function entity_get_controller($entity_type) {
  $controllers = &drupal_static(__FUNCTION__, array());
  if (!isset($controllers[$entity_type])) {
    $type_info = entity_get_info($entity_type);
    $class = $type_info['controller class'];
    $controllers[$entity_type] = new $class($entity_type);
...

So when I checked the 'og_membership' table I found that the group's entity type and field_name fields were empty. So I updated the below changes in 'og_membership' table to resolve the issue.

  • Set the 'field_name' value as 'og_group_ref', if the 'entity_type' value as 'node' for a row.
  • Set the 'field_name' value as 'og_user_node', if the 'entity_type' value as 'user' for a row.
  • Update the 'group_type' field value as 'node' to every row.

After updated the values in the 'og_membership' table the rebuild content permission was run successfully.

Hope this helps someone facing the issue after the upgrade or moving the website.


来自 https://www.drupal.org/node/399572


普通分类: 
drupal
Powered by Drupal

友情链接

校园好文网

 www.shipingzhong.cn  个人技术网_前端_后台    备案号:苏ICP备18010659号-2