From: Matt Schillinger <mschilli@vss.fsi.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: nfs@lists.sourceforge.net
Subject: Re: [Fwd: Re: rpc.mountd problems]
Date: 25 Jun 2003 12:33:47 -0500 [thread overview]
Message-ID: <1056562429.3941.49.camel@mosix> (raw)
In-Reply-To: <16119.28036.546786.260128@gargle.gargle.HOWL>
On Mon, 2003-06-23 at 16:13, Neil Brown wrote:
> On June 23, mschilli@vss.fsi.com wrote:
> >
> > I am forwarding this message to the list to see if anyone knows why I am
> > getting these 'Invalid argument' messages when doing an exportfs -arv..
> > It seems to be connected to only one of the export directories..
> >
> > Matt
> > -----Forwarded Message-----
> >
> > > From: Matt Schillinger <mschilli@vss.fsi.com>
> > > To: Steve Dickson <SteveD@RedHat.com>
> > > Subject: Re: [NFS] rpc.mountd problems
> > > Date: 23 Jun 2003 13:57:45 -0500
> > >
> > >
> > >
> > > Here is the results of the exportfs -arv. The exportfs did NOT fix the
> > > stall to clients, followed by a 'Permission Denied', with nothing
> > > registering in messages on the NFSD Server.
> > >
> > > The Server is now running 2.4.20 kernel with a CWD patch for nfsd to
> > > work correctly with older version of IRIX. This problem also existed in
> > > 2.4.19.
> > >
> > > Do file descriptors ever come into the picture?
> > >
> > > [root@thor root]# exportfs -arv
> > > exporting loki:/mnt/test
> > > unexporting philemon:/export/terrex_prototyping from kernel
> > > philemon:/export/terrex_prototyping: Invalid argument
> > > unexporting zippie:/export/terrex_prototyping from kernel
> > > zippie:/export/terrex_prototyping: Invalid argument
> > > unexporting rico:/export/terrex_prototyping from kernel
>
> The simplest explanation for this is that /export/terrex_prototyping
> was exported *before* a filesystem was mounted there.
> e.g.
> exportfs zippie:/export/terrex_prototyping
> mount /dev/sda1 /export/terrex_prototyping
> exportfs -avr
>
> exportfs is trying to unexport the newly mounted filesystem, and the
> kernel is saying that it isn't exported.
> Try unmounting it and running "exportfs" again.
But it WAS mounted prior to exportfs.. hmm.. could /var/lib/nfs/rmtab
entries existing prior to exportfs cause a problem?
I was reading about statd, and the --name option, and came across a
patch by Bruce Allan that deals with statd and multiple interface
machines..
I am not really sure if it's related, but I DO have a multi interfaced
machine..
The config is like this:
Three gigabit interfaces on three separate subnets.
in dns, there is only the name thor.vss.fsi.com that corresponds to the
ips... But another note, is that those ips are bound to ip aliases
(eth0:0, etc).
The actual interface ip addresses all have names associated (thor-200,
thor-400, thor-20).
Could this cause a problem??
One last shot in the dark is that 2 of our Solaris 8 boxes, that act as
nfs clients, are ALSO multi homed, on the same subnets.. Might that
interact badly?
Matt
>
> > >
> > >
> > > The problem is, I don't keep the primary nfs shares in /etc/exports..
> > > (exportfs -arv actually cleared all exports except the ONE that is in
> > > exports that is there to make sure that nfsd starts at boot).
> > >
> > > >From that though, I immediately ran an exportfs -o
> > > rw,async,no_root_squash @vss_grp:/export/vss/db/mv22
> > >
> > > and
> > > exportfs -o rw,async,no_root_squash @vss_grp:/export/terrex_prototyping
> > >
> > > On the nfs server.. this went fine, but the problem still existed on the
> > > clients (permission denied after stall).
>
> Presumably the filehandle the client has doesn't match the filesystem
> you have exported. This could similarly be caused by exporting before
> mounting.
>
> > >
> > > only a restart of rpc.mountd fixed the problem..
> > >
>
> Yep. rpc.mountd thinks it has exported "/export/terrex_prototyping"
> and so wont try to export it again. When you kill and restart it, it
> forgets that it has already exported it, and trys again. This time it
> exports the mounted filesystem and the clients become happy.
>
> > >
> > >
> > > QUESTION: is the "Invalid argument" in the exportfs -arv due to the fact
> > > that the particular mountpoint does not exist in /etc/exports??
> > >
>
> Not directly.
>
>
> NeilBrown
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2003-06-25 17:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-23 19:27 [Fwd: Re: rpc.mountd problems] Matt Schillinger
2003-06-23 21:13 ` Neil Brown
2003-06-25 17:33 ` Matt Schillinger [this message]
2003-06-25 23:35 ` Neil Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1056562429.3941.49.camel@mosix \
--to=mschilli@vss.fsi.com \
--cc=neilb@cse.unsw.edu.au \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.