Access denied "You are not authorized to access this page."

Need more info on how to reproduce on a clean installation.

I have the same issue.

1. When on a node content that belongs to a group,
2. click group tab
3. Click "add People" or any of the administrations options

I then get access denied. The url for the access denied page is:

group/node/382/admin/people/add-user

The OG Access module is uninstalled.

With which user are you getting this error? The admin(user 1)? A group manager? a group member? If you'r not going to the page as admin what did you gave to the user's roll?

More specific steps would helpful for this issue.

Sorry, I am going in as User 1 The supper Admin. I do not have any other users at this point. This is a fresh install and I just set up OG.

OK, is there a watchdogs alerts? Can you supply a database dump?

No error messages Just this from the log:

Type access denied
Date Wednesday, October 16, 2013 - 12:38
User spgd01
Location http://stcolumbachester.local/beta/group/node/382/admin/people/add-user
Referrer http://stcolumbachester.local/beta/node/382/group
Message group/node/382/admin/people/add-user
Severity warning
Hostname 127.0.0.1

I just went to:
admin/config/group/roles
and recive a number of these warnings:

Warning: Invalid argument supplied for foreach() in element_children() (line 6392 of E:\Websites\ws_090330_01_stcolumbachester\htdocs\beta\includes\common.inc).

OK, looking on your dump i can see that there are no roles and you get access denied because the function og_ui_user_access_group() check if there are any roles and if there isn't any role the access callback return false.

Did you upgrade your OG from older version to 2.x? On a clean installation of drupal you can't delete all your roles and this is something weird.

No it was a fresh install. I did add a role at some point and then I uninstalled and reinstalled the Dev version. I am not sure if it was the dev version or the adding roles, but it works now. I think it was the roles. Thank you for your help. For me this is closed but it looks like original poster had roles so i will leave it open.

I have this same issue with one of my three groups. It's set to both be a group and group content, as is the case with another content type that works fine. I do have roles enabled for the administrator to edit the content type, so what else would I need to do?

Same problem here.

In order to try and help we do need more information.
First, this was opened on 2.3. If this is the version you are using, please upgrade to latest stable version and verify it still exist.
Second, please try to provide a clear scenario on how to reproduce the problem.
Once you do it, please change status back to "Active".

I'm on OG 7.x-2.5, and I figured out that there was a database corruption issue. By removing all of the group fields and re-adding them, the issue was solved. However, it may be that simply removing and re-adding the group field is sufficient. The more complex solution I had found at first was to edit the og_role table and make sure there are were records for the content type in question, one for each of: non-member, member, administrator member. These need to have the gid field set to '0' (zero).

You can use the following SQL statements to help you easily insert these needed records (substitute 'my_content_type' with your content type's machine name):

insert into og_role (gid, group_type, group_bundle, name) values (0,'node','my_content_type','non-member');
insert into og_role (gid, group_type, group_bundle, name) values (0,'node','my_content_type','member');
insert into og_role (gid, group_type, group_bundle, name) values (0,'node','my_content_type','administrator member');

Then, there needs to be a matching record for each of the actual nodes that are of that group type. For example, if there is a group node with 'nid' of 15, then you have to have a record for that nid (in this case, it will become the gid field in the og_role table).

I hope this helps someone.

This problem occurred for me after changing the machine name of the OG context type. Fixed it by adjusting the og_role table as suggested by #14.