Access control not working: nid = 0 realm=all remaining in the node_access table

This records keeps reappearing after I enable the og access control on the upgrade 5.1 with og 5.x-2.2.
I checked on a fresh install of drupal 5.1 and og 5.x-2.2 and this record doesn't exist.

Thanks for info. That means that when I activate the og access control on the upgraded 5.1, it should delete this record nid=0 in order to allow the access control on a per node basis. But this record remains in the table whether the access control is enabled or not. (drupal 5.1 and og 5.x-2.2).

Thanks for info. That means that when I activate the og access control on the upgraded 5.1, it should delete this record nid=0 in order to allow the access control on a per node basis. But this record remains in the table whether the access control is enabled or not. (drupal 5.1 and og 5.x-2.2).

On a fresh install of drupal5.1/og2.2, this record nid=0 doesn't appear at all, whether the access control is activated or not.

Actually it's working fine on a fresh drupal5.1 with og2.2, but on an upgrade from 4.7 to 5.1 with the latest og2.2, there is always a record nid=0 realm=all in the node_access table, even if the access control is active. I also tried with all the modules disabled, and got the same problem. I have to delete the record manually to have the og access control working.

I found out what was wrong. I had 3 node with a uid that was deleted a while ago. Strange, since deleting a user should also attribute its content to the anonymous account, at least that's what happens in drupal5. At the time when I deleted this user I was using drupal 4.6.
When enabling the access control, the og empties the node_access table and check the permissions of every nodes to insert the right rules in node_access. I checked the sql queries log and the following queries were executed 3 times during the og access control activation (in my case where 3 nodes are attributed to a deleted user):

SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid INNER JOIN node_revisions r ON r.vid = n.vid WHERE n.nid = 29
DELETE FROM node_access WHERE nid = 0
INSERT INTO node_access (nid, realm, gid, grant_view, grant_update, grant_delete) VALUES (0, 'all', 0, 1, 0, 0)

(29 being here the id of one of the 3 corrupted nodes).

I think there is an issue here, preventing og (and any access control system) to work. Assigning a nid=0 in the node_access table grant public access to all nodes!

I changed manually in the db the uid of these 3 nodes to 1, and used the admin account to delete them. (before, even the admin had an access denied when trying to access them). Then the access control worked fine and didn't add any nid=0 in the node_access table.
The node_access summary of the devel module comes useful to check that out, and can find these corrupted nodes for you (Legacy Nodes).

This may not fix the problem. This didn't work for me at the time.
gracearoha, if this solution doesn't work, you have to make sure that you don't have any orphan node (ie nodes with a uid that has been deleted). Normally it should be set to 0 automatically, but it wasn't in my case.

You may find this query useful:

SELECT * FROM node LEFT OUTER JOIN users ON node.uid=users.uid WHERE users.uid IS NULL

it shows all the nodes without author. On a healthy system, it should not return any row, but in my case, it returned all the corrupted rows that I had then to fix manually in phpMyAdmin by changing their uid by a known user (1 for instance).
I also found the legacy node feature of the devel module useful, see an feature request I posted.

Let us know if that helps you to fix your problem.

I'm glad you found these corrupted nodes.
How did you delete these nodes? you should let drupal do it, by first changing the uid to a existing user (ex 1) and then delete them WITH drupal. if you do it directly in the db, you will have problems.
what I suggest now is to try out the devel module, and go the page with the legacy node feature (devel/node_access/summary). It should tell you more about the whole access control system.