From owner-freebsd-fs@FreeBSD.ORG Fri Nov 13 09:28:52 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 572E7106566C for ; Fri, 13 Nov 2009 09:28:52 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id D8EB88FC0C for ; Fri, 13 Nov 2009 09:28:51 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id nAD9Smwi031787; Fri, 13 Nov 2009 10:28:49 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id A569F4F; Fri, 13 Nov 2009 10:28:48 +0100 (CET) Date: Fri, 13 Nov 2009 10:28:48 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Rick Macklem Message-Id: <20091113102848.4a8298e8.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <20091112182414.cebec1df.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.11.13.91539 Cc: freebsd-fs@freebsd.org Subject: Re: nfsv4 FreeBSD server vs. Linux client I/O error X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 09:28:52 -0000 On Thu, 12 Nov 2009 14:45:04 -0500 (EST) Rick Macklem wrote about Re: nfsv4 FreeBSD server vs. Linux client I/O error: RM> A few things to check on the server: RM> - Did you add a "V4:" line to your /etc/exports and what did you set as RM> the root path in it? If you used "V4: /" then the root file system RM> would need to be exported by another line in /etc/exports for it to RM> work. RM> RM> - If you are only exporting another filesystem, lets say "/exports", RM> then your mount command would have to look like: RM> mount -t nfs4 /exports /mnt RM> (assuming "V4: /" was used) I think I do not yet understand the last part. How do I restrict the export of... oh, I guess I see. If I put / in the exports list, this will merely only allow for the full path still being used on the client side, but I have still to add the file systems actually to be exported. I was wondering about the notes in the manpages about this. RM> - If you used "V4: /exports", then "mount -t nfs4 :/ /mnt" RM> would work and you would see /exports at /mnt. However, this is exactly the way I went. My exports line on my server (cliff) looks like this: V4: /tank -network 192.168.0.0 -mask 255.255.0.0 On the client I try to mount like this: --- pt-ws1 ~ # time mount -t nfs4 cliff:/ /mnt real 0m30.005s user 0m0.000s sys 0m0.002s --- As you see, there is a timeout of about 30s involved. After that the nfs appears to be there: pt-ws1 ~ # mount [...] nfsd (rw) cliff:/ on /mnt type nfs4 (rw,addr=192.168.33.96,clientaddr=192.168.32.3) But it cannot be accessed: pt-ws1 ~ # ls /mnt ls: cannot open directory /mnt: Input/output error Unmounting gives the same timeout, but afterwards the nfs mount is indeed unmounted: pt-ws1 ~ # time umount /mnt real 0m30.002s user 0m0.001s sys 0m0.001s RM> Beyond something like the above, if you capture packets using RM> "tcpdump -s 0 -w host " on the server and then RM> email me "", I can take a look at it. (tcpdump doesn't know RM> diddly about NFSv4, but wireshark does and can handle tcpdump RM> captures.) I will do that, thanks. cu Gerrit