The content access permissions need to be rebuilt.
kims - July 11, 2008 - 10:43
| Project: | Content Access |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Description
not sure if this is the right place to post this, but i'll try.
I`v tired for severel days now, to run "The content access permissions need to be rebuilt. Please visit this page.", but all i get is "The content access permissions have not been properly rebuilt".
I`v upgraded my drupal from 5.7 to 6.3.
There is nothing in my logs that indicate what could be wrong, so i hope someone here can tell me what's going wrong.
Regards
Kim
#1
I've run into the same problem ... twice.
I'm new to the Drupal scene and have been building what might be considered a loaded system (60+ modules). There have been a few minor irritants, but no significant problems. Shortly after installing Content Access, though, I added an Address field to a Content Profile user type, and my system got trashed (blank white screens after login, and "Access Denied" to the front page for anonymous users. (I suspect a conflict between Content Access and Organic Groups, but I'm just guessing.) After a few days of hunting for a solution, and hacking at the database, I deleted the build and started over.
The current build is much more modest, with only the following modules installed in this order:
- cck-6.x-2.1.tar.gz
- views-6.x-2.1.tar.gz
- token-6.x-1.11.tar.gz
- pathauto-6.x-1.1.tar.gz
- admin_menu-6.x-1.1.tar.gz
- backup_migrate-6.x-1.0.tar.gz
- sitedoc-6.x-1.2.tar.gz
- journal-6.x-1.2.tar.gz
- content_access-6.x-1.0-beta1.tar.gz
In both builds, the "content access permissions need to be rebuilt. Please visit this page." message appears on all pages immediately after installing Content Access. I've gone to "this page" and after clicking the rebuild button, I get the "Rebuilding content access permissions" message. I manually kicked-off cron, but that doesn't seem to affect anything. The status report does not show any problems, except for the "permissions need to be rebuilt" banner.
In the second build, there are 7 roles defined, first name and last name fields added to the user profile, no users added, and there is 1 page created.
Any insights would be appreciated.
Thanks!
Mike
#2
UPDATE: I visited the Access Control page on all three defined content types (Book, Pages, Stories), and without changing anything, clicked on the Submit button on the first type (Book) and the "permissions need to be rebuild" message disappeared. Did the same on the 2 other types for good measure without any noticeable differences, since the banner was already gone.
Life seems to be good, at least for now. Would still like to understand if some interaction between Content Access & OG was involved in trashing the first build (wouldn't want to re-live that again!).
Thanks for reading this, anyway!
Mike
#3
This is weird on several points:
#4
Hi Salvis
1) The message would appear at the top of every page as part if its content ... not as a "residual" part from a previous page. Clicking on the "this page" link and clicking the [Rebuild permissions] button would lead to a new page indicating that permissions were being rebuilt, but there was no progress bar. If I recall correctly, refreshing the page did not produce the same page with the progress bar. (It may have been a different page, or an "Access Denied" page.
2) I don't know what caused the message to disappear, other than clicking [Submit] on the CA page of a Book Page content type. I don't believe that there was a cron process involved, even though I did run cron ... my 2nd rebuild is so small that cron would have PLENTY of time to complete before I navigated to the Book Page screen.
Hope this helps!
Mike
#5
That kind of message should say something like "Please rebuild permissions!". Once you click on the [Rebuild permissions] button, you should see something like "Rebuilding permissions" on a page of its own, along with a progress bar. That page should automatically refresh as many times as needed, until the process has completed. This is the safe way to rebuild permissions.
Modules should call node_access_needs_rebuild() which sets the site to display the former message, until you go and click the button. CA could presumably clear the message without doing a rebuild, or it could trigger a (non-batched) rebuild, but both would probably be wrong, IMO.
Since your story and my expectations don't match completely, I'm not sure whether my analysis is correct. If you want to pursue this with me, you'd have to post screenshots, so we can see the exact wording of what you get.
#6
Set your theme to one of the drupal cores, such as garland.
If you have any javascript errors the whole thing stops working.
#7
I've been having this problem also. The only way I've found to "fix" it is to disable the Organic groups access control module. When I turn it back on, the warning reappears.
I'm not following @mschupan's solution: I have no "access control page" in my content type edit page (for book or any other content type).
Just to be clear on what we're seeing...
Going to /admin/content/node-settings/rebuild shows you this:
After clicking on "Rebuild permissions", there is a brief pause, then the same page simply reloads. It does not show a "rebuilding permissions" page at all. Firefox error console shows no javascript errors.
#8
Duh! Nevermind about my previous comment about not having an "access control" page. I found this thread by searching on "rebuild permissions on site content" and failed to notice which project it was filed under! I did not have have the content_access module installed, so obviously, the solution described did not make sense.
After I installed content_access, and then followed the procedure described in #2, the warning message disappeared. However, after disabling content_access again, the problem reappears! (The same process of enabling content_access, followed by opening the Access control tab on any content type and submitting without making in changes, makes it go away.) Strange!
#9
Had the same issue and editing and saving a content type resolved the issue. Odd.
#10
This may make the "needs rebuilding" message go away, but I doubt that it
a) results in correct node access data (what rebuilding would do), and
b) corrects whatever problem interferes with rebuilding permissions.
By all means, go to admin/content/node-settings and click on the [Rebuild permissions] button. If this doesn't work, you'll be sorry down the line...
#11
Thank you very much for suggesting this. Fortunately I was able to rebuild the permissions. Your tip also helped in that the node access settings were not functioning. Rebuilding the permissions resolved this issue.
#12
@TrinitySEM: You were able to rebuild manually now, but not before???
That's a big surprise! Do you have any idea why the batch operation suddenly started working?
If all you did is the procedure suggested in #2, then there's a bug in CA after all and we need more information so that fago can find and fix it.
#13
@salvis: Yes, you are correct. I was unable to rebuild prior to editing the content type. Once I edited a content type, bang, the rebuild was successful.
I was also able to add an additional access module "Menu Access" without issue and was able to rebuild this time as well (did this as a precaution and out of curiousity). To triple confirm, I just went to rebuild now and couldn't find the function-somehow lost the location in the 36 hours since I've dealt with it. "A mind is a terrible thing" ;-) The instructions above must be for D5. Do you know where the rebuild function is located in D6?
#14
The [Rebuild permissions] button is on admin/content/node-settings for D5 and D6, if you have at least one node access module enabled. You don't find it there? Then your installation thinks you have no node access module installed and something is still wrong...
#15
Ahhh. Wasn't thinking in URL terms. Ok. I was able to rebuild. Seems to be working fine as previously described.
Thanks.
#16
Given TrinitySEM's confirmation in #13, I'm marking this as a bug for CA.
Let me summarize: Installing CA and ACL (and uc_node_access) put your installation into a state where rebuilding permission failed with only CA or with only ACL. Saving the content types (or just one?) with CA installed has fixed the installation.
CA: #429744: Rebuild Permissions: An error occurred. /batch?id=27&op=do
ACL: #430074: Rebuild Permissions: An error occurred. /batch?id=27&op=do
I'm still puzzled about what happened, but apparently, the cure is within the reach of CA...
fago?
#17
hm, the rebuild functionality is offered by core - CA does nothing special but activating this feature. So I really wonder where there should be the bug? Does it occur with CA alone too or only in conjunction with ACL?
#18
I wonder, too, but a number of people have reported that they were unable to rebuild permissions until they'd saved one (or more?) content type(s).
#19
Hi all,
I'm new to drupal, just installed D6. Wanted to share my experience. As I was configuring the modules, I got the
same error message : content access permissions need to be rebuilt.
After reading the messages here, I unselected og access control and saved config. The message went away.
Then I selected og access control again and saved config. The message reappeared.
This time I went ahead and clicked on rebuild. It did a quick rebuild and gave me a page with the following info :
Post settings
The content access permissions have been rebuilt.
Node access status
If the site is experiencing problems with permissions to content, you may have to rebuild the permissions cache. Possible causes for permission problems are disabling modules or configuration changes to permissions. Rebuilding will remove all privileges to posts, and replace them with permissions based on the current modules and settings.
Rebuilding may take some time if there is a lot of content or complex permission settings. After rebuilding has completed posts will automatically use the new permissions.
#20
I am running same issue. I upgraded few modules, in 6.10, and Keep getting the message that I need to rebuild the content permission, and the message doens't go away. I tried to rebuild the content permission, but no progress bar ever show up. just basically blank content. I have no idea it is done or not.
#21
running in the same Problem
first i thought this is a problem from
php.ini
maxtime etc -> so i set this to 96 000
ignore_user_abort = On
max_execution_time = 96000 ; Maximum execution time of each script, in seconds
max_input_time = 12000 ; Maximum amount of time each script may spend parsing request data
memory_limit = 228M
! long and big enough that this could not be the problem
80% CPU on TOP for houres ( now about 12h ) i think i'll kill this by a server restart
syslog = on
May 7 11:23:15 vs163174 drupal: http://drtest.marmorial.de|1241695395|locale|78.43.105.140|http://drtest.marmorial.de/batch?op=start&id=39|http://drtest.marmorial.de/admin/content/node-settings/rebuild|1||Parsed JavaScript file misc/progress.js.
May 7 11:23:15 vs163174 drupal: http://drtest.marmorial.de|1241695395|locale|78.43.105.140|http://drtest.marmorial.de/batch?op=start&id=39|http://drtest.marmorial.de/admin/content/node-settings/rebuild|1||Parsed JavaScript file misc/batch.js.
batch in mysqla:10:{s:4:"sets";a:1:{i:0;a:10:{s:7:"sandbox";a:3:{s:8:"progress";i:26960;s:12:"current_node";s:3:"111";s:3:"max";s:3:"107";}s:7:"results";a:0:{}s:7:"success";b:0;s:5:"title";s:37:"Rebuilding content access permissions";s:10:"operations";a:1:{i:0;a:2:{i:0;s:36:"_node_access_rebuild_batch_operation";i:1;a:0:{}}}s:8:"finished";s:35:"_node_access_rebuild_batch_finished";s:12:"init_message";s:24:"Initializing.<br/> ";s:16:"progress_message";s:31:"Remaining @remaining of @total.";s:13:"error_message";s:22:"An error has occurred.";s:5:"total";i:1;}}s:4:"form";a:28:{s:21:"#skip_duplicate_check";b:1;s:11:"#attributes";a:1:{s:5:"class";s:12:"confirmation";}s:11:"description";a:10:{s:6:"#value";s:113:"This action rebuilds all permissions on site content, and may be a lengthy process. This action cannot be undone.";s:5:"#post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:11:"#programmed";b:0;s:5:"#tree";b:0;s:8:"#parents";a:1:{i:0;s:11:"description";}s:14:"#array_parents";a:1:{i:0;s:11:"description";}s:7:"#weight";i:0;s:10:"#processed";b:0;s:16:"#defaults_loaded";b:1;s:7:"#sorted";b:1;}s:7:"confirm";a:18:{s:5:"#type";s:6:"hidden";s:6:"#value";i:1;s:5:"#post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:11:"#programmed";b:0;s:5:"#tree";b:0;s:8:"#parents";a:1:{i:0;s:7:"confirm";}s:14:"#array_parents";a:1:{i:0;s:7:"confirm";}s:7:"#weight";d:0.001;s:10:"#processed";b:1;s:12:"#description";N;s:11:"#attributes";a:0:{}s:9:"#required";b:0;s:6:"#input";b:1;s:8:"#process";a:1:{i:0;s:16:"form_expand_ahah";}s:5:"#name";s:7:"confirm";s:3:"#id";s:12:"edit-confirm";s:16:"#defaults_loaded";b:1;s:7:"#sorted";b:1;}s:7:"actions";a:13:{s:7:"#prefix";s:30:"<div class="container-inline">";s:7:"#suffix";s:6:"</div>";s:6:"submit";a:20:{s:5:"#type";s:6:"submit";s:6:"#value";s:19:"Rebuild permissions";s:5:"#post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:11:"#programmed";b:0;s:5:"#tree";b:0;s:8:"#parents";a:1:{i:0;s:6:"submit";}s:14:"#array_parents";a:2:{i:0;s:7:"actions";i:1;s:6:"submit";}s:7:"#weight";i:0;s:10:"#processed";b:1;s:12:"#description";N;s:11:"#attributes";a:0:{}s:9:"#required";b:0;s:6:"#input";b:1;s:5:"#name";s:2:"op";s:12:"#button_type";s:6:"submit";s:25:"#executes_submit_callback";b:1;s:8:"#process";a:1:{i:0;s:16:"form_expand_ahah";}s:3:"#id";s:11:"edit-submit";s:16:"#defaults_loaded";b:1;s:7:"#sorted";b:1;}s:6:"cancel";a:10:{s:6:"#value";s:49:"<a href="/admin/content/node-settings">Cancel</a>";s:5:"#post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:11:"#programmed";b:0;s:5:"#tree";b:0;s:8:"#parents";a:1:{i:0;s:6:"cancel";}s:14:"#array_parents";a:2:{i:0;s:7:"actions";i:1;s:6:"cancel";}s:7:"#weight";d:0.001;s:10:"#processed";b:0;s:16:"#defaults_loaded";b:1;s:7:"#sorted";b:1;}s:5:"#post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:11:"#programmed";b:0;s:5:"#tree";b:0;s:8:"#parents";a:1:{i:0;s:7:"actions";}s:14:"#array_parents";a:1:{i:0;s:7:"actions";}s:7:"#weight";d:0.002;s:10:"#processed";b:0;s:16:"#defaults_loaded";b:1;s:7:"#sorted";b:1;}s:6:"#theme";s:12:"confirm_form";s:11:"#parameters";a:2:{i:0;s:30:"node_configure_rebuild_confirm";i:1;a:3:{s:7:"storage";N;s:9:"submitted";b:0;s:4:"post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}}}s:9:"#build_id";s:37:"form-5a7e4579e777565d79f2330a90607a2e";s:5:"#type";s:4:"form";s:11:"#programmed";b:0;s:13:"form_build_id";a:18:{s:5:"#type";s:6:"hidden";s:6:"#value";s:37:"form-5a7e4579e777565d79f2330a90607a2e";s:3:"#id";s:37:"form-5a7e4579e777565d79f2330a90607a2e";s:5:"#name";s:13:"form_build_id";s:5:"#post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:11:"#programmed";b:0;s:5:"#tree";b:0;s:8:"#parents";a:1:{i:0;s:13:"form_build_id";}s:14:"#array_parents";a:1:{i:0;s:13:"form_build_id";}s:7:"#weight";d:0.003;s:10:"#processed";b:1;s:12:"#description";N;s:11:"#attributes";a:0:{}s:9:"#required";b:0;s:6:"#input";b:1;s:8:"#process";a:1:{i:0;s:16:"form_expand_ahah";}s:16:"#defaults_loaded";b:1;s:7:"#sorted";b:1;}s:6:"#token";s:30:"node_configure_rebuild_confirm";s:10:"form_token";a:19:{s:3:"#id";s:46:"edit-node-configure-rebuild-confirm-form-token";s:5:"#type";s:5:"token";s:14:"#default_value";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:5:"#post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:11:"#programmed";b:0;s:5:"#tree";b:0;s:8:"#parents";a:1:{i:0;s:10:"form_token";}s:14:"#array_parents";a:1:{i:0;s:10:"form_token";}s:7:"#weight";d:0.004;s:10:"#processed";b:0;s:12:"#description";N;s:11:"#attributes";a:0:{}s:9:"#required";b:0;s:6:"#input";b:1;s:5:"#name";s:10:"form_token";s:6:"#value";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:17:"#needs_validation";b:1;s:16:"#defaults_loaded";b:1;s:7:"#sorted";b:1;}s:7:"form_id";a:18:{s:5:"#type";s:6:"hidden";s:6:"#value";s:30:"node_configure_rebuild_confirm";s:3:"#id";s:35:"edit-node-configure-rebuild-confirm";s:5:"#post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:11:"#programmed";b:0;s:5:"#tree";b:0;s:8:"#parents";a:1:{i:0;s:7:"form_id";}s:14:"#array_parents";a:1:{i:0;s:7:"form_id";}s:7:"#weight";d:0.005;s:10:"#processed";b:1;s:12:"#description";N;s:11:"#attributes";a:0:{}s:9:"#required";b:0;s:6:"#input";b:1;s:8:"#process";a:1:{i:0;s:16:"form_expand_ahah";}s:5:"#name";s:7:"form_id";s:16:"#defaults_loaded";b:1;s:7:"#sorted";b:1;}s:3:"#id";s:30:"node-configure-rebuild-confirm";s:12:"#description";N;s:9:"#required";b:0;s:5:"#tree";b:0;s:8:"#parents";a:0:{}s:7:"#method";s:4:"post";s:7:"#action";s:36:"/admin/content/node-settings/rebuild";s:12:"#after_build";a:2:{i:0;s:22:"fckeditor_process_form";i:1;s:20:"wysiwyg_process_form";}s:7:"#submit";a:1:{i:0;s:37:"node_configure_rebuild_confirm_submit";}s:5:"#post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:10:"#processed";b:0;s:16:"#defaults_loaded";b:1;s:7:"#sorted";b:1;s:17:"#after_build_done";b:1;}s:10:"form_state";a:5:{s:7:"storage";N;s:9:"submitted";b:1;s:6:"values";a:6:{s:7:"confirm";i:1;s:2:"op";s:19:"Rebuild permissions";s:6:"submit";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-5a7e4579e777565d79f2330a90607a2e";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:14:"clicked_button";a:18:{s:5:"#type";s:6:"submit";s:6:"#value";s:19:"Rebuild permissions";s:5:"#post";a:5:{s:7:"confirm";s:1:"1";s:2:"op";s:19:"Rebuild permissions";s:13:"form_build_id";s:37:"form-8e4eff467c70d2f7ca257f84e31e7c95";s:10:"form_token";s:32:"8efad3ce3c4bfacb975b6404c02adea9";s:7:"form_id";s:30:"node_configure_rebuild_confirm";}s:11:"#programmed";b:0;s:5:"#tree";b:0;s:8:"#parents";a:1:{i:0;s:6:"submit";}s:14:"#array_parents";a:2:{i:0;s:7:"actions";i:1;s:6:"submit";}s:7:"#weight";i:0;s:10:"#processed";b:0;s:12:"#description";N;s:11:"#attributes";a:0:{}s:9:"#required";b:0;s:6:"#input";b:1;s:5:"#name";s:2:"op";s:12:"#button_type";s:6:"submit";s:25:"#executes_submit_callback";b:1;s:8:"#process";a:1:{i:0;s:16:"form_expand_ahah";}s:3:"#id";s:11:"edit-submit";}s:8:"redirect";s:27:"admin/content/node-settings";}s:11:"progressive";b:1;s:11:"current_set";i:0;s:3:"url";s:5:"batch";s:11:"source_page";s:35:"admin/content/node-settings/rebuild";s:8:"redirect";N;s:2:"id";s:2:"41";s:13:"error_message";s:76:"Please continue to <a href="/batch?id=41&op=finished">the error page</a>";}
now i started to switch off the modules
#22
Ok i think i have found the answer of this problem
PLESK (i hate this shit)
the VSERVER manager overwrites some parts of the config with a cronjob
and set safe_mode to on
but must be:
php_admin_flag safe_mode off
[solved]
#23
Did this get patched? I ran into it today -- some of my users were unable to edit pages they should have had permissions for, so I tried to rebuild permissions. I did encounter some problems related to out of date content, which I fixed, but in the end I had to disable and uninstall CA before I was able to rebuild permissions successfully. Our site was down for about 3 hours.
I plan to copy the whole mess to my test server and reinstall CA to see if I can get a better reproducible test case.
#24
No. It's unclear where the problem is.
If you have problems with permissions, start with installing devel_node_access.
#25
Thanks, I misunderstood what devel_node_access does. I'll try that on the test server to see if I can track down what the problem is. From #22, I thought someone had figured out more of what was causing this than is actually the case, I guess.
#26
safe_mode can cause trouble with files, but I don't think it can affect node access (which is completely inside the database) in any way.
This thread has somewhat degenerated into a collection of various rants. If you do succeed in finding something substantial, it'd probably be a good idea to start a new thread...
#27
I am dealing with this problem now on a site that hasn't had issues with content access and has been running for over a year.
I get the message about rebuilding content access permissions, I start the batch process and invariably end up with the "content access permissions cannot be rebuilt" message. This has basically set all new content on my site to hidden for anonymous users.
I went into the content types (I have about 30) and was able to save the Access Controls page and have the permissions rebuilt for that type. Everything was functioning normally.
Unfortunately as I neared the end of my list, I noticed some odd permissions on the Access Controls page and edited them before saving. I got a "changes have been saved" message followed by a "you must rebuild access permissions go to this page" warning.
Since then, I've disabled Content Access and ACL, run the batch process, re-enabled them and tried to save the Access Control page at the content type level and nothing works. Permissions are not rebuilt, all recent content on my site is hidden to anonymous users.
If anyone has a solution or even a band-aid, I'll take it. I don't know what else to do to get the permissions correct. Can I edit something directly in the database?
Thanks-
#28
The batch process works by repeatedly reloading the same page (with an incremented parameter), doing a little bit of work every time. How does it fail? Is it a certain step that takes too long and times out or what?
#29
In my case, it didn't fail. It completed with an error message that said it didn't work.
After trying a number of things, I ran uninstall on Content Access and ACL, then deleted the modules. Everything seems ok now.
#30
I have this problem on a recent 5.20 to 6.14 upgrade. I run forums across four domain names sharing a single database with 11,000+ common users. Two domains are fine, and two have this error. Turning off ACL on each domain makes the error message go away. CA has never been installed. I tried the button on admin/content/node-settings several times and I tried submitting all the content type and taxonomies. I've uninstalled both ACL and Forum Access per domain and still have the banner when I re-enable them:
* The content access permissions have not been properly rebuilt.
* The content access permissions need to be rebuilt.
I have no idea what to try next.... ideas would be appreciated.
#31
Turning off all (read 'the last') node access module will disable the node access system and remove the need for rebuilding the database. That's normal behavior and does not incriminate ACL in any way.
Four domains sharing a single database? Are you also using domain_access (another node access module)? Are you sure that your multi-domain setup can actually work with node access? Have you tried this on a smaller test installation?
The button on admin/content/node-settings must work — if it doesn't, then your walking on ice that's too thin for a production site. I still haven't been able to extract from any one of the posters how it fails...
I mean, what happens immediately before displaying
* The content access permissions have not been properly rebuilt.
? Does one of the steps time out? The first one? The last one? One in the middle? Always the same one? Or does it proceed all the way to the end and unexpectedly display the message? After how many seconds does it terminate? Study how the process works on your test installation with a few hundred messages and compare that to what happens on your live installation. How does it differ? Where does it go wrong?
Any messages in the watchdog log? Have you tried raising PHP memory and/or timeouts? Does this make any difference in how it fails? Have you tried using another browser?
Since we can't see what you're seeing, we have no way to help you, unless you tell us... Oh, and what are your Drupal and PHP versions?
#32
Not using domain_access. The only multi-site module we use is Single Sign-on. Drupal core supports everything else using shared tables. We do use ACL & Forum Access and I just installed Content Access to try and trouble shoot this. Turning off Forum Access with ACL on doesn't change anything. Turning off ACL makes the message go away. In fact turning it off gives me message #1 (the good one):
* Operating in off-line mode.
* Content permissions have been rebuilt.
* The configuration options have been saved.
Turning on Content Access only gives me message #2 (the bad one):
* The content access permissions need to be rebuilt. Please visit this page.
Turning off Content Access gives me message #1 again.
Turning on ACL only gives me message #2 again.
Rebuilding permissions is almost instantaneous with ACL or Content Access off. With either on it takes a few minutes but gives me the moving progress bar and "Remaining 1 of 1". When it completes it returns to the infamous result message:
* The content access permissions have not been properly rebuilt.
* The content access permissions need to be rebuilt.
This happens with both ACL and Content Access installed and either of them enabled on their own gives exactly the same result.
Here's the status details - remember this installation has two sites working fine and two sites with permissions problems:
Drupal 6.14
Database updates Up to date
MySQL database 5.0.86
PHP 5.1.6
PHP memory limit 128M
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Web server Apache/2.2.3 (CentOS)
The only log error I can attribute to running the permissions rebuild is this one (and it may be co-incidental):
Location /batch?id=25&op=do
Referrer /batch?op=start&id=25
Message Invalid argument supplied for foreach() in /../../modules/taxonomy/taxonomy.module on line 1214.
#33
You #2 "bad" message is not bad. It's the proper behavior. You do need to rebuild permissions at that point.
What's bad is that the rebuilding fails, i.e. the
* The content access permissions have not been properly rebuilt.
message is the bad one.
Also, I'm surprised that you see "Remaining 1 of 1" — I'd expect you to see something like "Remaining N of 234".
When you have "Remaining 1 of 1", does the progress bar sit at 0% for "a few minutes" or at 100%?
What's your browser? Have you tried another one?
When it sits there, try putting the cursor into the address line of the browser and hitting the Enter key again.
Well, that gives us something to work with! The code in taxonomy.module is this:
<?php/**
* Implementation of hook_nodeapi('update_index').
*/
function taxonomy_node_update_index(&$node) {
$output = array();
foreach ($node->taxonomy as $term) {
$output[] = $term->name;
}
if (count($output)) {
return '<strong>('. implode(', ', $output) .')</strong>';
}
}
?>
Change it to
<?php/**
* Implementation of hook_nodeapi('update_index').
*/
function taxonomy_node_update_index(&$node) {
$output = array();
if (isset($node->taxonomy) && is_array($node->taxonomy)) { // <== NEW
foreach ($node->taxonomy as $term) {
$output[] = $term->name;
}
} // <== NEW
if (count($output)) {
return '<strong>('. implode(', ', $output) .')</strong>';
}
}
?>
and see what happens...
#34
Browser is Firefox 3.5.5 on OS X 10.6.2.
I don't normally use Content Access so I'll try this with the ACL module first. I uninstalled the ACL module on one of the sites with this error which deleted the ACL tables (acl, acl_node, & acl_user). I re-enabled the module and this created empty tables. I can confirm that the new empty ACL tables are not being repopulated by the permissions rebuild.
When I do the permissions rebuild, the "remaining 1 of 1" progress bar actually chugs across the screen counting percentages as if there were multiple tasks going on in the background. Either that or it's reporting the % of the 1 task being done. It looks normal and takes about 10-15 minutes on the smallest problem site.
Trying that code above gives me the same "remaining 1 of 1" dialog. I've attached a screen shot. But nothing gets written to the ACL tables. They are still empty. Where do I need to look to find out why the tables aren't being written?
#35
Thank you for the picture — that looks correct (I was confused about the 1 of 1). Yes, it's the % completed of the one task.
It's correct that the ACL tables are not populated during the permissions rebuild. What's done is to replace the one single record in the {node_access} table with one record per node. At the end of the rebuild, you should have the same number of records in {node_access} as in {node}.
Disabling ACL removes all records in {node_access} and puts back the single one — that's why it's almost instantaneous.
So, it goes all the way to 100%, but in the end you still get
* The content access permissions have not been properly rebuilt.
? Is that what you're seeing?
#36
Yep, that's exactly what I'm seeing. So allow me to be thoroughly confused here as nothing matches after a permissions rebuild:
Site A:
{node} has 10,394 records
{node_access} has 3,156 records
Site B:
{node} has 16,125 records
{node_access} 11 records
I check some other installs as well which don't show any errors. Are the numbers supposed to stay in sync or do they drift apart over time?
#37
Those results are odd indeed. ACL by itself doesn't do anything (as long as the ACL tables are empty). It only provides services to other node access modules. However, Drupal doesn't know this and treats ACL like any other node access module, meaning it replaces the one 0/0/all/100 record (which allows read access to all nodes) by one nid/0/all/100 record for each node (provided you really don't have any other node access modules installed besides ACL!), to prepare itself for managing per-node access rights.
This process is somewhat time-consuming because Drupal has to load each node and ask whether any module wants to contribute any node access grants. No one answers, so Drupal inserts that one nid/0/all/100 record and goes on to the next node.
The number of records in the {node_access} table will usually be much higher if you actively use node access. For example, if two roles have access to a given node, you'll typically have two records for that one node. If you have less records in {node_access} than in {node}, this normally means that some of your nodes aren't accessible to users without the administer nodes permission.
Try installing the devel_node_access (DNA) module (part of the Devel module). It has a "Node Access Summary" page that may provide some insight.
Let's see those 11 records on site B! (Best to post a screenshot in png/jpg/gif format)
Enable DNA's debug mode as well as its second block and look at some of the nodes on site B.
#38
This is /devel/node_access/summary summary for Site B (it doesn't quite tally with the 11):
Node_access summary
Operating in off-line mode.
The content access permissions need to be rebuilt. Please visit this page.
Legacy Nodes
You have 16120 nodes in your node table which are not represented in your node_access table. If you have an access control module installed, these nodes may be hidden from all users. This could be caused by publishing nodes before enabling the access control module. If this is the case, manually updating each node should add it to the node_access table and fix the problem.
Access Granted to Some Nodes
The following realms appear to grant all users access to some specific nodes. This may be perfectly normal, if some of your content is available to the public.
Public Nodes
realm public nodes
all 1
Summary by Realm
The following realms grant limited access to some specific nodes.
Protected Nodes
realm private nodes
forum_access 4
I'm wondering if some of my tables didn't get upgraded correctly. Is there an integrity check for the database structure of D6.14? Somehow most of the nodes got unhooked.
Here's the node_access screenshot of the 11 records generated by Site B. It's repeatable. I can disable ACL and then re-enable it and rebuild the {node_access} table. The rebuilding results don't vary.
#39
Yes, the Schema module does this.
Your screenshot shows Forum Access records. So you're not just enabling and disabling ACL but also Forum Access?
Now, enable DNA debug mode and show us screenshots of the DNA information for node/1, node/2, and some other node that is not on the list (e.g. node/3, if it exists).