"User and Groups" does not inform user that manual UID already exists and create user groups.

Thank you for your bug. What version of Ubuntu do you use?

Problem exists under 6.10 and 7.04. Did not verify under 6.0.6. Only tested under x86. 6.10 and 7.04 have all fixes as of March 30th.

Thanks,

Similar situation occurs when an user is deleted and re-added.

Suppose you add a user "newuser" using the System -> Administration -> Users and Groups. The user is successfully created.
Then you decide to remove the user, and it is successfully removed.
Then, if you add user "newuser" again, the creation dialog works just like before, and the user shows up in the list, but it is not created. Indeed, closing and opening again the Users and Groups dialog will not show this user, nor will it be available as login.

In order to make it work again, it is needed to click on "Manage Groups" in the "Users settings" dialog, then manually remove the group "newuser". After that, it is possible to create the user successfully using the graphical interface.

However, as noted above, there are no messages indicating any errors.

I'm sorry, I forgot to indicate this happens in Ubuntu Feisty 7.04.

I just encountered this same issue on a new Feisty (7.04) install when I attempted to create a user name of "staff". As is default in Ubuntu, USERGROUPS=yes in adduser.conf so each new user gets their own group. The group "staff" is a Ubuntu default with a GID of 50 so it couldn't be used. No messages were displayed by users-admin and I didn't figure out what the problem was until I tried to use adduser which informed me the group already existed.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release?

Thank you,

Iulian

Sure, no problem.

Problem still exists on 8.04 (64bit edition) with latest updates Feb 28 2008.

Thanks

this bug looks like the same as bug 141067, only applied to users. I suggest setting it as a duplicate of 141067 (more explicit on the causes of this behaviour).

correction: best match is bug 124993. Comments, anyone?

No, this is completely different from those bugs-- fixing bug 124993 just gives the admin the opportunity to work around this bug, by manually checking all the existing uid's. That shouldn't be necessary, because a smart system should warn the admin automatically.

november 18th, in Ubuntu 8.10.
Not fixed. I've lost my admin priviledges and i can't boot anymore...need to reinstall I Guess.

users-admin works much better on Intrepid (8.10). If I create a user named "admin" it takes the existing admin group (112) and reassigns it a new ID in the user range (like 1002) and adds the admin user to all the normal user groups apparently without problems as there are no messages about it. This way it provides "Windows 9x-Me" security without the annoying Vista-like security warning pop-ups. Thanks!

i have the same problem... although i did not change the uid or anything else. just the password fields.
the group of the new user gets added:
grep test /etc/group
test:x:1005:
testu:x:1006:
(i tried two times... thought maybe test is a reserved word the first time)
but no user in passwd and no home dir.
i did add users on the console before, maybe that complicated things?
no matter what went wrong.. its just a WTF NONO!!! to not do any error handling, im really pissed.

I've just fixed this problem upstream by checking that an UID free before creating the user. If that's not the case, a dialog is shown. This will sadly not be available in GNOME 2.28 because this would imply modifying strings, and that's too late for that.

The bug described in the last comment can be fixed separately and could go into 2.28 if I find how to fix it.

AmenophisIII: Actually, I can't find how the problem you describe can appear, since the tool should always choose a free UID by default. The only explanation I can find is that you have an user with ID 60000 and another with ID 60001. Could you open a separate report for that? Thanks!

This is fixed upstream with the system-tools-backends 2.9.1, which should be in Lucid soon.

This bug was fixed in the package gnome-system-tools - 2.29.3-0ubuntu1

---------------
gnome-system-tools (2.29.3-0ubuntu1) lucid; urgency=low

  * New upstream release (LP: #506365)
    - Move to new System Tools Backends protocol (new liboobs API).
      We now only commit changes to one user at a time, reducing the
      risk for dangerous bugs.
    - Include default profiles configuration file (user-profiles.conf).
      Distributors should modify it to suit their needs and send them
      back for inclusion.
    - When creating an user, don't force UID, main group, home directory
      and shell: these parameters are now handled (better) by the platform
      tools (LP: #488158, LP: #313990)
    - Allow removing home directory when deleting an user (LP: #426125).
    - Don't allow deleting the last administrator account, and warn when
      the user is losing its own admin rights. Same for active users
      (LP: #25947, LP: #349453)
    - Don't allow creating a group with an existing GID (LP: #491434)
    - Use UID and GID ranges defined by liboobs, depending on the platform's
      abilities.
    - Clear suggested login entry when Real name is emptied in the new user
      dialog.
    - Change GConf "showall" option to apply only on users. System groups are
      always shown, since they are the most interesting ones.
    - Various UI and string improvements.
    - Change password for current user by running 'passwd', to avoid
      breaking keyrings and encrypted dirs
    - Ask for PolicyKit authentication when it most makes sense, i.e.
      when showing dialogs
    - Option to set encrypted home directories when creating users (on
      platforms that support it) (LP: #302870)
    - When editing one group, only commit changes to that group
    - When changing Real name, update it in the users list (LP: #498970)
    - Select current user on start, and the first one after selected user
      has been deleted
    - Don't force updating configuration twice on start
  * Also fixes LP: #344182, LP: #208057, LP: #188757, LP: #372695,
    LP: #99276, LP: #160862
  * debian/control:
    - Bump liboobs-dev build-dep to 2.29.3
  * debian/gnome-system-tools.install:
    - Don't install debian/profile
    - Install upstream user-profiles.conf instead
  * Delete debian/profiles
  * Refreshed patches:
    - 25_sambashare_group_definition.patch
    - 90_relibtoolize.patch
  * Dropped debian/patches/85_user_gnome_about_me_for_password.patch:
    - The change is obsolete in the new version
  * debian/patches/82_gst-packages-time-admin.patch:
    - Updated to remove superfluous UI file changes, causing focus issues
      in the users-admin password change dialog. Thanks to Will for
      spotting this (LP: #501976)
 -- Chris Coulson <email address hidden> Fri, 05 Feb 2010 15:30:10 +0000