What's wrong with this directory?

[Gord Moore]

I have been struggling with this for hours and don't see why this is happening.

$ pwd
/home/tuxedo
$ ls
$ ls -a
. .. .sh_history
$ ll
total 0
$ ll -d

at this point it hangs. I have to ctrl-c to get out. I have deleted and remade the directory. The user and group numbers seem to be ok. It is just certain commands that don't work. Here are the same commands when run as root.

[root] /home/tuxedo> pwd
/home/tuxedo
[root] /home/tuxedo> ls
.sh_history
[root] /home/tuxedo> ls -a
. .. .sh_history
[root] /home/tuxedo> ll
total 16
-rw------- 1 tuxedo tuxedo 164 Oct 14 12:09 .sh_history
[root] /home/tuxedo> ll -d
drwxr-xr-x 2 tuxedo tuxedo 96 Oct 14 11:48 .

As far as I can tell these are standard permissions for the directories. Can anyone tell me what's going on?

Another symptom (maybe) is that the user hangs after entering the password. I found out that the /etc/profile was running a mail -e command (just like all other users) and that is what was hanging. If I kill that process I get the prompt like this:

Password:
/etc/profile[105]: 20618 Terminated
$ pwd
/home/tuxedo

Other commands like whoami won't work either.


Thanks

[John Poff]

Hi,

Have you checked the permissions on your /etc/passwd file? Make sure that it is world readable. What results do you get from running 'ls -la' as the regular user?

JP

[Gord Moore]

as root I get this:
[root] /home/tuxedo> ls -la
total 32
drwxr-xr-x 2 tuxedo tuxedo 96 Oct 14 11:48 .
drwxr-xr-x 148 root root 8192 Oct 14 11:46 ..
-rw------- 1 tuxedo tuxedo 212 Oct 14 12:46 .sh_history

as the user I get hung:
$ pwd
/home/tuxedo
$ ls -la
total 32

and there it sits. This is a trusted system with NIS+ on HP-UX 11i. No other user is having a problem, and this user doesn't have a problem on other servers. Things look the same between the servers. Really strange to me.

[Geoff Wild]

Do you have any aliases for ll and or ls?

# alias
autoload='typeset -fu'
cat=/usr/bin/cat
chmod=/usr/bin/chmod
command='command '
cp=/usr/bin/cp
date=/usr/bin/date
functions='typeset -f'
grep=/usr/bin/grep
history='fc -l'
integer='typeset -i'
local=typeset
ls=/usr/bin/ls
mv=/usr/bin/mv
nohup='nohup '
r='fc -e -'
stop='kill -STOP'
suspend='kill -STOP $$'
type='whence -v'
vi=/usr/bin/vi

Rgds...Geoff

[doug mielke]

maybe a new profile is in order for user Tuxedo.

Our tuxedo user has suffered all manner of corruption over time, ( we seem to have hung tuxedo processes whenever we shutdown, and sometime have to cleanup broken files afterward)

[Govind_3]

when you kill the mail -e command could you tell me what process is prompting the password? Check to see if there is any local user called tuxedo on this server?? Check to see if youa re sourcing the same .profile for the user tuxedo on all the servers.
-Cheers
Govind

[Gord Moore]

nothing special, just the usual

ls=/usr/bin/ls

I can put files into that directory. I just can't use ll to list them.

$ pwd
/home/tuxedo
$ touch test
$ env > test.env
$ alias > test.alias
$ ls
test test.alias test.env
$ ls -a
. .. .sh_history test test.alias test.env
$ ls -l
total 32
(hangs, use ctrl-c)
$ ls -n
total 32
-rw-r--r-- 1 777 777 0 Oct 14 14:27 test
-rw-r--r-- 1 777 777 283 Oct 14 14:28 test.alias
-rw-r--r-- 1 777 777 1386 Oct 14 14:28 test.env
$ ls -g
total 32
$

So it is a number to name translation thing?
The userid is 777 and the group is 777 as well. Both are called tuxedo.

[Patrick Wallek]

What happens if you do an 'ls -n /etc/passwd'?

[Gord Moore]

Patrick,

$ ls -n /etc/passwd
-r--r--r-- 1 0 3 722 Mar 17 2004 /etc/passwd
$ ll /etc/passwd
-r--r--r-- 1 root sys 722 Mar 17 2004 /etc/passwd

So the ll command works for files other than the user's own directory. hmmmm.

[Gord Moore]

Govind,

the mail -e command is run from the default profile in /etc/profile. See the tail end of my original posting.

The user doesn't have a local .profile file.

[Sundar_7]

I have seen something close with automounted home directories.

By any chance, the user's home directory automounted ?

[Govind_3]

1)Try stopping and starting the NFS client on this workstation. I agree with Sundar that this sounds more like a NFS auto mounter issue. try doing a "showmount -e HOMEDIRECTORY_SERVER_FORTUXEDO"
try mounting it some other directory say /mnt.
and then su to tuxedo and see if you are able to do "ls -l" on the directory.
2) Check to see if the /etc/profile is trying to mount something unkown to this current server? That might a possible case too.
Goodluck
Govind

[support_5]

It may also be something to do with Trusted Systems. May I ask how did you add the user? Did you use the standard useradd command? Or did you by any chance manually add an entry in /etc/passwd? If so, then the account will not work properly.

Also, it's worth while running this command once in a while to check the Trusted Systems Database (TCB entries):

authck -p

This will tell you if there is something wrong going on in your TCB files.

Hope this helps.

- Andy Gray

[Gord Moore]

The system is trusted and uses NIS+. The user should have been added through SAM in the NIS+ user menus. I would have to check.

I have checked that it is only in the NIS+ tables; it is not in /etc/passwd.

I ran authck -p and did not get any hits on that user; however there were others that I will be looking into tomorrow.

I am just at a loss to figure out why the ls -l command fails, but the ls -n command works. Where does the -l command look for the user id and group id name?

[support_5]

In that case, it sounds a lot like an NFS issue. I don't know if you are using NFS'd home directories or not, but if you are, I'd be checking stuff to do with that, although if it's only happening to the one user, then that is really strange. Perhaps stop and restart NFS stuff? Maybe even a reboot may do wonders (I hate to say that)? You never know.

Can't help you much more...sorry.

Anyone else?

- Andy Gray