Bug #666555 ""users and groups” home directory change does not “...” : Bugs : gnome-system-tools package : Ubuntu

Revision history for this message

Milan Bouchet-Valat (nalimilan) wrote on 2010-10-27:

#1

Interesting... Indeed, doesn't seem to be a duplicate of bug 659758, which is only about newly created users (and about which I know the root cause).

Please follow the instructions at :
https://wiki.ubuntu.com/DebuggingGnomeSystemTools#For%20Users%20[users-admin]
and attach the information here. Thanks!

Changed in gnome-system-tools (Ubuntu):
status:	New → Incomplete
importance:	Undecided → Medium

Revision history for this message

RnSC (webclark) wrote on 2010-10-27: Re: [Bug 666555] Re: "users and groups" home directory change does not "take"

#2

Will try to do tonight, may be a few days. I have fiddled with 10.04 before also. This is at least the second, perhaps the third or fourth clean install with this behavior. I just shrugged it off that I must have done something wrong in the past, but this time I was prepared and very meticulous, and verified. Again, I will do what you asked soon.
--Ray

---- Milan Bouchet-Valat <email address hidden> wrote:
> Interesting... Indeed, doesn't seem to be a duplicate of bug 659758,
> which is only about newly created users (and about which I know the root
> cause).
>
> Please follow the instructions at :
> https://wiki.ubuntu.com/DebuggingGnomeSystemTools#For%20Users%20[users-admin]
> and attach the information here. Thanks!
>
> ** Changed in: gnome-system-tools (Ubuntu)
> Status: New => Incomplete
>
> ** Changed in: gnome-system-tools (Ubuntu)
> Importance: Undecided => Medium
>
> --
> "users and groups" home directory change does not "take"
> https://bugs.launchpad.net/bugs/666555
> You received this bug notification because you are a direct subscriber
> of the bug.

Revision history for this message

RnSC (webclark) wrote on 2010-11-14:

#3

stb-users.log Edit (9.4 KiB, text/plain)

Sorry for the delay. Boy, that was easy. I did the following:

Started the two processes in the two consoles, per the directions.
mkdir /newdir
Selected the "administ" account
Pressed the [Advanced Settings] button
Selected the "Advanced" tab
Change the home directory from "/lhome/administ" to "/newdir/administ"
Pressed "OK"
Pressed "Closed"

Wrote this note, attached the two files. Note that one is zero length. stb-users.log is attached. A follow-on comment will include the zero length file, for whatever it is worth.

Revision history for this message

RnSC (webclark) wrote on 2010-11-14:

#4

users-admin.log is zero length. There is no mistake here.

Revision history for this message

RnSC (webclark) wrote on 2010-11-14:

#5

It will not let me upload an empty file, it removed it and posted the comment without an attachement. (Probably not news to you, but thought I should clearly document what is going on here). Thanks.

Revision history for this message

Milan Bouchet-Valat (nalimilan) wrote on 2010-11-14:

#6

No need to attach the empty file, obviously it's enough to say it doesn't contain anything... ;-)

Nothing weird seems to be done by the backends, so the problem may come from a configuration issue on your system. Could you paste here the output of:
sudo /usr/sbin/usermod -d /newdir/administ -g 1000 -l administ -s /bin/bash -u 1000 administ

Revision history for this message

RnSC (webclark) wrote on 2010-11-14:

#7

sudo /usr/sbin/usermod -d /newdir/administ -g 1000 -l administ -s /bin/bash -u 1000 administ > 2010-11-14-1455.log 2>&1

Nothing comes out on stdout, the following comes out on stderr:

usermod: user administ is currently logged in

So perhaps that is the problem. It did work in 0810, even when I was logged on.

I do admit that there a strange situation here, and one has to know what they are doing or there will be unpredictable results.

I am not in a position to check it on another account right now, I hope to be in a few days. I will post results at that time.

Revision history for this message

Milan Bouchet-Valat (nalimilan) wrote on 2010-12-16:

#8

usermod always fails when trying to change the home for an active user. This is very reasonable since many files are likely to be open, so moving/removing them will fail.

I've changed users-admin upstream to disable the home dir field and show and explanation notice in that case. This will be present in the gnome-sytem-tools 2.91.1, thus in Natty. Thanks for the report!

Changed in gnome-system-tools (Ubuntu):
status:	Incomplete → Triaged
Changed in gst:
status:	New → Fix Released

Revision history for this message

RnSC (webclark) wrote on 2011-01-02:

#9

Download full text (5.3 KiB)

Following up, new system. Gave up on getting 10.04 video to work on my system (another story), switched to 10.10.

Created a user named "bugta", user 1001, group 1001.

Tried to use System / Administration / Users and Groups to change the home directory of bugta from /home to /lhome. lhome pre-existed, but did NOT have a directory in it called bugta.

After prompting me, it created /lhome/bugta and copied the contents of /home/bugta into it. However it did not update /etc/passwd. To be explicit, the bugta line in /etc/passwd still had /home/bugta as the user's home directory.

Repeated the test described in my 2010-11-14 post exactly, except for changing the user. The line below was copy pasted from what I typed:

/usr/sbin/usermod -d /lhome/bugta -g 1001 -l bugta -s /bin/bash -u 1001 bugta >2011.01.02-1709.log 2>&1

/etc/passwd was modified to make the home directory /lhome/bugta.

I believe that this represents a bug in 10.10. The System / Administration / users and groups dialog does not modify /etc/passwd even when the user being changed is not logged on.
---

With regard to modifying the user who is logged on, I believe that *somehow* this should work. My need for it *is* driven by how I build my systems, which will explain below, but that is immaterial and I do not want to cloud my message. It suggest the following:

The issue would arise any time userid, groupid, home directory is changed for an active user. If the user is *not* in the user trying to make the change, I suggest that the program refuse to make the change, and specify that the user must log off and all processes running under that user ID must exit before the change can be made. Note that in obscure cases that this may still not be sufficient, as any process could have information about the target user ID in private memory. The only 100% safe thing to do is to reboot. The user could be warned and given a choice - log off or reboot.

If the user is the one running "Users and Groups", I suggest that a dialog offer the choices of aborting the change, or continuing with a unavoidable and immediate system restart without further warning afterward to ensure consistency for running processes related to that user ID (To avoid giving the user the opportunity to ctrl-alt-backspace for example out of the reboot).

I do not like the idea of having to reboot the system for a change, but this is a very unusual situation.

---
Why I need this (And a little bit of a soap box):

In general, my user home directories are on a file server. This is /home, created by an auto mount map or direct nfs mount. I create the accounts on each machine to avoid the complexity of LDAP at the cost of 15 minutes work when I rebuild.

The account created during installation I use as a local administrator account (naming it administ), which is functional and whole even if my network or the file server with the home directories is non-functional. But Ubuntu gives me no choice but to create it in /home! So I let it create it, then need to move it to *somewhere else* before I can make /home refer to my server and activate my other accounts. I choose /lhome (local home).

I use the Ubuntu Syst...

Following up, new system.  Gave up on getting 10.04 video to work on my system (another story), switched to 10.10.

Created a user named "bugta", user 1001, group 1001.

Tried to use System / Administration / Users and Groups to change the home directory of bugta from /home to /lhome.  lhome pre-existed, but did NOT have a directory in it called bugta.

After prompting me, it created /lhome/bugta and copied the contents of /home/bugta into it.  However it did not update /etc/passwd.  To be explicit, the bugta line in /etc/passwd still had /home/bugta as the user's home directory.

Repeated the test described in my 2010-11-14 post exactly, except for changing the user.  The line below was copy pasted from what I typed:

/usr/sbin/usermod -d /lhome/bugta -g 1001 -l bugta -s /bin/bash -u 1001 bugta >2011.01.02-1709.log 2>&1

/etc/passwd was modified to make the home directory /lhome/bugta.

I believe that this represents a bug in 10.10.  The System / Administration / users and groups dialog does not modify /etc/passwd even when the user being changed is not logged on.
---

With regard to modifying the user who is logged on, I believe that *somehow* this should work.  My need for it *is* driven by how I build my systems, which will explain below, but that is immaterial and I do not want to cloud my message.  It suggest the following:

The issue would arise any time userid, groupid, home directory is changed for an active user.  If the user is *not* in the user trying to make the change, I suggest that the program refuse to make the change, and specify that the user must log off and all processes running under that user ID must exit before the change can be made.  Note that in obscure cases that this may still not be sufficient, as any process could have information about the target user ID in private memory.  The only 100% safe thing to do is to reboot.  The user could be warned and given a choice - log off or reboot.

If the user is the one running "Users and Groups", I suggest that a dialog offer the choices of aborting the change, or continuing with a unavoidable and immediate system restart without further warning afterward to ensure consistency for running processes related to that user ID (To avoid giving the user the opportunity to ctrl-alt-backspace for example out of the reboot).

I do not like the idea of having to reboot the system for a change, but this is a very unusual situation.

---
Why I need this (And a little bit of a soap box):

In general, my user home directories are on a file server.  This is /home, created by an auto mount map or direct nfs mount.  I create the accounts on each machine to avoid the complexity of LDAP at the cost of 15 minutes work when I rebuild.

The account created during installation I use as a local administrator account (naming it administ), which is functional and whole even if my network or the file server with the home directories is non-functional.  But Ubuntu gives me no choice but to create it in /home!  So I let it create it, then need to move it to *somewhere else* before I can make /home refer to my server and activate my other accounts.  I choose /lhome (local home).

I use the Ubuntu System / administration / users and groups dialog to change the home directory (This *is* the mainstream Ubuntu mechanism).  I guess I *could* create another administrator account, then change it from there, then delete the second account.  But I feel that somehow the system should deal with this situation, not block out a valid change.

Regarding using the dialog vs. the command line stuff, I "grew up" editing UNIX configuration files such as /etc/passwd and /etc/group, creating home directories with mkdir.  "man" explained the actions of each command, and each configuration file.  Life was simple and transparent.  Today a plethora of dialog boxes provide magical access to who-knows-what underlying mechanisms, and maintaining coherence of who-knows-what interdependencies.  I am afraid to change anything the easy way, and instead use the provided dialogs.  I fear that Linux is moving toward Windows, where everything is opaque and based on hidden magic, vs. UNIX where everything was transparent and intuitive to the most casual observer.  Because the dialogs are not well documented as to what they do, one cannot manage the system the old way because you have no way of knowing what to do any more.

Hiding the underlying mechanisms is a good architectural principle, but I would prefer the simple transparent system with those clearly identified as the system interfaces, perhaps with nice helpful graphical applications whose stated role is to manipulate those system interfaces in well defined and documented (transparent) ways to make the system nice for those who cannot type.  I like to be in control and secure that I can make the system work.  Otherwise I might as well buy Windows, where everything is easy, confusing, seems to encounter unanticipated situations and malfunctions or doesn't work on a regular basis, and you can't figure out why or fix it!  Please don't take offense, notice the direction we are going and think about it!  Making it clear what you are doing is just as important as doing it.  It would only take a page or two of text to outline what the "Users and Groups" dialog is doing!

Anyway, thanks for your work.  I am grateful for a system other than Windows, much less a better system.

Revision history for this message

Milan Bouchet-Valat (nalimilan) wrote on 2011-01-03:

#10

Download full text (7.2 KiB)

Le dimanche 02 janvier 2011 à 22:58 +0000, RnSC a écrit :
> Following up, new system. Gave up on getting 10.04 video to work on my
> system (another story), switched to 10.10.
>
> Created a user named "bugta", user 1001, group 1001.
>
> Tried to use System / Administration / Users and Groups to change the
> home directory of bugta from /home to /lhome. lhome pre-existed, but
> did NOT have a directory in it called bugta.
>
> After prompting me, it created /lhome/bugta and copied the contents of
> /home/bugta into it. However it did not update /etc/passwd. To be
> explicit, the bugta line in /etc/passwd still had /home/bugta as the
> user's home directory.
>
> Repeated the test described in my 2010-11-14 post exactly, except for
> changing the user. The line below was copy pasted from what I typed:
>
> /usr/sbin/usermod -d /lhome/bugta -g 1001 -l bugta -s /bin/bash -u 1001
> bugta >2011.01.02-1709.log 2>&1
>
> /etc/passwd was modified to make the home directory /lhome/bugta.
>
> I believe that this represents a bug in 10.10. The System / Administration / users and groups dialog does not modify /etc/passwd even when the user being changed is not logged on.
So please follow instructions from
https://wiki.ubuntu.com/DebuggingGnomeSystemTools so that we can check
if/why the correct commands are successfully run.

> ---
>
> With regard to modifying the user who is logged on, I believe that
> *somehow* this should work. My need for it *is* driven by how I build
> my systems, which will explain below, but that is immaterial and I do
> not want to cloud my message. It suggest the following:
>
> The issue would arise any time userid, groupid, home directory is
> changed for an active user. If the user is *not* in the user trying to
> make the change, I suggest that the program refuse to make the change,
> and specify that the user must log off and all processes running under
> that user ID must exit before the change can be made. Note that in
> obscure cases that this may still not be sufficient, as any process
> could have information about the target user ID in private memory. The
> only 100% safe thing to do is to reboot. The user could be warned and
> given a choice - log off or reboot.
>
> If the user is the one running "Users and Groups", I suggest that a
> dialog offer the choices of aborting the change, or continuing with a
> unavoidable and immediate system restart without further warning
> afterward to ensure consistency for running processes related to that
> user ID (To avoid giving the user the opportunity to ctrl-alt-backspace
> for example out of the reboot).
>
> I do not like the idea of having to reboot the system for a change, but
> this is a very unusual situation.
Upstream users-admin now prevents changing home dir for active users. I don't
think we should require a reboot because that's not likely to be useful. usermod
currently fails because it checks whether the user is logged in - if
only a few processes are still running, they are not likely to block
changing the home dir. And killing them would be a mess given how the
gnome-system-tools are designed.

> ---
> Why I need this (And a little bit of a soap b...

Le dimanche 02 janvier 2011 à 22:58 +0000, RnSC a écrit :
> Following up, new system.  Gave up on getting 10.04 video to work on my
> system (another story), switched to 10.10.
> 
> Created a user named "bugta", user 1001, group 1001.
> 
> Tried to use System / Administration / Users and Groups to change the
> home directory of bugta from /home to /lhome.  lhome pre-existed, but
> did NOT have a directory in it called bugta.
> 
> After prompting me, it created /lhome/bugta and copied the contents of
> /home/bugta into it.  However it did not update /etc/passwd.  To be
> explicit, the bugta line in /etc/passwd still had /home/bugta as the
> user's home directory.
> 
> Repeated the test described in my 2010-11-14 post exactly, except for
> changing the user.  The line below was copy pasted from what I typed:
> 
> /usr/sbin/usermod -d /lhome/bugta -g 1001 -l bugta -s /bin/bash -u 1001
> bugta >2011.01.02-1709.log 2>&1
> 
> /etc/passwd was modified to make the home directory /lhome/bugta.
> 
> I believe that this represents a bug in 10.10.  The System / Administration / users and groups dialog does not modify /etc/passwd even when the user being changed is not logged on.
So please follow instructions from
https://wiki.ubuntu.com/DebuggingGnomeSystemTools so that we can check
if/why the correct commands are successfully run.

> ---
> 
> With regard to modifying the user who is logged on, I believe that
> *somehow* this should work.  My need for it *is* driven by how I build
> my systems, which will explain below, but that is immaterial and I do
> not want to cloud my message.  It suggest the following:
> 
> The issue would arise any time userid, groupid, home directory is
> changed for an active user.  If the user is *not* in the user trying to
> make the change, I suggest that the program refuse to make the change,
> and specify that the user must log off and all processes running under
> that user ID must exit before the change can be made.  Note that in
> obscure cases that this may still not be sufficient, as any process
> could have information about the target user ID in private memory.  The
> only 100% safe thing to do is to reboot.  The user could be warned and
> given a choice - log off or reboot.
> 
> If the user is the one running "Users and Groups", I suggest that a
> dialog offer the choices of aborting the change, or continuing with a
> unavoidable and immediate system restart without further warning
> afterward to ensure consistency for running processes related to that
> user ID (To avoid giving the user the opportunity to ctrl-alt-backspace
> for example out of the reboot).
> 
> I do not like the idea of having to reboot the system for a change, but
> this is a very unusual situation.
Upstream users-admin now prevents changing home dir for active users. I don't
think we should require a reboot because that's not likely to be useful. usermod
currently fails because it checks whether the user is logged in - if
only a few processes are still running, they are not likely to block
changing the home dir. And killing them would be a mess given how the
gnome-system-tools are designed.

> ---
> Why I need this (And a little bit of a soap box):
> 
> In general, my user home directories are on a file server.  This is
> /home, created by an auto mount map or direct nfs mount.  I create the
> accounts on each machine to avoid the complexity of LDAP at the cost of
> 15 minutes work when I rebuild.
> 
> The account created during installation I use as a local administrator
> account (naming it administ), which is functional and whole even if my
> network or the file server with the home directories is non-functional.
> But Ubuntu gives me no choice but to create it in /home!  So I let it
> create it, then need to move it to *somewhere else* before I can make
> /home refer to my server and activate my other accounts.  I choose
> /lhome (local home).
> 
> I use the Ubuntu System / administration / users and groups dialog to
> change the home directory (This *is* the mainstream Ubuntu mechanism).
> I guess I *could* create another administrator account, then change it
> from there, then delete the second account.  But I feel that somehow the
> system should deal with this situation, not block out a valid change.
usermod refuses to change the home dir of active users, based on the rationale
you suggested above. If you think there should be an override option, file
a bug against usermod. But we should make sure this would theoretically
work. And anyway doing so brings the risk of being locked out of the
only admin account in case something goes wrong - so that's not
something to recommend.

> Regarding using the dialog vs. the command line stuff, I "grew up"
> editing UNIX configuration files such as /etc/passwd and /etc/group,
> creating home directories with mkdir.  "man" explained the actions of
> each command, and each configuration file.  Life was simple and
> transparent.  Today a plethora of dialog boxes provide magical access to
> who-knows-what underlying mechanisms, and maintaining coherence of who-
> knows-what interdependencies.  I am afraid to change anything the easy
> way, and instead use the provided dialogs.  I fear that Linux is moving
> toward Windows, where everything is opaque and based on hidden magic,
> vs. UNIX where everything was transparent and intuitive to the most
> casual observer.  Because the dialogs are not well documented as to what
> they do, one cannot manage the system the old way because you have no
> way of knowing what to do any more.
> 
> Hiding the underlying mechanisms is a good architectural principle, but
> I would prefer the simple transparent system with those clearly
> identified as the system interfaces, perhaps with nice helpful graphical
> applications whose stated role is to manipulate those system interfaces
> in well defined and documented (transparent) ways to make the system
> nice for those who cannot type.  I like to be in control and secure that
> I can make the system work.  Otherwise I might as well buy Windows,
> where everything is easy, confusing, seems to encounter unanticipated
> situations and malfunctions or doesn't work on a regular basis, and you
> can't figure out why or fix it!  Please don't take offense, notice the
> direction we are going and think about it!  Making it clear what you are
> doing is just as important as doing it.  It would only take a page or
> two of text to outline what the "Users and Groups" dialog is doing!
If you know how to use commandline tools and you prefer them, please use them!
users-admin is made to ease the life of people that don't know or like command
line. It wouldn't make sense to expose all the details of the commands
that are run to people that don't want to use them (even if we should
have a nicer error reporting, obviously). And users-admin isn't even
intended for administrators: it's more of a tool for desktop users,
which supports advanced settings as a bonus (and because we lack a
proper tool for admins).

But I don't think dialogs are really obscure about what they do: if you
know how users and groups work on Unix, most settings are transparent.
It's just that the failure of the commands isn't reported correctly.
Sadly, it's nearly impossible to report errors with the current
architecture of the gnome-system-tools, so the best I can do is prevent
common errors from happening.

Revision history for this message

RnSC (webclark) wrote on 2011-01-16:

#11

"script" capture of console1 and console2, stb-users.log, users-admin.log Edit (20.0 KiB, application/x-tar)

I apologize for not attaching the files the second time.

Now I seem to have a bigger problem, it will not let me add an account. I have been continuing to configure my system, but I don't know (obviously) what I did wrong. In general I have edited various configuration files and merged them from a previous Ubuntu system. I have gone back and checked the file owners and modes from a backup I created just after installation.

Would you please help me to sort this out? Then I will get back to the original problem, if it still exists.

I have followed the procedure, adding using "script" to capture what I typed. Files attached in a tar file. I:

Started script on Console 1 capturing in console1.log
Started script on Console 2 capturing in console2.log

Typed:
sudo killall /usr/bin/perl; sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig -v &> ~/stb-users.log
in console 1 per web page, and as captured in console1.log
Entered by password.

Typed:
users-admin &> ~/users-admin.log
in console 2 per web page, and as captured in console2.log
Clicked "Add"
"Create a new user" dialog appeared
Provided Name and Username, both "bugta"
Dialog popped up: "Tye configuration cannot be saved. You are not allowed to modify the system configuration"
Exited user creation tool.
Exited script shell on console2
Exited script shell on console1

I was logged in as "administ", which when I run "id" prints:
uid=1000(administ) gid=1000(administ) groups=1000(administ),4(adm),20(dialout),24(cdrom),46(plugdev),111(lpadmin),119(admin),122(sambashare),123(vboxusers)

grep administ /etc/group prints:
admin:x:119:administ,ray,rnsc,rnscadm

ls -l passwd shadow group gshadow
-rw-r--r-- 1 root root 1662 2011-01-16 14:19 group
-rw-r----- 1 root shadow 1441 2011-01-16 14:19 gshadow
-rw-r--r-- 1 root root 2712 2011-01-16 14:19 passwd
-rw-r----- 1 root shadow 2874 2011-01-16 14:19 shadow

Revision history for this message

Milan Bouchet-Valat (nalimilan) wrote on 2011-01-16:

#12

Thanks! The interesting part is:
file_run_full_failed::Command [/usr/sbin/adduser --gecos --disabled-password bugta] failed.
Since the user wasn't created, everything else fails.

What do you get when you run:
sudo /usr/sbin/adduser --gecos --disabled-password bugta
in a terminal? You'll get the reason why users-admin fails.

But this is a different bug, and it's likely triggered by a broken system...

Revision history for this message

RnSC (webclark) wrote on 2011-01-17:

#13

Per your request / suggestion:

sudo /usr/sbin/adduser --gecos --disabled-password bugta
[sudo] password for administ:
Adding user `bugta' ...
Adding new group `bugta' (1001) ...
Adding new user `bugta' (1001) with group `bugta' ...
Creating home directory `/home/bugta' ...
Stopped: Couldn't create home directory `/home/bugta': No such file or directory.

Removing directory `/home/bugta' ...
Removing user `bugta' ...
Removing group `bugta' ...
groupdel: group 'bugta' does not exist
adduser: `groupdel bugta' returned error code 6. Exiting.
administ@bagend:~/CannotAdd$ exit
exit
Script done, file is 2011.01.16.2004.log

Ah, /home is an automount map (auto.home). Thank you for showing me how to get to the bottom of my problem, and so quickly. I would think that having /home be an automount map would be a common configuration. Is there a way for you to detect this condition so that it can be handled intelligently?

I have an action now to disable my automount map, make a user in /home, then try to move it to /lhome when they are not logged in to see if it works. Cannot do tonight. Thank you for your patience.

As far as a mis-configured system, I only changed:

/etc/inetd.conf
/etc/cups/cups-pdf.conf
/etc/auto.home
/etc/auto.master
/etc/mdadm/mdadm.conf
/etc/samba/smb.conf
/etc/fstab
/etc/default/grub
/etc/default/console-setup
/etc/exports

(And installed to corresponding packages that they support) as required). I should have recognized that one cannot create a directory in an automount map.

I guess my suggestion at this point would be to try to put out a better message... but you mentioned earlier that you cannot report errors ... but there was the recent dialog box I got "The configuration cannot be saved: You are not allowed to modify the system configuration." That got through. Could you not capture the output I got (below) and stick it in a dialog box? Also, the message about "The configuration cannot be saved" is misleading. It is not that something could not be saved, it is that the home directory could not be created. But then I know literally nothing about gnome.

Thank you for your help. I will get to the above verification that things work when home is not an automount and report.

--Ray

Per your request / suggestion:

sudo /usr/sbin/adduser --gecos --disabled-password bugta
[sudo] password for administ: 
Adding user `bugta' ...
Adding new group `bugta' (1001) ...
Adding new user `bugta' (1001) with group `bugta' ...
Creating home directory `/home/bugta' ...
Stopped: Couldn't create home directory `/home/bugta': No such file or directory.

Removing directory `/home/bugta' ...
Removing user `bugta' ...
Removing group `bugta' ...
groupdel: group 'bugta' does not exist
adduser: `groupdel bugta' returned error code 6. Exiting.
administ@bagend:~/CannotAdd$ exit
exit
Script done, file is 2011.01.16.2004.log

Ah, /home is an automount map (auto.home).  Thank you for showing me how to get to the bottom of my problem, and so quickly.  I would think that having /home be an automount map would be a common configuration.  Is there a way for you to detect this condition so that it can be handled intelligently?

I have an action now to disable my automount map, make a user in /home, then try to move it to /lhome when they are not logged in to see if it works.  Cannot do tonight.  Thank you for your patience.

As far as a mis-configured system, I only changed:

/etc/inetd.conf
/etc/cups/cups-pdf.conf
/etc/auto.home
/etc/auto.master
/etc/mdadm/mdadm.conf
/etc/samba/smb.conf
/etc/fstab
/etc/default/grub
/etc/default/console-setup
/etc/exports

(And installed to corresponding packages that they support) as required).  I should have recognized that one cannot create a directory in an automount map.

I guess my suggestion at this point would be to try to put out a better message... but you mentioned earlier that you cannot report errors ... but there was the recent dialog box I got "The configuration cannot be saved: You are not allowed to modify the system configuration."  That got through.  Could you not capture the output I got (below) and stick it in a dialog box?  Also, the message about "The configuration cannot be saved" is misleading.  It is not that something could not be saved, it is that the home directory could not be created.  But then I know literally nothing about gnome.

Thank you for your help.  I will get to the above verification that things work when home is not an automount and report.

--Ray

Revision history for this message

Milan Bouchet-Valat (nalimilan) wrote on 2011-01-17:

#14

So your system isn't broken, it's just that adduser doesn't interact well with automount. I'm not sure why this doesn't work (i.e. why /home isn't mounted when adduser tries to access it), nor if it should work. But that's not a bug in users-admin. You could report a bug against adduser in Debian (which develops it), but I don't understand why adduser would need to be aware of the fact that /home is an automount point: are they supposed to be transparent to applications?

Ideally we should report the error in the dialog, but as I said that wouldn't be easy, and as users-admin are deprecated, we'd better spend our time improving the new tools that will be used in new releases.

Changed in gnome-system-tools (Ubuntu):
status:	Triaged → Invalid

Ubuntu
gnome-system-tools package

"users and groups" home directory change does not "take"

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Affects		Status	Importance	Assigned to	Milestone
	GST	Fix Released	Undecided	Unassigned
	gnome-system-tools (Ubuntu)	Invalid	Medium	Unassigned

Ubuntugnome-system-tools package

"users and groups" home directory change does not "take"

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
gnome-system-tools package