All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.