Comment 2 for bug 236305

I also experienced this bug. At best, it's a nuisance, but it could render the system unusable for some users. It's exacerbated by the fact that it's not immediately obvious that anything is wrong--it could be some time before the user notices any problems, making it harder to identify the cause. For these reasons I'd consider this a serious bug.

It may be possible to recover, however. If you reboot and choose the recovery mode option from the boot menu, you can boot the system to a root console. You can then edit /etc/group.

You should find that most of the groups in /etc/group have sequential group ID's (GID), and are listed in order by GID. Even though the admin group's GID has changed, it may still be listed in its original order. This allows you to infer the correct GID based on those of the groups immediately before and after admin.

For example, the relevant section of the file may look something like this:
powerdev:x:115:haldaemon,johnsmith
admin:x:1006:johnsmith
gdm:x:118:

In this example, it's a safe bet that the correct GID for admin is either 116 or 117. We should search the file to see if either 116 or 117 are in use but listed out of order--the correct admin GID should not appear elsewhere in the file. In our example, if 116 is used elsewhere in the file but 117 isn't, then 117 is probably the correct GID for admin.

If you're lucky, by following this process you should narrow the options down to a single possibility. If so, change the admin group's GID to this value, ensure a user is assigned to the group and save the file.

You should also delete the admin user with the command:
 userdel admin
(This should not affect /etc/group.)

With luck, all should be well when you reboot. Of course your mileage may vary, and I accept no responsibility if this makes things worse. There may also be better, smarter ways to find the correct GID for admin, but this worked for me and I decided not to question my luck.