Google tells me that a common cause for CDE issues is the inability of the server to look up its own hostname. If the hostname resolution files like /etc/hosts, /etc/nsswitch.conf or /etc/resolv.conf have non-standard permissions, one user might have problems while other users can use CDE normally. These files should be readable by everyone, but writeable by root only.
That's right. I have already ran that check script, which verify the correct permissions and fixed accordingly /usr/contrib/bin/X11/dr_dt but still can't log in.
Look at ~/.dt/startlog: it is a log file that stores session startup diagnostics from the latest CDE session. Older versions of the log are stored at ~/.dt/startlog.old and ~/.dt/startlog.older. The normal startup for user "foo" should look similar to this:
The user in this example had a ~/.dtprofile file. The CDE reads ~/.profile only if ~/.dtprofile does not exist, or if ~/.dtprofile explicitly tells the system to read ~/.profile too.
One of my old notes says: "If there are 'unable to open display' errors in the ~/.dt/startlog* files, see if the user has hardcoded the DISPLAY variable to some value in ~/.dtprofile or ~/.profile." If the user logs in locally, the DISPLAY variable is provided automatically by the dtlogin process that starts the user's session.
There are other CDE session log files that might be useful too: ~/.dt/errorlog and the directory ~/.dt/sessionlogs/.
But if the permissions of /ednop/dbmgr/.dt/sessionlogs/ directory allow the user to write into this directory, something else may be preventing the user from creating any files.That would definitely cause problems for the CDE session.
Is the user currently restricted by a disk quota? If you are not sure, this command should tell you:
quota -v <username>
If the disk quota is configured and the user currently has more files than the quota allows, the user cannot create any new files at all. This will cause the CDE session setup to fail. As a sysadmin, your options are to either help the user remove some unnecessary files (or store them somewhere else), or to adjust the quota to suit the user's needs (assuming that the user has a legitimate requirement for more disk space).
The pathname in the error message also indicates the user's home directory is not the usual /home/<username>, but /ednop/dbmgr. This sounds like a filesystem that is configured for some specific application: have you checked that the filesystem is not full?
The DISPLAY variable currently contains an IP address instead of a hostname. That may indicate hostname resolution issues. If you run "nslookup 8.12.4.198" on the server, the response should include a valid hostname for the system with that IP address. (Yes: it means that if the user is logging on using Reflection/X or similar from a remote workstation, the the server needs to be able to resolve the hostname of the workstation.)
The server also always needs to be able to resolve its own hostname. Find the IP address(es) of the server and use the nslookup command (as above) to verify that the address(es) are correctly resolvable to the server hostname ("erez2", I believe).
A basic X application might handle a DISPLAY variable with an IP address instead of hostname just fine, but if I recall correctly, a full CDE desktop session needs the hostname.
Also, the DISPLAY=8.12.4.198:3 means a 4th X display on system with the IP address 8.12.4.198, or that the X server process that actually draws the stuff on the user's display is running on port 6003. As the screenshot in your original post indicated you can see the CDE copyright messages, this is probably not an error, but just a slightly unusual configuration.
I might provide more information regarding this issue.
HP-UX is running the application here and connect to the "ednop"
"ednop" is a netup or a disk storage that store all data.
The users login to the system via exceed (v.14). But I checked the login to this specific user directly in front of the HP-UX machine and the same error message received.
In addition, all other accounts are accessible and can be logged in via exceed.
# quota -v dbmgr
gives
Disk quota for dbmgr (uid 247) and no error or unusual message.
# nslookup 8.12.4.198
can be resolved. this is my pc IP address from which I run the exceed program and communicate the HP-UX machine.
This IP address has been added to the /etc/hosts.
Anyways, I will backup data from dbmgr and make some more space there.
> "ednop" is a netup or a disk storage that store all data.
So it is a separate filesystem? Is it a remote filesystem, like a NFS mount? (What does "mount | grep ednop" say?)
If it is a remote filesystem (e.g. NFS or CIFS), then the server that actually holds the disks may still be implementing quotas or other restrictions. Or it might have an error condition that produces a meaningful error message only on the server that has the actual disks.
> So it is a separate filesystem? Is it a remote filesystem, like a NFS mount? (What does "mount | grep ednop" say?)
Yes, it is NFS mount
# mount | grep ednop
/ednop on ednop:/vol/vol0/scc soft,rsize=32768, wsize=32768, NFSv3
> If it is a remote filesystem (e.g. NFS or CIFS), then the server that actually holds the disks may still be implementing quotas or other restrictions. Or it might have an error condition that produces a meaningful error message only on the server that has the actual disks.
Maybe this user has a disk quota on ednop, and the rquotad daemon (the daemon that provides remote quota information to NFS clients) is not running on host ednop, or is blocked by firewalls?
The error message I noted previously indicates that the dbmgr user cannot create a file in a subdirectory of his home directory. That is not normal. Whatever the cause is, it might be preventing dbmgr from creating other files too. One of those files might be a file that is required for a successful CDE session.
Are the file permissions of the sessionlogs directory (and its parent directories) properly set, so that the dbmgr user can access his home directory, and write to files and sub-directories within it?
If possible, log in to host ednop, and verify the overall health of the filesystem /vol/vol0/scc there. Also check for disk quotas.
The ednop server ultimately controls what the dbmgr user can write and what it cannot. If a disk quota or some other restriction has been applied to dbmgr on that host, the restriction is probably in effect over the NFS mount too. The ednop server might be stopping the dbmgr user from creating files, but unable to report the reason of the restriction over the NFS protocol. You might get more information by checking the state of the filesystem locally.
If it is possible to log in to ednop as dbmgr, can you create files to /vol/vol0/scc/dbmgr/.dt/sessionlogs locally?
The answer to this question should help in locating the problem:
If you can, the problem is probably caused by something NFS-related: UID/GID mismatch, the user being a member of too many groups, etc.
If you cannot, the problem is definitely caused by something on the ednop server, probably at the filesystem level or lower.
If there is a localized failure of the physical disk surface, it might first appear as a filesystem corruption in an essentially random location... and over NFS, it might be apparent only as strange behavior like this.
That was a permission problem. Somehow, files under the home directory of different users receives NUMBERS (such as 110 or 114 or other combination of 3 digits No.) instead of the owner permission name of a specific user account.
In this case I changed the owner permission to dbmgr and removed the .Xauthority of the dbmgr user.
Then logged in successfully.
Can someone explain me why these permissions changed and how to prevent it to reoccur?
