Bug 153082
| Summary: | nfs4 mount + path involving symlink = wrong behavior | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Will Partain <will> | ||||
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3 | CC: | charlescurley, mattdm | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-02-07 05:49:11 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Will Partain
2005-04-01 13:40:47 UTC
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. |