Bug 250597 - hierarchical automount will only mount one partition at a time
Summary: hierarchical automount will only mount one partition at a time
Alias: None
Product: Fedora
Classification: Fedora
Component: autofs   
(Show other bugs)
Version: 7
Hardware: All Linux
Target Milestone: ---
Assignee: Ian Kent
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-02 12:38 UTC by Michael Young
Modified: 2008-05-14 14:06 UTC (History)
8 users (show)

Fixed In Version: nfs-utils-1.1.0-3.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-14 14:06:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
debug log from automount (9.70 KB, text/plain)
2007-08-02 16:38 UTC, Michael Young
no flags Details

Description Michael Young 2007-08-02 12:38:42 UTC
With a 2.6.22 kernel (eg. kernel- or kernel- we
have a hierarchical automount that behaves strangely, because it will only mount
one submount at a time and listing a second submount fails with the error
ls: cannot open directory /home/hudson/staff: No such file or directory
The configuration is in /etc/auto.master
/home /etc/auto.home            -rw,intr,noquota,noac,actimeo=0
and in /etc/auto.home
hudson -rw,intr,quota,noac,actimeo=0 /staff &:/vol/vol0/staff /group
you can list either /home/hudson/staff or /home/hudson/group if the other isn't
mounted, but have to unmount one before you can see the other, though both
should work simultaneously, (which is the case with a 2.6.21 kernel such as
kernel-2.6.21-1.3228.fc7). I am guessing there is either a bug in the new
kernels, or (perhaps more likely given other reports of USB problems etc.)
something has changed in the kernel which triggers a bug in autofs.

Comment 1 Ian Kent 2007-08-02 15:39:59 UTC
Yes, that should work and the last significant change
I made to autofs4 went into 2.6.21. I'll check for
differences but if it's outside of autofs4 then I'll
need to duplicate the problem on 2.6.22.

Unfortunately, the recent 2.6.22 kernel packages fail to
recognize my SATA disk so I can't even duplicate this
till I can get a revision of the kernel package that
will boot.

Could you get a debug log for the userspace daemon, at
least I'll have something to check in the mean time. Info
of that can be found on Jeff Moyers people page at http://people.redhat.com/jmoyer.


Comment 2 Michael Young 2007-08-02 16:38:13 UTC
Created attachment 160536 [details]
debug log from automount

Here is a debug log I generated. This is with /home/hudson/misc mounted, then
/home/hudson/group attempting and failing to be mounted.

Comment 3 Ian Kent 2007-08-02 17:24:03 UTC
(In reply to comment #2)
> Created an attachment (id=160536) [edit]
> debug log from automount
> Here is a debug log I generated. This is with /home/hudson/misc mounted, then
> /home/hudson/group attempting and failing to be mounted.

Thanks, I think I know what's causing this.
It's late here now so let me check tomorrow and perhaps
post to the kernel kernel list.


Comment 4 Ian Kent 2007-08-02 17:28:11 UTC
(In reply to comment #2)
> Created an attachment (id=160536) [edit]
> debug log from automount
> Here is a debug log I generated. This is with /home/hudson/misc mounted, then
> /home/hudson/group attempting and failing to be mounted.

btw, would I be correct in saying that hudson:/vol/vol0/misc
and hudson:/vol/vol0/group are exports from within the same
filesystem and that this doesn't happen for exports of distinct


Comment 5 Michael Young 2007-08-02 17:53:11 UTC
Yes, the nfs share is hudson:/vol/vol0

Comment 6 Ian Kent 2007-08-03 06:44:03 UTC
OK, I'm fairly sure the kernel patch linux-2.6-nfs-nosharecache.patch
causes this behavior.

The history is that at some time in the past superblock sharing
was added to the upstream kernel to avoid some nasty cache
coherency issues. This had the side effect of preventing second
and subsequent mounts from the same exported filesystem from
using different mount options, such as mixing rw and ro. There
was some unhappyness about this and the above patch was put
together to allow it to be over-ridden by a mount option
"nosharecache". Unfortunately, the patch returns -EBUSY when such
a mount is attempted and the new option is not specified, causing
the symptom you're seeing. No-one wanted to make "nosharecache"
the default because of the issues the original change resolved
which means an explicit "nosharcache" option is required.
Unfortunately, the current nfs-utils in Rawhide and F-7 doesn't
know about the option yet.


Comment 7 Steve Dickson 2007-08-13 15:35:10 UTC
The nosharecache option will be in nfs-utils-1.1.0-3.fc7 which
will be in a yum repo near you... very soon... 

Comment 8 Michael Young 2007-09-11 10:56:49 UTC
Yes, adding -Onosharecache to the OPTIONS line in /etc/sysconfig/autofs and
restarting autofs fixes the problem with this nfs version.

Comment 9 Hemant Shah 2007-10-16 19:44:34 UTC
I was having same problems with kernel. I added nosharecache
option and was able to mount the sub-directories, but now when I mount the
sub-directories it crashes rpcbind on my NFS server. We have Auspex NS3000 NFS

I have nfs-utils-1.0.10-14.fc6 and nfs-utils-lib-1.0.8-7.2 installed on the system.

When rpcbind crashes the NFS access on Unix (AIX, HP-UX, various flavors of
Linux) slows down. I also share the NFS filesystem with PCs using samba and the
PCs cannot access the files. 

Comment 10 Bug Zapper 2008-05-14 13:50:07 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Michael Young 2008-05-14 14:06:12 UTC
I haven't had any problems since we rolled out the -Onosharecache option, so I
consider this fixed.

Note You need to log in before you can comment on or make changes to this bug.