current working directory
I think that most commonly occurs when you have a filesystem mounted. The mounted filesystem permissions are seen when you do 'ls -ld <mount>', but the permissions of the directory underneath are used by some utilities.
You'll see similar errors with 'pwd' when a user is in the directory, but doesn't have sufficient priviliges on the underlying mount point.
Easiest solution is to unmount the filesystem, chmod the mountpoint, then remount the directory.
--
Darren
These suggestions don't make any sense to me. A script creates a directory in /tmp with subdirectories and datafiles. The script cd's back to the $HOME directory and then "rm -fr $tmp_dir" where $tmp = /tmp/directory/$0.$date.$$. Before the upgrade to Solaris 9, the code worked fine in Solaris 8. Now, after the upgrade I am getting the error. and have to explicitly do a rmdir $tmp.
On the other hand, there is something here, because if I log on to the box, and manually enter the rm -fr * command in /tmp/directory, then all the stuff goes away and I don't get the error. But, under other circumstances even when working manually from the command line, I get the error.
As far as the permissions reported by ls -l, they are all either drwxrwxrwx or drwxr-xr-x and the user/owner where the problem is occurring is the same as the parent directory. That is the owner of /tmp/directory is the same as /tmp/directory/$0.$date.$$.
Message was edited by:
Chasman
The mount point in question is /tmp. Unmount it, fix the permissions underneath, then remount it.
Here's an example:
# mkdir /priv /unpriv
# chmod 700 /priv
# chmod 777 /unpriv
# mount -F tmpfs swap /priv
# mount -F tmpfs swap /unpriv
# chmod 777 /priv
# ls -ld /priv /unpriv
drwxrwxrwx3 rootother117 Apr 5 08:44 /priv
drwxrwxrwx3 rootother117 Apr 5 08:44 /unpriv
# su - nobody
$ cd /priv
$ mkdir a
$ rm -rf a
rm: cannot determine if this is an ancestor of the current working directory
a
$ cd /unpriv
$ mkdir a
$ rm -rf a
Note that in the 'ls' above, the permissions look identical. But because the directory underneath the mount points are not the same, it screws up.
There's no difference between 8 and 9 here. It's just that it's screwed up for you on this particular box.
You don't mention accounts. When you log into the box and can clean it up, are you root? This error is permissions based, so it won't happen to root. Only to an account without sufficient privileges on the underlying mount point.
--
Darren