Are there really no server-side mount/umount message for NFSv4?
Subsystems (2)
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
Signature · 5 lines
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. *
Quoted 10 lines · Frank Steiner
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 -----
Quoted 33 lines
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?Quoted 10 lines · Frank Steiner
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
Quoted 2 lines · Tigran
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.
Quoted 37 lines
Tigran.
----- Original Message -----
Quoted 33 lines
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?Quoted 10 lines · Frank Steiner
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
Quoted 1 line
There aren't any mount or umount calls in the NFSv4 protocol.
Ok.
Quoted 7 lines
(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
Signature · 5 lines
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. *
Quoted 14 lines · Frank Steiner
J. Bruce Fields wrote
Quoted 1 line
There aren't any mount or umount calls in the NFSv4 protocol.
Ok.
Quoted 7 lines
(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.
Quoted 9 lines
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.