Access denied to anonymous users (was: Node access settings)

What modules do you have enabled, and in particular are you using any access control modules?

Here's what viewing and saving admin/user/access does (from http://api.drupal.org/api/5/function/user_admin_perm_submit):

function user_admin_perm_submit($form_id, $form_values) {
  // Save permissions:
  $result = db_query('SELECT * FROM {role}');
  while ($role = db_fetch_object($result)) {
    if (isset($form_values[$role->rid])) {
      // Delete, so if we clear every checkbox we reset that role;
      // otherwise permissions are active and denied everywhere.
      db_query('DELETE FROM {permission} WHERE rid = %d', $role->rid);
      $form_values[$role->rid] = array_filter($form_values[$role->rid]);
      if (count($form_values[$role->rid])) {
        db_query("INSERT INTO {permission} (rid, perm) VALUES (%d, '%s')", $role->rid, implode(', ', array_keys($form_values[$role->rid])));
      }
    }
  }

  drupal_set_message(t('The changes have been saved.'));

  // Clear the cached pages and menus:
  menu_rebuild();
} 

This makes me think that perhaps the permission table is getting messed up for anonymous users somehow. I'm not sure though, it might also be the menu_rebuild() that fixes it.

Subscribing.. I have a very similar problem. See also my post http://drupal.org/comment/reply/188956/619801

i have worked around this problem with a hack. i am under a deadline, so not sure why/how this worked. a guess: at one point we had og turned on with permissions setup so that only group members could see content for their group. when we turned that module off, we cannot see content that should be available to anonymous users. i noticed that a clean d5.3 install had the following row in node_access table that was missing in our post-og database, so i ran an insert statement to put the following back in:

insert into node_acccess(nid, gid, realm, grant_view, grant_update, grant_delete) values('0', '0', 'all', '1', '0', '0');

after that, all the content i had wanted anonymous users to see showed up.

comments welcome on why this worked or warn others on why this was a bonehead move...

Subscribing.

Also got this weird problem yesterday. Digging through user_access() function, I finally found out that "access content" permission is not there in permission table for rid = 1. This after all the "go to admin/user/access", "check/uncheck" the access content permission for anonymous user but it still spit out 403 when trying to access the site as anonymous user. So I manually update the permission table, copying the value from previously backed up db (lucky we have that) but it still won't go. I need to go back to admin/user/access, check/uncheck again the anonymous permission and now it's work !

Very hard to duplicate since I don't even know what cause that. It suddenly happened with a blink of an eye, so to speak.

I am having these issues as well.
The site I was working on split into 2, the site with the problem did not need civicrm anymore, so I disabled it and removed the code and databases. I don't know whether this caused it.
We do have OG enabled.
I did not have the following row on node_access values('0', '0', 'all', '1', '0', '0'); so I inserted it as suggested but it did not make a difference.
I opened and saved the admin/user/access page as suggested and it works fine now for anonymous users.

To icstars
Thanks!!! You saved my life.

PS: I have the same problem on Drupal 6.6

I'm having the exact same problem: #371993: URL aliases are not available to anonymous users. I'll try icstars' trick and see if it helps.

I already had those values in my node_access table. I don't use any node access settings, and the newest node referenced in node_access is quite old.

By the way, this happens for URL aliased nodes with path.module. I've even tried to deinstall that path module, but the aliases are still there. (And they still break after a few hours). The URLs work again when I go to Performance -> clear cache.

I'm on Drupal 6.9, by the way.

This is being reported for 6.x, it should be fixed there and then backported.

I've set up an hourly cron job that checks for this error on my site, so that I can reset the cache to make the site work again. These are the times it stopped working the last month:

Sun, 15 Feb 2009 18:13:01 +0100 (CET)
Sun, 15 Feb 2009 19:13:01 +0100 (CET)
Sun, 15 Feb 2009 20:13:02 +0100 (CET)
Wed, 18 Feb 2009 16:13:02 +0100 (CET)
Wed, 18 Feb 2009 17:13:01 +0100 (CET)
Tue, 24 Feb 2009 18:13:01 +0100 (CET)
Tue, 24 Feb 2009 20:13:01 +0100 (CET)
Wed, 25 Feb 2009 16:13:01 +0100 (CET)
Thu, 26 Feb 2009 14:13:01 +0100 (CET)

I haven't really managed to pinpoint what makes the URL aliases stop working for anonymous users. The site does have a higher load around 16-19 every day, but not anything critical. The site is still very responsive.

This has recently happened on one of my sites as well...

We've found a fix by patching the node module, specifically node_access_write_grants().

The inline documentation for the $node parameter says:

The $node being written to. All that is necessary is that it contain a nid.

So why not check, before deleting the record, that the node id is > 0.

function node_access_write_grants($node, $grants, $realm = NULL, $delete = TRUE) {
  if ($delete && $node->nid >= 0) {
  	$query = 'DELETE FROM {node_access} WHERE nid = %d';
    if ($realm) {
      $query .= " AND realm in ('%s', 'all')";
    }
    db_query($query, $node->nid, $realm);
  }

Is this a sane fix? I'll be more than happy to provide a patch, unless someone else has another solution...

That code should be

$node->nid > 0

Rather than >=

Try to find out what module is calling node_access_write_grants(). It probably shouldn't...

I doubt that your "fix" is correct. It's more likely the caller's fault to pass a 0 $node->nid (possibly a NULL $node).

node_access_write_grants() should never be called by contrib modules, because in any but the trivial cases it may result in inconsistent data in the {node_access} table.

In our particular case there are no calls from node_access_write_grants() from anywhere outside of node.module.

While I agree that contrib modules shouldn't be using node_access_write_grants() directly, having this extra layer of security doesn't seem like a bad idea.

Core messing up the {node_access} table? That would be very nasty.

There's only one call to node_access_write_grants() in core, which is in node_access_acquire_grants(). Do you have modules that call node_access_acquire_grants() with a bad $node? Or modules calling node_save() with a bad $node?

It would be good to clear this up...

I tried everything on this page and nothing worked, but I stumbled upon my own solution for what appears to be a different cause for this problem.

The only thing that worked was for me to open up the permissions (admin/user/permissions), then I changed one of the settings for the anonymous user (to be sure the settings are applied), then save those changes.

After that everything magically worked.

I suspect one of the update scripts for my modules (applied yesterday) screwed up a setting somewhere for permissions, and performing this procedure fixed it.

My thanks, appreciation and respect for the entire drupal community.

Keep sharing the love.

did this via phpmyadmin and worked thank you much

insert into node_acccess(nid, gid, realm, grant_view, grant_update, grant_delete) values('0', '0', 'all', '1', '0', '0');

did this via phpmyadmin and worked thank you much

insert into node_acccess(nid, gid, realm, grant_view, grant_update, grant_delete) values('0', '0', 'all', '1', '0', '0');

This is pretty much the same as disabling node access completely, i.e. you're making everything visible to everyone. If that's your goal, then why not just uninstall all node access modules?

I've tried everything in above, and also great hints at http://devbee.com/you_are_not_authorized_to_access

Anon users still cant access any pages (except, strangely, a calendar ?? ).

I now have turned off all add-on modules, and still no luck.

Any fresh ideas. I've been searching for hours.

Install Devel Node Access (part of Devel module, enable its Debug Mode and its second block, look at one node, take a screenshot of the DNA information and post it here.

I've resolved my no access issue, which was my own fault - not a fault of this upgrade.

Helped me, and saved my day.
Just a correction on the typo ("access") so novices like me don't get confused:

insert into node_access(nid, gid, realm, grant_view, grant_update, grant_delete) values('0', '0', 'all', '1', '0', '0');

Question is ofcourse what caused this problem...

The problem is most probably your lack of understanding of how the node access system works.

Follow #28 and study the result, and you will begin to understand...

Inserting a 0/0/all/100 grant is like tearing a hole into a wall because you don't know how to open the door — it's probably not what you want...

Issue http://drupal.org/node/282555#comment-2154724 (which at least by the judgement of my quick check looks like a duplicate of this bug) has a comment No. 9, which mentions a way to replicate the issue. May be the answer lies somewhere there?

Interesting — yes, that could explain some of what's reported here, if your set-up really requires a 0/0/all/100 grant. This depends on what node access module(s) you have installed and how you're using it/them.

I believe, the 0/0/all/100 grant should only be present in the {node_access} table when no other grants are there. In that case it can be added safely, but if any other records are in {node_access}, then adding it will expose all of your nodes to everyone and make it impossible for your node access modules to restrict view access to any of your nodes.

See my reply in #282555-10: anonymous disappears from node_access table, gets access denied for all nodes.

I just posted a patch over in #282555: anonymous disappears from node_access table, gets access denied for all nodes that might help some of the folks here.

I'm tempted to mark these issues as duplicates of each other, but some of the problem descriptions are different enough that I don't think it's 100% clear they are duplicates.

Has this issue been fixed in the latest D6?

If you encounter this issue:

#28: Install Devel Node Access (part of Devel module, enable its Debug Mode and its second block, look at one node, take a screenshot of the DNA information and post it here.