Bug 153082

Summary: nfs4 mount + path involving symlink = wrong behavior
Product: [Fedora] Fedora Reporter: Will Partain <will>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: charlescurley, mattdm
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-07 00:49:11 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
autofs debug info as requested none

Description Will Partain 2005-04-01 08:40:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
If I invoke a script by a path that involves a symlink which in turn
requires an nfs4 mount, it fails the first time  but then works after that.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
[client is FC3 i386; server is FC3 x86_64; both fully up-to-date]

The server is exporting...:

  /._disc1 quidditch.verilab.com(rw,sync,fsid=0,insecure,no_subtree_check)[other hosts]

The client (quidditch) is mounting /home/partain via /etc/auto_home ...

  partain -fstype=nfs4,rw,nosuid,nodev,sync,retry=5,rsize=16384,wsize=16384,udp,intr	albus.verilab.com:/home/partain

If, on the client, I now set up...:

   cd /etc
   sudo ln -s /home/partain/wibble test-wibble

and then (on some machine)

   mkdir -p /home/partain/wibble/bin

and create a script /home/partain/wibble/bin/foo

   #!/usr/bin/env sh
   echo hello NFS bug

Now... /home/partain is _not_ mounted on quidditch; I do (from another machine)

   % ssh quidditch /etc/test-wibble/bin/foo
   sh: /etc/test-wibble/bin/foo: /usr/bin/env: bad interpreter: Is a directory

/home/partain will be mounted now; if I run it immediately again:

   % ssh quidditch /etc/test-wibble/bin/foo
   hello NFS bug

This is very wrong :-)

If (with /home/partain not mounted) I avoid the symlink in /etc, I get

   partain@hagrid% ssh quidditch /home/partain/wibble/bin/foo
   hello NFS bug

which is correct.

Actual Results:  see above

Expected Results:  see above

Additional info:
Comment 1 Will Partain 2005-04-04 08:04:01 EDT
I can confirm that if I remove the "fstype=nfs4" from /etc/auto_home on the
client, things work as expected; i.e. it is nfs4-related.
Comment 4 Jeffrey Moyer 2005-04-04 13:07:31 EDT
Could you please post the version of autofs you are using?  Also, please enable
debugging for the autofs mount point you are using.  You can do that by simply
appending a --debug to the proper line in auto.master.

Next, place a line like the following in your /etc/syslog.conf:

*.*    /var/log/debug

Restart syslogd and autofs.  Then, reproduce the problem and attach
/var/log/debug to this bugzilla.

Doing this will help deterine whether or not autofs is a part of the problem.

Comment 5 Will Partain 2005-04-04 15:21:38 EDT
Created attachment 112679 [details]
autofs debug info as requested

It is for autofs-4.1.3-28
Comment 6 Jeffrey Moyer 2005-04-04 18:46:08 EDT
This is a debug log of a successful mount.  Can you produce a log that shows the
failed mount attempt?

Comment 7 Will Partain 2005-04-05 04:53:41 EDT
A failed mount has never been the problem.

Run the script the first time: the mount happens, but we get the "bad
interpreter" symptom.

Run the script immediately again (w/ the filesystem now mounted), and we get the
correct result.

Unmount /home/partain (i.e. back to where we started), then run the script
without going through the symlink in /etc; i.e. ssh quidditch
and it will work correctly (and, of course, do the mount correctly).
Comment 8 Jeffrey Moyer 2005-04-05 11:52:58 EDT
Okay, deferring to Steve.  It sounds like autofs is doing the right thing. 
Thanks for helping to clarify that!
Comment 9 Vincent Raffensberger 2005-08-16 15:18:20 EDT
I've been experiencing the same problem and may be able to add more info.  
In my situation, I'm running an app which uses a config file which exists on an
nfs volume.  The directory for the config file is actually a symbolic link to a
directory on the nfs4 volume:
/data/config -> /mnt/fse0_pub/config/
The app runs like this:
bf --config /data/config/bf.conf

The app isn't able to read the config file.
Strace reveals this:
open("/data/config/bf.conf", O_RDONLY) = -1 EISDIR (Is a directory)
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0

This will occur repeatedly until you perform a ls on /data/config/.

This does not happen when the nfs volume is mounted as nfs3.  
I do not use an automounter.
This is on EL4 with all updates: 2.6.9-11.ELhugemem.
This also occurred on 2.6.9-5.0.5ELhugemem.

I hope this helps.
Comment 10 Charles Curley 2005-11-26 18:38:41 EST
A bit more information.

I have a server running FC4 as updated, on which I have the FC5T1 ISOs. I have a
directory set up with symlinks, /var/ftp/pub/fc4.90. The symlinks in it point to
another directory, which autofs populates with the content of the ISOs. Each
line of the autofs file looks as follows (all one line):

FC5-test1-i386-disc1.iso	-fstype=iso9660,ro,loop

If I run ls, find, etc, on the server (e.g. "ls
var/ftp/pub/fc4.90/FC5-test1-i386-disc1.iso/"), everything is fine. I see the
contents of the ISO image, and no evidence that there is a symlink or any other

I have /var/ftp/pub/ exported as follows:


If I mount that directory on a client ("mount -t nfs charlesc:/var/ftp/pub
/mnt/nfs/", with or without "-t nfs" or "-o nfsvers=3"), and then run an ls or
find, I get a broken symlink. E.g:

ls /mnt/nfs/fc4.90/FC5-test1-i386-disc1.iso
/mnt/nfs/fc4.90/FC5-test1-i386-disc1.iso (in red, indicating a broken symlink)

ll /mnt/nfs/fc4.90/FC5-test1-i386-*/
ls: /mnt/nfs/fc4.90/FC5-test1-i386-*/: No such file or directory

This even immediately after I have run an ls on the server to force an automount.

Loggin is silent on autofs mounts, which is the case with no attempts to mount
or sucessful attempts. Logging indicates that NFS mounts are sucessful.

I conjecture that NFS is passing the raw symlink to the client, where it should
be passing the target of the symlink.
Comment 11 Charles Curley 2005-11-26 18:43:52 EST
Addendum to my last:

I can access the ISOs correctly via FTP.
Comment 12 Matthew Miller 2006-07-10 19:32:54 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 13 petrosyan 2008-02-07 00:49:11 EST
Fedora Core 3 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release please reopen this bug and assign it to the corresponding
Fedora version.