Can't find current directory

[Kevin Liquori]

I have a problem with a directory. I recently wanted to change a mountpoint
name. I umount'd the filesystem, created a new directory (mountpoint) and
remounted the filesystem. Everything seemed to work OK. Now I see a problem. As
root everything looks OK, but as a regular user (non-root) I cannot do an ls on
'..' (dot dot). This is causing a problem with the application that resides in
the directory. I can see dot but not dot dot. I am able, however, to do 'cd dot
dot' and it works. In the directory above I can see everything fine. Is this a
user environment issue? Could it have something to do with the mountpoint?

Thanks
...Kevin

[James R. Ferguson · Accepted solution]

Hi Kevin:

This is probably a permissions problem. Unmount the filesystem and make sure that the permissions on the mountpoint are (at least) read+execute for all (i.e. 555).

Regards!

...JRF...

[Alex Glennie]

I suspect its the permissions of the mount point ... have a read of the following eg znd see if your problem is similar : if not some more details on the perms , mount point and O/S would be handy ...

Problem DescriptionI have an application loaded in a directory that users need
to access. The filesystem is loaded on a logical volume.
When the users cd into the directory, the ".." (parent directory)
is missing. Root can cd into the directory and the ".." is there.
I ran fsck against the umounted logical volume, but it came back
with no errors. The mount points for the filesystem are all
777 (drwxrwxrwx) and root is 755 (drwxr-xr-x).What is going ?Configuration Info
Operating System - HP-UX Version -10.20Hardware System - HP 9000
Series -755Solution
The problem is that the filesystem is a JFS filesystem and JFS
looks at the underlying mount point permissions/ownerships for
access. HFS simply looks at the permissions after the filesystem
is mounted. There is no way to see the mountpoint permissions
using normal HP-UX commands until the filesystem is umounted.
In this case the underlying permission was 770 (drwxrwx---)
and the ownership was root:sys. This is a somewhat unrealistic
permission for a directory.
Changing the permissions from 770 to 777 will correct the problem.
Generally the restrictive permissions are caused by root running
with a umask of 007 which strips all of the bits from the other
portion of the permissions. Users must have read and executability
at a minimum for reading and directory movement.

[Sanjay_6]

Hi Kevin,

Make sure you have the execute permission set on the directory.

hope this helps.

Regds

[Kevin Liquori]

The permissions on that mountpoint are 777. Could that be showing false because it's already mounted?

Thanks
...Kevin

[Justo Exposito]

Hi Kevin,

Try to re-change the permits to 777 and then login to the system with a normal user and try to ls.

Regards,

Justo.

[Steve Post]

Yeah everybody's right. There is one other possibility. If the directory was renamed or moved while you were in it, you would get errors like what you have here.
It happened to me once when I shut down a third party application and one of its "enhancements" was to move the log directory to log.old (WHILE I WAS IN IT).

[Kevin Liquori]

Yes, everyone was right! The permissions looked like 777, I umount'd the filesystem and they were 744. I chmod'd to 777, re-mounted and everything was cool!

Thanks
...Kevin