Cris.Fuhrman@a.coe.wvu.wvnet.edu (02/08/89)
Hello everyone.
I've got another 'stupid' question for you. Same set up as all the other
letters I've sent: Some Sun 3/60's off a server running Sun OS 3.2.
Can someone tell me why it's necessary to put the link for /usr/lib/uucp
to be
lrwxrwxrwx 1 root 34 Jun 3 1988 uucp -> ../../private.MC68020/usr/lib/uucp
Why couldn't it be /private.MC68020/usr/lib/uucp ? The reason I'm asking
is that I can't get my /usr/lib/sendmail.cf to be readable from all of my
clients (it needs to be linked to /private/usr/lib/sendmail.cf). An ls -l
of the server machine (where /usr is physically located)
/usr/lib/sendmail.cf is as follows:
lrwxrwxrwx 1 root 33 Dec 21 10:37 sendmail.cf -> ../../private/usr/lib/send
mail.cf
For example, if I'm on a client machine (/usr is nfs mounted) and cd
/usr/lib, all works fine (I can read all the files with o+r modes). At
that point, if I type cd ../.. (I'd think I'd be back at root), I get
../..: Permission denied
If I do ls -lad .., it says .. not found.
cd / works fine.
>From the server, ls -ld /usr yields
lrwxrwxrwx 1 root 11 Jun 3 1988 /usr -> usr.MC68020/
and ls -ld /usr/lib yields
drwxr-xr-x 21 bin 4096 Dec 21 15:46 lib/
Anyone care to comment?
I'm pretty frustrated about the NFS cross mounting kludge... Just when I
thought I was beginning to like unix...
-Crisdik@uva.UUCP (Casper H.S. Dik) (02/16/89)
Cris.Fuhrman@a.coe.wvu.wvnet.edu writes: > [stuff deleted about accessing ../.. on clients in /usr/lib ] >From the server, ls -ld /usr yields > >lrwxrwxrwx 1 root 11 Jun 3 1988 /usr -> usr.MC68020/ > >and ls -ld /usr/lib yields > >drwxr-xr-x 21 bin 4096 Dec 21 15:46 lib/ > >Anyone care to comment? > >I'm pretty frustrated about the NFS cross mounting kludge... Just when I >thought I was beginning to like unix... You stumbled accross one of the nastiest bugs I've encountered. I had the same problem, and it turned out to be caused by the permissions set for the mount point. When you access '..' in the root of a NFS-mounted filesystem, this is translated to a search for .. in the mount point. If you the permissions for the mount point aren't right - trouble ahead. Fix: umount /usr chmod a+rx /usr (need both read & execute permission) mount /usr This bug once cost me the better part of a day, I dumped the fs and ran newfs - all to no avail. I don't know for sure but it seems to happen on normally (not NFS) mounted filesystems as well. Let's try. # chmod 700 /mnt # ls -ld /mnt drwx------ 2 bin 24 Sep 15 1986 /mnt/ # mount /dev/sd2c /mnt # ls -ld /mnt drwxr-xr-x 3 root 1024 Feb 2 19:33 /mnt/ # su nobody $ cd mnt $ ls -ld drwxr-xr-x 3 root 1024 Feb 2 19:33 . $ ls -ld .. . not found So check all your mount points and chmod a+rx them. [[ Remember: in order to change the mount point itself, you have to do the chmod before the file system is mounted there. Otherwise you will be changing the root directory of the mounted file system (and in the case of NFS partitions, it might produce an error message). --wnl ]] --cd Casper H.S. Dik University of Amsterdam | dik@uva.uucp The Netherlands | ...!uunet!mcvax!uva!dik