Bug 222138

I'm not sure I follow you Additional info statements, but no matter.  Could you
please collect some debugging information?  You can find a description of how to
do so on my people page:  http://people.redhat.com/jmoyer/.

The map you posted is fine, I think we can make assumptions about what the keys
are.  In the future, though, if you're going to post NIS maps, use ypcat -k to
get the key field.

Thanks!

(In reply to comment #1)
> I'm not sure I follow you Additional info statements, but no matter.  Could you
> please collect some debugging information?  You can find a description of how to
> do so on my people page:  http://people.redhat.com/jmoyer/.

The info on Jeffs page is a little out of date for autofs version 5.
The bit that could cause confusion is the reference to DAEMONOPTIONS
which is not used in v5. To achieve the same result set
DEFAULT_LOGGING="debug"
in /etc/sysconfig/autofs.

Created attachment 145329 [details]
syslog debugging

Sorry for my vagueness ;)

Debug seems to show it's trying a rw mount.  Mount shows a rw mount on linux_b,
but /proc/mounts doesn't:

servermachine:/export/inf_a/linux /home/linux nfs
ro,nosuid,nodev,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=iri05
0 0
servermachine:/export/inf_a/linux_b /home/linux_b nfs
ro,nosuid,nodev,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=iri05
0 0

Strange.  Can you confirm that the mount is read-only?  I'm CC-ing SteveD, here,
in case it's an nfs issue.  What version of util-linux, nfs-utils, and kernel do
you have installed?

Steve, if you look at the autofs debug log attached in comment #3, you'll see
that autofs calls mount with -o rw (among other things), but the mount is
showing up in /proc/mounts as read-only.  Any ideas?

(In reply to comment #5)
> Strange.  Can you confirm that the mount is read-only?  I'm CC-ing SteveD, here,
> in case it's an nfs issue.  What version of util-linux, nfs-utils, and kernel do
> you have installed?
> 
> Steve, if you look at the autofs debug log attached in comment #3, you'll see
> that autofs calls mount with -o rw (among other things), but the mount is
> showing up in /proc/mounts as read-only.  Any ideas?

I'm fairly sure this is related to the export and the initial
mount options because I see similar behaviour when different
mount protocol is specified for the same location.

Ian

Definitely read-only as that's what first drew it to my attention (logging into
X failed immediately as users couldn't write to their home directory).

Cleanest machine to exhibit this problem is a fresh FC6 install that showed it
from the original versions of packages and the latest.  Current packages are:

util-linux-2.13-0.45.3.fc6
nfs-utils-1.0.10-5.fc6
kernel-2.6.18-1.2869.fc6

(In reply to comment #6)
> I'm fairly sure this is related to the export and the initial
> mount options because I see similar behaviour when different
> mount protocol is specified for the same location.

Sorry for being dense, but what are you saying, here?  Are you implicating
autofs, nfs client, mount, or something else?

(In reply to comment #8)
> (In reply to comment #6)
> > I'm fairly sure this is related to the export and the initial
> > mount options because I see similar behaviour when different
> > mount protocol is specified for the same location.
> 
> Sorry for being dense, but what are you saying, here?  Are you implicating
> autofs, nfs client, mount, or something else?

Yes, fairly vague I agree, but that's because it's not clear
to me either.

I think this is a fairly recent NFS "feature" related to the
exporting of subdirectories of a filesystem rather than entire
filesystems. I think that multiple exports within the same
filesystem, with different export options, will take on the
options of the first mounted subdirectory in subsequent
mounts. So this may be related to the NFS server, client
or both.

I don't think that there's anything that autofs can do about
it. Perhaps mount.nfs could to be more accurate in it's status
reporting as it's certainly not accurate in this case.

So we probably should pass this on to?

Ian

Any ideas on the cause of this?

Ian

http://bugzilla.kernel.org/show_bug.cgi?id=7612

I assume this means I'm expecting too much from the newer kernels and that this
simply how it's going to behave in future.

(In reply to comment #11)
> http://bugzilla.kernel.org/show_bug.cgi?id=7612
> 
> I assume this means I'm expecting too much from the newer kernels and that this
> simply how it's going to behave in future.

That appears to be the case, yes.  There aren't any tricks we can play from the
automount side of the house.  I'm not sure how to close this.  For now, I guess
we'll call it not a bug (since it functions as designed).

(In reply to comment #11)
> http://bugzilla.kernel.org/show_bug.cgi?id=7612
> 
> I assume this means I'm expecting too much from the newer kernels and that this
> simply how it's going to behave in future.

Yes, I've seen this for quite some time but haven't
been sure whether it was also the case for seperate
filesystems exported from a server.

In your case is this happening for distinct filesystems
exported from the server also? I'd like to find out if
this is also a problem with the kernel super block
sharing as posts that I've seen imply the problem is 
restricted to filesystems that have multiple exports.

It would be good to know exactly what the status is
for this as the issue has been lurking around for a
while now without anyone being quite sure of what is
wrong.

And there's really nothing we can do about it in
autofs so once we're clear on the issue we'll have
to close this as CANTFIX, sorry.

Ian