users-admin won't add or delete users

From the terminal, users-admin spits out the following when adding the user:

(users-admin:21721): Liboobs-CRITICAL **: create_dbus_struct_from_user: assertion `(login && password && homedir && shell)' failed

(users-admin:21721): Liboobs-CRITICAL **: Not committing due to inconsistencies in the configuration, this reflects a bug in the application

Thanks for your report, that works fine for me, Can you try to recreate the same with another user with required rights to create users? It seems tha there's something broken with your configuration, btw is this an upgraded machine or a fresh hardy installation? thanks.

I've tried with another user belonging to the admin group, with the same result. This machine was upgraded from Gutsy.

FYI, this is the contents of /usr/share/PolicyKit/policy/system-tools-backends.policy if it's of any use:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">

<policyconfig>

  <action id="org.freedesktop.systemtoolsbackends.set">
    <description>Manage system configuration</description>
    <message>System policy prevents modifying the configuration</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.systemtoolsbackends.self.set">
    <description>Change user configuration</description>
    <message>System policy prevents modifying the user configuration</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_self</allow_active>
    </defaults>
  </action>
</policyconfig>

I'm sure my Policykit configuration is correct.

Looks similar to bug http://bugzilla.gnome.org/show_bug.cgi?id=521438 , can you get the same logs Carlos is asking on the upstream report? especially the output of "./test-backends.pl UsersConfig" , thanks.

Pedro, I've attached the output of test-backends on to the upstream bug report (and here too). Although all my symptoms are the same, the original reporter upstream has users without valid shells, which isn't the case with me (or it doesn't seem so). He is reporting that adding a valid shell fixes his inability to add new users. So maybe my configuration is broken in a slightly different way.

I can confirm this, too. What was really annoying, was that I had just added a dozen students to the Edubuntu server, and then poof... gone. What is weird is that I did notice that it created unique groups for each user (I had not assigned them to a single group). But no entries were created in passwd or shadow files, just group. And all entries have a valid shell. Everything was working in Gutsy before I upgraded. I did manage to add the users via Webmin though.

I found that I was getting errors when running users-admin in terminal.

(users-admin:*****): Liboobs-CRITICAL **: create_dbus_struct_from_user: assertion `(login && password && homedir && shell)' failed

(users-admin:*****): Liboobs-CRITICAL **: Not committing due to inconsistencies in the configuration, this reflects a bug in the application

After I uninstalled the Sabayon system administration tool functionality returned to the users-admin program again without generating errors.

I am not sure what in the Sabayon code conflicts with the gnome users-admin tool.

I had the same problem.

In my case, I discovered that it was due to a null password : I created a guest account and configured gdm so that passwod ios not required for this account. In order to be coherent I deleted the password with 'passwd -d guest'. This creates a 'null' password that causes the assertion fail. If an account without password is authorized, then in liboobs-2.22.0/oobs/oobs-usersconfig.c line 362, the assertion g_return_val_if_fail ((login && password && homedir && shell), FALSE); should be replaced by g_return_val_if_fail ((login && homedir && shell), FALSE).

As having a password does not change the behaviour of gdm (it still not requires the passwd for this guest account), I put a password to "guest" and everything is now ok.

I had a look to the backends outputs previously attached above:
   - in test-backends output, there is a password for root account. This should be the cause of the pb, as for me
   - in UsersConfig.out, I do not see anything wrong about passwords..

edrangas: You're right - in my case, a simple:

'sudo passwd -l root'

...fixes my issue! I can now use the users-admin tool again.

In my case, I think I probably broke the configuration myself at some point. My current Hardy machine has been upgraded from Gutsy which was upgraded from Feisty, and at some point along the way I set a root password, and then later deleted it using 'sudo passwd -d root', which is probably what screwed it up

I've just fixed that upstream as part of bug 316667.