Bugzilla – Bug 134977
nfs server does not follow the symlink
Last modified: 2005-11-29 10:55:34 UTC
I have made symlink directory as ln -s /path/somedir /exportdir and in yast -> nfs server the /exportdir is exported. On other computer user mounts exportdir through nfs. But it shows only broken symlink (/path/somedir doesn't exist on that computer). If the same process is made on SL 10.0, on other computer, user sees the content of my /path/somedir/.
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.