From: "J. Bruce Fields" <bfields@fieldses.org>
To: Peter Horvath <peter.horvath77@googlemail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: NFSv4 client restriction
Date: Wed, 22 Feb 2012 20:45:14 -0500 [thread overview]
Message-ID: <20120223014514.GA19890@fieldses.org> (raw)
In-Reply-To: <CAO9xhuZhtC8nWOhLjqG0iBRyvVN4ap7XqeD=hYHRR_29LBZpGA@mail.gmail.com>
On Thu, Feb 23, 2012 at 01:24:35AM +0000, Peter Horvath wrote:
> It is a vmware RDM disk mounted /srv
> It is the same filesystem.
> Do you say this config would work if i use separate partition for the
> separate directories?
Yes, I expect so.
--b.
>
> On 23 February 2012 01:01, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Wed, Feb 22, 2012 at 07:24:12PM +0000, Peter Horvath wrote:
> >> We are using Ubuntu LTS 10.04 servers and clients.
> >> NFS version is the following:
> >> nfs-common 1.2.0-4ubuntu4.2
> >> nfs-kernel-server 1.2.0-4ubuntu4.2
> >>
> >> My exports looks like this:
> >>
> >> /srv 10.66.3.0/24(fsid=0,ro,no_subtree_check,sync)
> >> /srv/www/project1 10.66.3.101(rw,no_root_squash,no_subtree_check,sync)
> >> /srv/www/project2 10.66.3.102(rw,no_root_squash,no_subtree_check,sync)
> >> /srv/www/project3 10.66.3.103(rw,no_root_squash,no_subtree_check,sync)
> >>
> >> My problem is that in this case clients have only read-only access. If
> >> i set the pseudofilesystem root to RW it is working but in that case
> >> all the clients would be able to mount the root and access other
> >> projects too.
> >> How can i achieve the same results as it was in NFSv3 with this config.
> >>
> >> /srv/www/project1 10.66.3.101(rw,no_root_squash,no_subtree_check,sync)
> >> /srv/www/project2 10.66.3.102(rw,no_root_squash,no_subtree_check,sync)
> >> /srv/www/project3 10.66.3.103(rw,no_root_squash,no_subtree_check,sync)
> >
> > Are project1, 2, 3 on the same filesystem as /srv and /srv/www?
> >
> > If so, this is expected; create a separate partition for /srv/www, or
> > for each project1, 2, 3 directory, and you may find the problem is
> > fixed.
> >
> > If that doesn't fix the problem, it may be a bug. We've fixed a few
> > bugs in that area lately, so it would be worth retrying with more recent
> > kernel and nfs-utils.
> >
> > --b.
next prev parent reply other threads:[~2012-02-23 1:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 19:24 NFSv4 client restriction Peter Horvath
2012-02-23 1:01 ` J. Bruce Fields
2012-02-23 1:24 ` Peter Horvath
2012-02-23 1:45 ` J. Bruce Fields [this message]
2012-02-23 7:09 ` steve
2012-02-23 10:25 ` Peter Horvath
2012-02-23 14:16 ` Daniel Kahn Gillmor
2012-02-23 15:42 ` steve
2012-02-29 22:32 ` 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=20120223014514.GA19890@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=peter.horvath77@googlemail.com \
/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.