From patchwork Fri May 10 21:54:45 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 10939625 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E3F5314B6 for ; Fri, 10 May 2019 21:54:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D33D51FE84 for ; Fri, 10 May 2019 21:54:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C74861FE95; Fri, 10 May 2019 21:54:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4D9E81FE84 for ; Fri, 10 May 2019 21:54:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728160AbfEJVys (ORCPT ); Fri, 10 May 2019 17:54:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:43956 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727828AbfEJVys (ORCPT ); Fri, 10 May 2019 17:54:48 -0400 Received: from tleilax.poochiereds.net (cpe-71-70-156-158.nc.res.rr.com [71.70.156.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6DEDE217D6; Fri, 10 May 2019 21:54:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557525287; bh=OlL2+v8U1rTwUryIIhYhCqJpysGNxtNHY09Fq/O9t74=; h=From:To:Cc:Subject:Date:From; b=eYUM6pqOPCLapV1ItJQzqJ8LffhgN/N4pizwCd4w7L2S+lSGBXP6iJKprYgMaE15R OUlfjdPfcYDT6dFIeKU1+AEYrmVWOGgHZ7uZf2EUmbn/C6eEs4SwD3EQbofkFczfs0 9wRCnyFzUU7KdSHgLQ4k1yJ9Vj/Qo68jV9bMnei0= From: Jeff Layton To: steved@redhat.com Cc: linux-nfs@vger.kernel.org, jfajerski@suse.com Subject: [PATCH] manpage: explain why showmount doesn't really work against a v4-only server Date: Fri, 10 May 2019 17:54:45 -0400 Message-Id: <20190510215445.1823-1-jlayton@kernel.org> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Jeff Layton I occasionally see people that expect valid info when running showmount against a server that may export some or all filesystems via NFSv4. Let's make it clear that it only works by talking to the remote MNT service, and that that may not be available from a v4-only server. Cc: Jan Fajerski Signed-off-by: Jeff Layton --- utils/showmount/showmount.man | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/utils/showmount/showmount.man b/utils/showmount/showmount.man index a2f510fb5617..35818e1b61c5 100644 --- a/utils/showmount/showmount.man +++ b/utils/showmount/showmount.man @@ -56,5 +56,10 @@ Because .B showmount sorts and uniqs the output, it is impossible to determine from the output whether a client is mounting the same directory more than once. +.P +.B showmount +works by contacting the server's MNT service directly. NFSv4-only servers have +no need to advertise their exported root filehandles via this method, and may +not expose their MNT service to clients. .SH AUTHOR Rick Sladkey