public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Mau <mau@oscar.ping.de>
To: "Malte Schröder" <MalteSch@gmx.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PROBLEM] [2.6.0-test6] Stale NFS file handle
Date: Sun, 28 Sep 2003 22:47:53 +0200	[thread overview]
Message-ID: <20030928204753.GA28255@oscar.prima.de> (raw)
In-Reply-To: <200309282031.54043.MalteSch@gmx.de>

On Sun, Sep 28, 2003 at 08:30:50PM +0200, Malte Schröder wrote:
> Hi,
> since 2.6.0-test6 I get "Stale NFS file handle" when transferring
> huge amounts of data from a nfs-server which is running on -test6.
> The client also runs -test6. Transfers from a server running kernel 2.4.22 
> work flawless.
> 
> I use the nfs-kernel-server 1.0.6 on Debian/sid.

Hallo Malte,
Hallo list-members,

my solution for getting a reliable NFS Server with 2.5 kernels was
to use "no_subtree_check" in /etc/exports.

(The next thing is pasted, please read below the code)

I stumbled over the following lines of code in fs/nfsd/nfsfh.c:

int nfsd_acceptable(void *expv, struct dentry *dentry)
{
        struct svc_export *exp = expv;
        int rv;
        struct dentry *tdentry;
        struct dentry *parent;

        if (exp->ex_flags & NFSEXP_NOSUBTREECHECK)
                return 1;

        tdentry = dget(dentry);
        while (tdentry != exp->ex_dentry && ! IS_ROOT(tdentry)) {
                /* make sure parents give x permission to user */
                int err;
                parent = dget_parent(tdentry);
                err = permission(parent->d_inode, S_IXOTH, NULL);
                                                  ^^^^^^^ <- !!!!
                if (err < 0) {
                        dput(parent);
                        break;
                }

First, nfsd_acceptable always returns success if subtree_checks are
diabled. Second, I think, the line marked above is not correct.

The comment says "give x permission to user", but the call looks
suspiciously wrong.

You can also make the error disappear by allowing setting all x bits
for "other" from your mount-point down to the directory where the error
appears.

Echoing "32767" to /proc/sys/sunrpx/nfs_debug helped me a great deal
to find that error.

Cheers,
Patrick

  parent reply	other threads:[~2003-09-28 20:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-28 18:30 [PROBLEM] [2.6.0-test6] Stale NFS file handle Malte Schröder
2003-09-28 18:48 ` Axel Siebenwirth
2003-09-29 17:42   ` Malte Schröder
2003-09-29 20:06   ` bill davidsen
2003-09-28 20:47 ` Patrick Mau [this message]
2003-09-29 18:58   ` Patrick Mau
2003-09-30  4:41     ` Malte Schröder
2003-10-16  5:17   ` Neil Brown

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=20030928204753.GA28255@oscar.prima.de \
    --to=mau@oscar.ping.de \
    --cc=MalteSch@gmx.de \
    --cc=linux-kernel@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