Hi,
we are missing the "authenticated u/mount request..." messages or
error messages like "refused mount request from /x (/): not exported"
for NFSv4 servers. We were using the mount/umount messages e.g. to
detect when some reached a certain point of an installation etc.
And the error messages on the server side often were more helpful
than the ones on the client.
Is there really no way to get these easy-to-understand messages?
Debugging shows a lot but nothing that e.g. gives an understandable
error reason.
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Tue, Jul 21, 2015 at 03:57:26PM +0200, Frank Steiner wrote:
> we are missing the "authenticated u/mount request..." messages or
> error messages like "refused mount request from /x (/): not exported"
> for NFSv4 servers. We were using the mount/umount messages e.g. to
> detect when some reached a certain point of an installation etc.
> And the error messages on the server side often were more helpful
> than the ones on the client.
>
> Is there really no way to get these easy-to-understand messages?
> Debugging shows a lot but nothing that e.g. gives an understandable
> error reason.
There aren't any mount or umount calls in the NFSv4 protocol.
(For example, an NFSv4 server typically wouldn't have any way to tell
the difference between a client that has unmounted and one that just
isn't using the filesystem right now.)
If you could describe in more detail your use case, someone might be
able to suggest a different solution. Or it might influence what sort
of information the nfs server exports to users in the future.
--b.
With NFSv4.1 there are indirect hints to mount/umount: create and
destroy session.
Tigran.
----- Original Message -----
> From: "J. Bruce Fields" <[email protected]>
> To: "Frank Steiner" <[email protected]>
> Cc: [email protected]
> Sent: Tuesday, July 21, 2015 6:03:38 PM
> Subject: Re: Are there really no server-side mount/umount message for NFSv4?
> On Tue, Jul 21, 2015 at 03:57:26PM +0200, Frank Steiner wrote:
>> we are missing the "authenticated u/mount request..." messages or
>> error messages like "refused mount request from /x (/): not exported"
>> for NFSv4 servers. We were using the mount/umount messages e.g. to
>> detect when some reached a certain point of an installation etc.
>> And the error messages on the server side often were more helpful
>> than the ones on the client.
>>
>> Is there really no way to get these easy-to-understand messages?
>> Debugging shows a lot but nothing that e.g. gives an understandable
>> error reason.
>
> There aren't any mount or umount calls in the NFSv4 protocol.
>
> (For example, an NFSv4 server typically wouldn't have any way to tell
> the difference between a client that has unmounted and one that just
> isn't using the filesystem right now.)
>
> If you could describe in more detail your use case, someone might be
> able to suggest a different solution. Or it might influence what sort
> of information the nfs server exports to users in the future.
>
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
J. Bruce Fields wrote
> There aren't any mount or umount calls in the NFSv4 protocol.
Ok.
> (For example, an NFSv4 server typically wouldn't have any way to tell
> the difference between a client that has unmounted and one that just
> isn't using the filesystem right now.)
>
> If you could describe in more detail your use case, someone might be
> able to suggest a different solution. Or it might influence what sort
> of information the nfs server exports to users in the future.
The case where we watched the log file is very very specific and nothing
that could not be solved otherwise. My main point was that we sometimes
ran into "could not mount blabla" on the client, and then the server
often gave a more detailed messages pointing us to the error. E.g. in
NFSv4 we made a mistake by exporting our /nfsv4/ root, bind-mounted
/nfsv4/x/ and exported onlt /nfsv4/ and /nfsv4/x/y to some client.
Without any helpful error messages it took us some time to figure
out that we had to export the whole bind-mount /nfsv4/x to the
client or make another bindmount only for the /x/y/ subdir.
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Wed, Jul 22, 2015 at 02:13:59PM +0200, Frank Steiner wrote:
> J. Bruce Fields wrote
>
> > There aren't any mount or umount calls in the NFSv4 protocol.
>
> Ok.
>
> > (For example, an NFSv4 server typically wouldn't have any way to tell
> > the difference between a client that has unmounted and one that just
> > isn't using the filesystem right now.)
> >
> > If you could describe in more detail your use case, someone might be
> > able to suggest a different solution. Or it might influence what sort
> > of information the nfs server exports to users in the future.
>
> The case where we watched the log file is very very specific and nothing
> that could not be solved otherwise. My main point was that we sometimes
> ran into "could not mount blabla" on the client, and then the server
> often gave a more detailed messages pointing us to the error. E.g. in
> NFSv4 we made a mistake by exporting our /nfsv4/ root, bind-mounted
> /nfsv4/x/ and exported onlt /nfsv4/ and /nfsv4/x/y to some client.
> Without any helpful error messages it took us some time to figure
> out that we had to export the whole bind-mount /nfsv4/x to the
> client or make another bindmount only for the /x/y/ subdir.
Hm. In this case I think there'd be evidence of the failure left in
/proc/net/rpc/nfsd.fh/content, though only after you turned on some rpc
debugging, which isn't something you'd want some program doing behind
your back. There'd also be an upcall to rpc.mountd (at least on the
first failure), so simplest might be to add some optional logging there.
Might be worth looking into. (I'm not volunteering for now.)
--b.
On Wed, Jul 22, 2015 at 09:31:24AM +0200, Mkrtchyan, Tigran wrote:
> With NFSv4.1 there are indirect hints to mount/umount: create and
> destroy session.
Yes, not sure that would have helped Frank in this case, but it'd be
useful some day to be able to e.g. query information about clients that
currently have established session (or other state).
--b.
>
> Tigran.
>
> ----- Original Message -----
> > From: "J. Bruce Fields" <[email protected]>
> > To: "Frank Steiner" <[email protected]>
> > Cc: [email protected]
> > Sent: Tuesday, July 21, 2015 6:03:38 PM
> > Subject: Re: Are there really no server-side mount/umount message for NFSv4?
>
> > On Tue, Jul 21, 2015 at 03:57:26PM +0200, Frank Steiner wrote:
> >> we are missing the "authenticated u/mount request..." messages or
> >> error messages like "refused mount request from /x (/): not exported"
> >> for NFSv4 servers. We were using the mount/umount messages e.g. to
> >> detect when some reached a certain point of an installation etc.
> >> And the error messages on the server side often were more helpful
> >> than the ones on the client.
> >>
> >> Is there really no way to get these easy-to-understand messages?
> >> Debugging shows a lot but nothing that e.g. gives an understandable
> >> error reason.
> >
> > There aren't any mount or umount calls in the NFSv4 protocol.
> >
> > (For example, an NFSv4 server typically wouldn't have any way to tell
> > the difference between a client that has unmounted and one that just
> > isn't using the filesystem right now.)
> >
> > If you could describe in more detail your use case, someone might be
> > able to suggest a different solution. Or it might influence what sort
> > of information the nfs server exports to users in the future.
> >
> > --b.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html