Unable to Add Users

[heprox]

I'm running AIX 4330-10 and have recently been unable to add new users in SMIT. When a new new user is created I get the following error:

"3004-698 Error committing change to "%username%": Value is invalid."

I thought this might be a corruption of the etc/passwd file (i.e. blank line, syntax error, corrupt nobody account), or possibly the etc/security/lastlog file (bad characters). I'm presently looking at the etc/security/limits, etc/security/group, and the etc/security/user files btu hey all appear correct. Is there any other possible cause for this error and the inability to create any new users? All of the permissions look correct for the files:

etc/security:
environ -rw-r-----
limits -rw-r-----
passwd -rw-------
user -rw-r-----

etc/
passwd -rw-r--r--
group -rw-r--r--

Any ideas?

 

[AIXSPadmin]

Try recreating the lastlog file.

 

[heprox]

I've renamed my existing lastlog file and created a blank file named "lastlog" to no avail. Are you proposing that I go through and actually re-type the entire file?

 

[sunnytiger]

Two way:
1: recreate /etc/security/lastlog
# chmod 666 /etc/security/lastlog
if works, you must apply new patch on bos.rte.security, I think.

2: # usrck -n all (check not fix)
If errors, backup /etc/security, run
# usrck -y all (fix)

 

[damir]

how much letters in username?

 

[Yegolev]

the "bad value" error is probably the biggest clue. i would guess you are now using illegal chars or too many or some such.

that %username% looks odd, perhaps you are using MicroSoft Fingers v8.2? =) IBM Certified -- AIX 4.3 Obfuscation

 

[heprox]

The username that created the problem was "rfgers". I just added the %username% to represent any user in general. It does not matter what username I attempt to create presently, they all fail. I'm going to attempt to re-create the lastlog file in vi.

 

[heprox]

So far I've re-created the lastlog files by renaming the original, and making a blank "lastlog" file. I'm going to try actually making a completely new one with the original entries. What should the permissions be on the etc/security directory, as well as the actual lastlog file?

 

[Boria]

Hello Helpox,
/etc/security has permitions drwxr-x---
lastlog -rw-r-----
Boris

 

[heprox]

I changed the permissions accordingly and still get the following error when addind the test user "test3". I'm pretty sure I have some type of corruption in the /etc directory. Any opinions on using usrck to locate and correct the problem?

3004-698 Error committing changes to "test3" : Value is invalid.

 

[ggauthier]

What happens when you type:
mkuser test3
from the shell prompt? Is that successful?

-gg

 

[heprox]

Same thing:

3004-698 Error committing changes to "test3" : Value is invalid.

Totally perplexed..., I'm trying to backtrack the error code it is giving.

 

[johndrake]

Hello,

I'm having the same problem. The backup admin was
able to add two users. When he tried adding the third user,
the same exact thing happens. The one thing that I did
notice was that the / directory was at 100%. I increased
the size of the filesystem but that did not help. I had
thought that maybe their is a limitation to the number
of users, so I deleted about 15, that did not help. I
created a new lastlog file, that did not help. I can't
find much info on this 3004-698 Error, either. My last
resort is try and reboot the machine, it might be that
something is in a weird state.

-Joe

 

[johndrake]

Hi,

I got mine to work. I looked at the /etc/passwd file
and the last line was not complete for a previous user
that was added. I blew away the last line and I tried to
recreate the user, and it worked. So, I think, that possibly
one of the filesystems that the "mkuser" command uses is
corrupted. I think that this all goes back to the / filesystem being maxed out, in my case.

Hope this helps,

-Joe

 

[heprox]

I couldn't find anything wrong with the passwd file, all of the entries look good. Which file system are you talking about? /usr or /etc? I ran the usrck -n ALL command and got the following:

3001-664 The account for user daemon has expired.
3001-664 The account for user bin has expired.
3001-664 The account for user sys has expired.
3001-664 The account for user nobody has expired.
3001-664 The account for user lpd has expired.
3001-612 User imnadm has a non-existent
or inaccessible home directory /home/imnadm.

...from what I can tell I have several accounts that have expired, but they are mostly system accounts.

 

[johndrake]

Hi,

In my case it was the root filesystem (/) that was at
100%. Here are the filesystems that are impacted by the
mkuser command:

/usr/bin/mkuser Contains the mkuser command.

/usr/lib/security/mkuser.default Contains the default values for new users.

/etc/passwd Contains the basic attributes of users.

/etc/security/user Contains the extended attributes of users.

/etc/security/user.roles Contains the administrative role attributes of users.

/etc/security/passwd Contains password information.

/etc/security/limits Defines resource quotas and limits for each user.

/etc/security/environ Contains the environment attributes of users.

/etc/group Contains the basic attributes of groups.

/etc/security/group Contains the extended attributes of groups.

/etc/security/.ids Contains standard and administrative user IDs and group IDs.

Try checking all of them to make sure that they are not corrupt. In my case, I had the following line in the /etc/passwd file:

jinscoe:!:216:207:J:/home/jinscoe:/usr/bin/ks

I noticed that "/usr/bin/ks" was not complete, so I completely deleted that line. Now you could also have
a control character in one of the files that is causing this to happen. If it is a control file, then you can't
see it if you "vi" the file. You might have to have to
get an octal dump of the file and view it that way. For
example:

od -c /etc/passwd > junk

Try checking out the files listed above.

-Joe

 

[bi]

Don't worry about those system accounts having expired.

johndrake is talking about the root file system (/), of which /etc is a directory. have you recently filled up your root filesystem (/)? If if was filled or almost filled when you created your last user, the command couldn't finish writing to /etc/passwd file, which is probably what happened to johndrake.

 

[heprox]

I have looked at all of the files mentioned, they all seem fine. The file system has plenty of space present, this server hasn't even gone into production yet. There is an app that creates certain users va script, I'm wondering if this may have caused problems. Could anyone tell me the necessary permissions for the following files:

usr/bin/mkuser

/usr/lib/security/mkuser.default

/etc/passwd

/etc/security/user

/etc/security/user.roles

/etc/security/passwd

/etc/security/limits

/etc/security/environ

/etc/group

/etc/security/group

/etc/security/.ids

 

[johndrake]

Hi,

I have the file permissions for you below. See if you
can add a group via smitty. I only say this because once
I changes a path variable and smitty was screwed up.

Here is the path in the file /etc/security/.profile:

PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:.

Here are the owners/permissions that you requested:

-rw-r----- 1 root security 164 Dec 18 2000 mkuser.default
-rw-r----- 1 root security 164 Dec 18 2000 /usr/lib/security/mkuser.default
-rw-r--r-- 1 root security 10358 Jan 8 16:38 /etc/passwd
-rw-r----- 1 root security 14607 Jan 8 16:18 user
-rw------- 1 root security 17656 Jan 8 16:38 /etc/security/passwd
-rw-r----- 1 root security 1361 Jan 8 12:20 /etc/security/limits
-rw-r----- 1 root security 60 Feb 13 2001 /etc/security/environ
-rw-r----- 1 root security 3945 Jan 8 16:16 /etc/security/group
-rw------- 1 root security 13 Jan 8 16:17 /etc/security/.ids

-Joe

 

[heprox]

Johndrake,

Thanks for your help. I fixed it last night by following your advice and doing an octal dump and examining the file. There was a whole string of crap at the bottom that I deleted; after that user creation worked fine. IBM recommends using the CDE or vedit versus vi in AIX for this very reason, apparently AIX doesn't like the buffer arrangement that vi uses.... Thanks again.