Contents of /etc/skel not copied

SteveK1979 · 09-09-2007, 07:09 PM

Hi,

I seem to be having an issue copying the contents of /etc/skel to a new user's home directory.

My user account has the "Primary Adminsitrator" role on a Solaris 9 system.

I'm able to create a new user without any issues, however specifying the -k /etc/skel option seems to silently fail regardless.

I'm issueing the command as follows:

Code:

$ pfexec /usr/sbin/useradd -c "User Name" -s /bin/ksh -d /home/<username> -m -k /etc/skel -u 1002 -g user -G users <username>

It executes without error and creates the user as specified etc., but the contents of /etc/skel are not copied to the new user's home directory. It doesn't seem to make any difference if I specify the home directory as /home/<username> or /export/home/<username>.

The home directory is mounted via the automounter using the auto_home file. It already exists, and according to the man page for useradd, it needs to be writeable by the user's primary group, which it is.

Anybody see this problem before? Any ideas? Is it a known bug?

Cheers,
Steve

jlliagre · 09-10-2007, 04:24 AM

It works for me:

Code:

bestouan:~ $ ls -la /export/home/removeme
/export/home/removeme: No such file or directory
bestouan:~ $ pfexec /usr/sbin/useradd -c removeme -s /bin/ksh -d /export/home/removeme -m -k /etc/skel -u 1002 -g nogroup -G nogroup removeme
64 blocks
bestouan:~ $ ls -la /export/home/removeme
total 12
drwxr-xr-x   2 removeme nogroup      512 Sep 10 11:20 .
drwxr-xr-x   4 root     root         512 Sep 10 11:20 ..
-rw-r--r--   1 removeme nogroup      144 Sep 10 11:20 .profile
-rw-r--r--   1 removeme nogroup      136 Sep 10 11:20 local.cshrc
-rw-r--r--   1 removeme nogroup      157 Sep 10 11:20 local.login
-rw-r--r--   1 removeme nogroup      174 Sep 10 11:20 local.profile

SteveK1979 · 09-24-2007, 06:35 PM

Hi jlliagre

Quote:

Originally Posted by jlliagre

It works for me:

Code:

bestouan:~ $ ls -la /export/home/removeme
/export/home/removeme: No such file or directory
bestouan:~ $ pfexec /usr/sbin/useradd -c removeme -s /bin/ksh -d /export/home/removeme -m -k /etc/skel -u 1002 -g nogroup -G nogroup removeme
64 blocks
bestouan:~ $ ls -la /export/home/removeme
total 12
drwxr-xr-x   2 removeme nogroup      512 Sep 10 11:20 .
drwxr-xr-x   4 root     root         512 Sep 10 11:20 ..
-rw-r--r--   1 removeme nogroup      144 Sep 10 11:20 .profile
-rw-r--r--   1 removeme nogroup      136 Sep 10 11:20 local.cshrc
-rw-r--r--   1 removeme nogroup      157 Sep 10 11:20 local.login
-rw-r--r--   1 removeme nogroup      174 Sep 10 11:20 local.profile

I've just tried this myself and if I copy your command above, with a different UID, I get the following:

Code:

$ pfexec /usr/sbin/useradd -c removeme -s /bin/ksh -d /export/home/removeme -m -k /etc/skel -u 1003 -g nogroup -G nogroup removeme
UX: /usr/sbin/useradd: ERROR: nogroup is the primary group name.  Choose another

So I re-ran the command as follows:

Code:

$ pfexec /usr/sbin/useradd -c removeme -s /bin/ksh -d /export/home/removeme -m -k /etc/skel -u 1003 -g nogroup removeme
64 blocks
$ ls -la /export/home/removeme
total 14
drwxr-xr-x   3 removeme nogroup      512 Sep 25 00:27 .
drwxr-xr-x   7 root     root         512 Sep 25 00:27 ..
-rw-r--r--   1 removeme nogroup      144 Sep 25 00:27 .profile
-rw-r--r--   1 removeme nogroup      136 Sep 25 00:27 local.cshrc
-rw-r--r--   1 removeme nogroup      157 Sep 25 00:27 local.login
-rw-r--r--   1 removeme nogroup      174 Sep 25 00:27 local.profile
drwx------   2 removeme nogroup      512 Sep 25 00:27 Mail

and it does appear to have worked! I'm not quite sure what's causing the problem, but I think it must be related to the fact that I had created the user's home directory and assigned group permissions in advance, as that's the biggest difference I can see between what I was trying originally and this method. However, that should work according to the useradd man page.

I still think there is a bug in useradd, but at least I know it does work if the directory isn't created in advance.

Cheers,
Steve

jlliagre · 09-25-2007, 03:56 AM

Quote:

Originally Posted by SteveK1979

I still think there is a bug in useradd, but at least I know it does work if the directory isn't created in advance.

I don't think this can be qualified as a bug. Useradd isn't touching a home directory that already exists which makes sense.

However, the manual page could be improved. The sentence "This directory must already exist." in the "-k" description is certainly ambiguous. I guess you understood it to mean the user's home directory must exists while it really refers to the skeleton directory.

SteveK1979 · 09-25-2007, 08:33 AM

Quote:

Originally Posted by jlliagre

I don't think this can be qualified as a bug. Useradd isn't touching a home directory that already exists which makes sense.

However, the manual page could be improved. The sentence "This directory must already exist." in the "-k" description is certainly ambiguous. I guess you understood it to mean the user's home directory must exists while it really refers to the skeleton directory.

Thanks for the reply - the part I was looking at was actually this section:

Code:

     -m    Create the new user's home directory if  it  does  not
           already  exist.  If  the  directory already exists, it
           must have read,  write,  and  execute  permissions  by
           group, where group is the user's primary group.

So I assumed that if I met these requirements (which I did), useradd would behave exactly as it does when the home directory does not exist in advance. However it appears that useradd doesn't behave the same if the user's home directory already exists.

Cheers,
Steve

jlliagre · 09-25-2007, 11:21 AM

Got it.

From the useradd source code, '-m' flag is ignored if the directory already exists, and '-k' is only processed if the home directory is created by useradd.

This should probably be clarified in the man page.