public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Shehjar Tikoo <shehjart-+FkPdpiNhgJBDgjK7y7TUQ@public.gmane.org>
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Linux client mount fails with Gluster NFSv3 server
Date: Mon, 31 Aug 2009 19:37:07 +0530	[thread overview]
Message-ID: <4A9BD90B.4090804@gluster.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

Hi All

I am writing a NFSv3 server as part of the Gluster clustered FS.
To start with, I've implemented the Mountv3 protocol and am just
starting out with NFSv3. In NFSv3, the first thing I've implemented
is the FSINFO and GETATTR calls to support mounting with NFS client.

The problem I am facing is this. The Linux NFS client fails to mount
the remote export even though it is successfully receiving the file
handle from the MNT request and the result of the FSINFO call. This
is shown in the attached pcap file, which would be best viewed through
wireshark with "rpc" as the display filter.

The command line output is shown below:

root@indus:statcache# mount 127.0.0.1:/pos1 /mnt -o noacl,nolock
mount.nfs: mounting 127.0.0.1:/pos1 failed, reason given by server:
   No such file or directory

This happens even though, we're told the following by showmount.
root@indus:statcache# showmount -e
Export list for indus:
/pos1 (everyone)
/pos2 (everyone)
/pos3 (everyone)
/pos4 (everyone)
root@indus:statcache#

..where /pos1, /pos2, etc are exports from the locally running Gluster
NFS server.

As you'll notice in the trace, there is no NFSv3 request after
the FSINFO, so I've a feeling it could be that some field in the
FSINFO reply is not what the Linux NFS client is expecting. Could that
be the reason for the mount failure?

What else should I be looking into to investigate this further?

The client is a 2.6.18-5 kernel supplied with Debian on an AMD64 box.
nfs-utils is version 1.1.4.

Many thanks,
-Shehjar

[-- Attachment #2: mount.dump --]
[-- Type: application/octet-stream, Size: 6718 bytes --]

             reply	other threads:[~2009-08-31 14:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-31 14:07 Shehjar Tikoo [this message]
     [not found] ` <4A9BD90B.4090804-+FkPdpiNhgJBDgjK7y7TUQ@public.gmane.org>
2009-08-31 17:12   ` Linux client mount fails with Gluster NFSv3 server Trond Myklebust
     [not found]     ` <1251738771.5144.21.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-09-01  6:39       ` Shehjar Tikoo
     [not found]         ` <4A9CC186.10504-+FkPdpiNhgJBDgjK7y7TUQ@public.gmane.org>
2009-09-01 12:26           ` Trond Myklebust
     [not found]             ` <1251807998.18608.1.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-09-01 13:13               ` Shehjar Tikoo
2009-09-01 16:43               ` J. Bruce Fields
2009-08-31 19:26   ` J. Bruce Fields

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=4A9BD90B.4090804@gluster.com \
    --to=shehjart-+fkpdpinhgjbdgjk7y7tuq@public.gmane.org \
    --cc=linux-nfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox