Bug 134977

Neil, this sounds as if mountd or exportfs no longer chase symlinks?

I cannot duplicate this, and I'm a little confused by the symptoms reported.

Can you give me the exact command run on the list to mount from the server,
and an 'ls -l' of the location that was mounted.

Thanks,
NeilBrown

On my computer with SL 10.1 alpha3 I do:
mkdir /abuild/work
touch /abuild/work/asdf
ln -s /abuild/work /exportnfs 
yast2
 ->network services -> nfs server
      run nfs server
      add directory : /exportnfs (I leave attributes as offered)
      Finish.

On other computer
su 
mount -t nfs mycomputername:/exportnfs /mnt
ls -d /mnt shows broken symlink to -> /abuild/nfs, which doesn't exist on that computer.
If I boot SL 10.0 and do the same, on other computer ls /mnt shows file asdf.

Thankyou for being more explicit - it helps.

Is there any chance that SL 10.1 has NFSv4 enabled and so that is being used?
Some things to test:

 - look in /proc/mounts on the client for the entry for '/mnt'.  Is it different
   between having 10.0 and 10.1 on the server?
 - run 'rpcinfo -p name-of-server | grep nfs' when server is running 10.0 and 
   10.1.  Is there any difference?
 - Try mounting with '-o vers=3' when the server is running 10.1.  Does this make 
   it work as you would expect?

Thanks.

if booted 10.0

less /proc/mounts
...
zuzka:/hudba /mnt nfs
rw,v3,rsize=32768,wsize=32768,hard,tcp,lock,addr=zuzka 0 0


rpcinfo -p zuzka | grep nfs
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs

if booted 10.1

less /proc/mounts
...
zuzka:/hudba /mnt nfs
rw,v3,rsize=32768,wsize=32768,hard,tcp,lock,addr=zuzka 0 0
 Looks like it is the same.

rpcinfo -p zuzka | grep nfs
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs

mount -t nfs -o vers=3 zuzka:/hudba /mnt doesn't helped.
ll  /mnt

lrwxrwxrwx  1 root root 10 2005-11-22 17:32 /mnt/Sk -> /abuild/Sk
/abuild/Sk doesn't exist.

Thanks for the further detail.
However I am now confused.

You originally seemed to say that the object you were mounting was a symlink
on the server.e.g.
    mount -t nfs mycomputername:/exportnfs /mnt
  /exportnfs is a symlink on the server.

However now you seem to be saying that the object you are mounting is a directory
that contains a symlink.
    mount -t nfs -o vers=3 zuzka:/hudba /mnt
 /hudba is a directory containing a symlink called 'Sk', which points to
 /abuild/Sk.

Which is it?

NFS *Should* follow a symlink that is at the name being mounted, so if you
   mount -t nfs host:/path /mnt
and /path is a symlink on the server, then the symlink will be resolved (or
followed) before the mount happens.  However NFS DOES NOT (and never has)
follow symlinks inside mount points.  So in the above example, if 
   /path/somefile
is a symlink, then on the client you will see '/mnt/somefile' as being
a symlink to the same place (which certainly may not exist on the client) - 
that is simple the wawy NFS has always worked.

If you are still seeing a difference in behaviour between 10.0 and 10.1, please
send a transcript of the exact commands that you run in each setup, and the
exact results that you get.

Thanks,
NeilBrown

I'm a fool. I're right. I didn't notice this little difference. I thought I did the same action as in 10.0. I'm sorry.