Bug 153082

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.

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.

Thanks!

Created attachment 112679 [details]
autofs debug info as requested

It is for autofs-4.1.3-28

This is a debug log of a successful mount.  Can you produce a log that shows the
failed mount attempt?

Thanks!

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
/home/partain/wibble/bin/foo
and it will work correctly (and, of course, do the mount correctly).

Okay, deferring to Steve.  It sounds like autofs is doing the right thing. 
Thanks for helping to clarify that!

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.

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
:/crcmisc/isos/fc5/FC5-test1-i386-disc1.iso

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
magic.

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

/var/ftp/pub 192.168.1.0/24(ro,no_root_squash,sync)

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.

Addendum to my last:

I can access the ISOs correctly via FTP.

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!

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.