I reinstalled Solaris on my box and as root created a group called Developer (has gid of 100). I then created a directory called /usr/dev1 and then created a user called dev1 with primary group of 100, Korn shell, /usr/dev1 home and no initial password.

When I logout out of the system and try to log back in as dev1, I'm prompted to change the password, which seems to process OK. At this point, it returns me to the logon screen and I use dev1 with the new password. It begins to log me on, however when it gets to the CDE desktop, I'm able to see a box that is titled "Action Required" and then it immediately logs back out. This is a repeative cycle. I can still log on as root without any problems.

Any suggestions?

Just a wild guess:

Are the permissions correct for the userdir (/usr/dev1).

Question: Why create the dir first and then create the user? Can't adduser (useradd) do this for you.

Just my 2 cents and hope this helps.

__________________

The dead stay dead and the living only wait to join them........

First - check the permissions as Druuna suggested.

Then test the account from another system by using telnet/rlogin/ssh. If that isn't possible, check via su - username. If that doesn't work, then your problem isn't with CDE - look at .profile/.kshrc.

If it does work that way, then your problem is probably with CDE - hard to pinpoint it as Sunsolve doesn't show any error like this (more searching may be required to find another possible solution)

More info found - see if this helps:

from Sunsolve:
At the CDE login (dtlogin) window, you have entered your username and password
correctly.

Dtlogin attempts to log you in (e.g., the background changes, a new Xserver
is started, etc.) but then, for no obvious reason, the login fails in one of the
following ways:

1. It abruptly returns to the dtlogin window.
2. It hangs on the welcome banner screen.
3. It takes 3 or 6 minutes to get into CDE.
4. It takes around 10 minutes to get into CDE.
5. It takes around 20 minutes to get into CDE.
6. It takes around 30 minutes to get into CDE.

System hangs with an hourglass on the welcome banner screen
Telnet to the system, if possible, and check the /var/adm/messages file and
/var/dt/Xerrors file.

This document demonstrates different approaches to troubleshooting this problem.
Follow through the steps below to try and isolate the cause.

1) Look at the startlog and errorlog files in $HOME/.dt

The logs may give clues to the cause of the error.

2) Verify whether there is an error in the global customization of CDE

Since CDE is so customizable, it is possible that changes
that have been done to the global customization area has
confused the login.

The command rm -rf /etc/dt removes all the global customization.
Note: Save the /etc/dt first if the changes are important

3) Verify whether there is an error in the local customization of CDE

Remove everything in the directory $HOME/.dt and the file $HOME/.dtprofile

From a command line login or remote telnet connection, move or remove
the directory $HOME/.dt and the file $HOME/.dtprofile.

These files or directories will be recreated upon the user's next CDE login.

4) Check for errors in the users environment

It is possible to put commands in the user's environment that
confuse the CDE login environment.

To prove that this is not the case, either remove or save the following
file depending on the users shell. If you're not sure, do all of the following:

cd $HOME
rm -f .login .cshrc .profile .kshrc

and remove any customization from /etc/profile that has been added. The online
manual pages for the various shells describe what files are used during a login.

As an alternative, set up a local user on the host and try logging in as that
user. If it works, it's a user issue. If not, it's an environment issue.

5) A Permissions or Access problem

After you have removed the customization that could have occurred
as described in the steps above, attempt to login as the root user.

Since access is unrestricted on any local file system, it will prove if the
problem is a permissions problem or something else.

Because logging in as root only checks permissions on a local file system,
verify whether the /usr/dt or /usr/openwin directories are local file systems.

If these directories are NFS mounted from another machine, ensure that they
are mounted and shared with root access.

You can do this on Solaris[TM] 2.x Operating Environment with the command:

share -F nfs -o root=machine /usr/dt

Change the machine and the directory to export to be appropriate for your
environment. Refer to the online manual page for share_nfs for further details.

Note: The reason for taking 30 minutes to get into CDE can be caused by NFS
mounting problems.

6) Incorrect tooltalk daemon


It is a possibility, although unlikely, that the CDE installation failed.
If this did occur, then the old OpenWindows tooltalk daemon may still be
being used.

Check that the latest version is installed by looking at the file
/etc/inetd.conf and look for a line similar to below:

For 2.5.1 -
100083/1 stream rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbserverd

For 2.6 and above -
100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbserverd

The important point is the path to /usr/dt/bin/rpc.ttdbserverd

7) Corrupted tooltalk database

The tooltalk database that is used by CDE and openwin may sometimes get corrupted.
This can cause CDE to hang.

Installing the latest tooltalk patch and then cleaning the tooltalk database can
take care of the problem.

Note: 6 and 7 above can be the reason for CDE to hang for approximately 10
minutes or hanging on the welcome banner screen with an hourglass.

8) Is or has the disk space reached 100 % in any partition?

In some circumstances, if a file system reaches 100% full the tooltalk
databases can get corrupted. The tooltalk databases, which are located
at each local mount point and are in directories with the name TT_DB, will
need to be cleaned up.

Check SRDB 12729 - "How to clean out the ToolTalk[TM] Databases" for detailed
information on how to achieve this.

A similar effect can be seen if a users quota is exceeded.

9) Check what name service is being used?

Look at the file /etc/nsswitch.conf to see what name service is being
used. Look at the hosts line. If it is anything other than

hosts: files

temporarily change that entry as above so that only the /etc/hosts
file is accessed when trying to lookup host information.

Ensure that the /etc/hosts file contains an entry for localhost,
as shown below, and an entry for the machine name.

127.0.0.1 localhost

Double check that the IP address for the machine is the same as
the system IP address. Run the command:

ifconfig -a

to check the interfaces IP addresses. Verify that the first name after the
IP address for the machine is the same as defined in /etc/hostname.* where *
is the name of the interface.

After confirming the details, reboot the system to ensure all processes take
account of the temporary change of name service.

If the login works after that then there is a problem with the previous hosts
map, whether it be DNS, NIS or NIS+. Either locate the specific problem or
change the name service map /etc/nsswitch.conf to have the files entry before
the name service.

For example, for DNS name services the /etc/nsswitch.conf hosts line would be:
hosts: files dns

Note: If the name service is the cause, then it might take 3 minutes
per name services used. So if there are two name services used and
both are before "file", then it might take 6 minutes to resolve, and
hence to get into CDE. If the name service and the tooltalk are the
cause of the problem, then it might take 20 minutes to resolve.

10) Manually start CDE from the command line

Before trying to start the openwin/CDE from command line, check if
there is a graphic mode at all which is needed for the openwin/CDE.

That can be done as follows -

From the command line (i.e., no gui is running), log in as root and start the
CDE environment using the commands below (assumes the root shell is ksh or sh):

# OPENWINHOME=/usr/openwin
# export OPENWINHOME

# $OPENWINHOME/bin/xinit

This just starts the Xserver.

At this point, a window should open with one window with no borders,
from which a window manager can be opened by typing dtwm &, or twm &.
And this confirms that there is graphic mode.

If the above fails, then there is something wrong with the graphic
card or its configuration.

If there is a graphic mode, try opening CDE from the command line by using
the following command -

# $OPENWINHOME/bin/xinit /usr/dt/bin/Xsession

If this fails, does a core dump get generated? Look at it via the symbolic
debugger "debugger" using a command such as:

debugger fullpath_of_program core

> where
> quit

If no core file is generated, try using the truss command to see if you can
identify the error. The command below will truss the processes and store the
truss output in a file in the current directory called logfile:

# truss -aef -o logfile $OPENWINHOME/bin/xinit /usr/dt/bin/Xsession

11) Run pkgchk for any corrupt packages, mostly the SUNWdt* packages.

12) Check for maximum CPU usage, etc by any process.
ps -ef | more

13) Check that the hardware is supported?

14) Re-Install CDE

If you still can't solve the problem, re-install CDE from the CDROM.
This is applicable only for Solaris 2.5.1, as CDE comes in a separate
CD for 2.5.1.

The install-cde script will attempt to remove the previous installation
before installing the packages again.


15) Re-Install OS + CDE

If the problem still is not resolved, the change to the system is extremely
difficult to track down. It may be simpler to just re-install the OS and CDE
from scratch.

Re-install the OS starting with a simple configuration with no networking.

Check that CDE works and then add networking and any name service that is
required until either the problem re-appears or the system is fully functional
again.

Thanks for the quick replies.

As is quite evident...I'm a newbie to UNIX.

That was my mistake. I created the directory first. Owner of the /usr/dev1 directory was root with read & execute to the dev1 user I created.

To start clean, I deleted the user and the directory and recreated the user with Admintool and was able to login OK.

Thanks again to both of you! It's this kind of support that makes learning UNIX alittle easier.