Bug 222138 - NFS map mounted incorrectly as read only
NFS map mounted incorrectly as read only
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-10 12:05 EST by John Hodrien
Modified: 2015-01-04 17:29 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-05 14:20:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
syslog debugging (10.04 KB, text/plain)
2007-01-11 05:03 EST, John Hodrien
no flags Details

  None (edit)
Description John Hodrien 2007-01-10 12:05:09 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.0.9) Gecko/20061219 Fedora/1.5.0.9-1.fc6 Firefox/1.5.0.9 pango-text

Description of problem:
Normal use of an NFS map results in rw mounts being mounted ro.  

Version-Release number of selected component (if applicable):
autofs-5.0.1-0.rc2.40

How reproducible:
Always


Steps to Reproduce:
1.  start the automounter
2.  cd /home/linux
3.  cd /home/linux_b

Actual Results:
/home/linux_b is mounted read-only

Expected Results:
/home/linux_b is mounted read-write

Additional info:
automounter map:

-rw,ac,nosuid,nodev,hard,intr   srv:/export/inf_a/linux_c
-rw,ac,nosuid,nodev,hard,intr   srv:/export/inf_a/linux_b
-ro,ac,nosuid,nodev,hard,intr   srv:/export/inf_a/linux

exports:

/export/inf_a @tux(rw,async,fsid=0)

Getting the rw mount before the ro mount results in /home/linux being mounted rw.
Changing the linux mount to rw solves the problem (obviously).

Behaviour is fine on another machine that experimentally uses fsc.
Comment 1 Jeffrey Moyer 2007-01-10 13:32:16 EST
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!
Comment 2 Ian Kent 2007-01-10 21:23:58 EST
(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.
Comment 3 John Hodrien 2007-01-11 05:03:33 EST
Created attachment 145329 [details]
syslog debugging
Comment 4 John Hodrien 2007-01-11 05:05:09 EST
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
Comment 5 Jeffrey Moyer 2007-01-11 11:42:54 EST
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?
Comment 6 Ian Kent 2007-01-11 11:53:59 EST
(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


Comment 7 John Hodrien 2007-01-11 11:57:37 EST
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
Comment 8 Jeffrey Moyer 2007-01-11 11:59:46 EST
(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?
Comment 9 Ian Kent 2007-01-21 23:55:38 EST
(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
Comment 10 Ian Kent 2007-02-14 02:23:35 EST
Any ideas on the cause of this?

Ian
Comment 11 John Hodrien 2007-03-05 13:17:08 EST
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.
Comment 12 Jeffrey Moyer 2007-03-05 14:20:16 EST
(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).
Comment 13 Ian Kent 2007-03-05 20:55:06 EST
(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

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