Can't edit groups (freeze and "permission denied" error)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
system-tools-backends |
Fix Released
|
Undecided
|
Unassigned | ||
system-tools-backends (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Binary package hint: gnome-system-tools
netbook-remix 10.4beta1, system language set to german
1. open user and group administration tool System--User&Group administration
2. Add a new admin user, user id 1001
3. new user doesn't get a group. Add a new group, group id 1001
4. group tool freezes for 5..10 seconds
5. error popup window: unable to save configuration. Unknown error.
6. quit group tool, reopen it again. Check list of groups, the new group does exist now. So /etc/groups was saved successfully.
7. from the group list, open properties for the new group. No member so far. Add the new user to the group.
8. tool freezes again and gives error pop up again (similar to step 4 and 5)
9. repeat step 6: reopen group tool
10. repeat step 7: check properties of the new group. The new user was added successfully.
ProblemType: Bug
Architecture: i386
Date: Sat Mar 20 21:36:18 2010
DistroRelease: Ubuntu 10.04
ExecutablePath: /usr/bin/
InstallationMedia: Ubuntu-Netbook 10.04 "Lucid Lynx" - Beta i386 (20100318)
Package: gnome-system-tools 2.29.91-0ubuntu2
ProcEnviron:
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcVersionSign
SourcePackage: gnome-system-tools
Uname: Linux 2.6.32-16-generic i686
tags: | added: patch |
Thanks for the report. I think there are several different issues at stake here.
First, when creating an user, its main group is creating under the hood by adduser, and we don't show it until the tool is restarted. This is a known problem, but it's not easy to fix properly, at least in a stable release. But this shouldn't be a major bug: why would you need to edit the user's main group right after creating it?
Second, groups creation seems to fail *for any group* in Lucid. But the error I get is about permissions, not "Unknown error". Could you check that it's the case on your machine? This bug seems to be fixed in the current upstream version, though.