NFSv4 client restriction

NFSv4 client restriction

[Peter Horvath]

Hi,

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)

I wasn't able to find any solution on the net and forums so far.

All help would be appreciated.

Thank you

Re: NFSv4 client restriction

[J. Bruce Fields]

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.

Re: NFSv4 client restriction

[Peter Horvath]

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?

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.

Re: NFSv4 client restriction

[J. Bruce Fields]

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.

Re: NFSv4 client restriction

[steve]

On 02/23/2012 02:01 AM, J. Bruce Fields 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.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

It is not recommended to use the pseudoroot fsid=0 stuff for Linux.

See the nfs wiki: 'The linux implementation allows you to designate a 
real filesystem as the pseudofilesystem, identifying that export with 
the fsid=0 option; we no longer recommend this. Instead, on any recent 
linux distribution, just list exports in /etc/exports exactly as you 
would for NFSv2 or NFSv3.'

HTH
Steve

Re: NFSv4 client restriction

[Peter Horvath]

On ubuntu 10.04 with the repository installs of the packages:
mount.nfs4 10.66.3.101:/srv/www/test /srv -v
mount.nfs4: timeout set for Thu Feb 23 10:24:10 2012
mount.nfs4: text-based options: 'clientaddr=10.66.3.102,addr=10.66.3.101'
mount.nfs4: mount(2): No such file or directory
mount.nfs4: mounting 10.66.3.101:/srv/www/test failed, reason given by server:
  No such file or directory

mount.nfs 10.66.3.101:/srv/www/test /srv -v
mount.nfs: timeout set for Thu Feb 23 10:24:32 2012
mount.nfs: text-based options: 'addr=10.66.3.101'
10.66.3.101:/srv/www/test on /srv type nfs

Which means i can mount with nfsv3 but i am not able to mount with
nfsv4 without fsid=0
I will try bruce idea with different partitions as shared directories.

Peter

On 23 February 2012 07:09, steve <steve@steve-ss.com> wrote:
> On 02/23/2012 02:01 AM, J. Bruce Fields 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.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> It is not recommended to use the pseudoroot fsid=0 stuff for Linux.
>
> See the nfs wiki: 'The linux implementation allows you to designate a real
> filesystem as the pseudofilesystem, identifying that export with the fsid=0
> option; we no longer recommend this. Instead, on any recent linux
> distribution, just list exports in /etc/exports exactly as you would for
> NFSv2 or NFSv3.'
>
> HTH
> Steve
>

Re: NFSv4 client restriction

[Daniel Kahn Gillmor]

On 02/23/2012 02:09 AM, steve wrote:
> It is not recommended to use the pseudoroot fsid=0 stuff for Linux.
> 
> See the nfs wiki: 'The linux implementation allows you to designate a
> real filesystem as the pseudofilesystem, identifying that export with
> the fsid=0 option; we no longer recommend this. Instead, on any recent
> linux distribution, just list exports in /etc/exports exactly as you
> would for NFSv2 or NFSv3.'

I believe the last time this came up, i asked for a rationale or
explanation.  The only reason given [0] was from J. Bruce Fields:

>> The main problem with the fsid=0 trick is that your v3 and v4 clients
>> end up with different paths.

So, if you have no v3 clients, i don't think there is any reason to
avoid fsid=0 if it makes things cleaner for you.  And removing fsid=0
will require you to change /etc/fstab (or your automounter config) in
all of your clients.

	--dkg

[0] http://thread.gmane.org/gmane.linux.nfs/46932/focus=46944

Re: NFSv4 client restriction

[steve]

On 02/23/2012 03:16 PM, Daniel Kahn Gillmor wrote:
> On 02/23/2012 02:09 AM, steve wrote:
>> It is not recommended to use the pseudoroot fsid=0 stuff for Linux.
>>
>> See the nfs wiki: 'The linux implementation allows you to designate a
>> real filesystem as the pseudofilesystem, identifying that export with
>> the fsid=0 option; we no longer recommend this. Instead, on any recent
>> linux distribution, just list exports in /etc/exports exactly as you
>> would for NFSv2 or NFSv3.'
> I believe the last time this came up, i asked for a rationale or
> explanation.  The only reason given [0] was from J. Bruce Fields:
I've never got to the bottom of this one either. I only know that it works.
>>> The main problem with the fsid=0 trick is that your v3 and v4 clients
>>> end up with different paths.
But if say, you're exporting /home and have /home bind mounted to your 
pseudoroot, then the paths are exactly the same. You still mount -t nfsx 
server:/home /client/somewhere for x=3 or x=4. No?
> So, if you have no v3 clients, i don't think there is any reason to
> avoid fsid=0 if it makes things cleaner for you.  And removing fsid=0
> will require you to change /etc/fstab (or your automounter config) in
> all of your clients.
Please accept my apologies for butting in on this. I'm simply trying to 
get some facts together.
Cheers,
Steve

Re: NFSv4 client restriction

[J. Bruce Fields]

On Thu, Feb 23, 2012 at 04:42:46PM +0100, steve wrote:
> On 02/23/2012 03:16 PM, Daniel Kahn Gillmor wrote:
> >On 02/23/2012 02:09 AM, steve wrote:
> >>It is not recommended to use the pseudoroot fsid=0 stuff for Linux.
> >>
> >>See the nfs wiki: 'The linux implementation allows you to designate a
> >>real filesystem as the pseudofilesystem, identifying that export with
> >>the fsid=0 option; we no longer recommend this. Instead, on any recent
> >>linux distribution, just list exports in /etc/exports exactly as you
> >>would for NFSv2 or NFSv3.'
> >I believe the last time this came up, i asked for a rationale or
> >explanation.  The only reason given [0] was from J. Bruce Fields:
> I've never got to the bottom of this one either. I only know that it works.
> >>>The main problem with the fsid=0 trick is that your v3 and v4 clients
> >>>end up with different paths.
> But if say, you're exporting /home and have /home bind mounted to
> your pseudoroot, then the paths are exactly the same. You still
> mount -t nfsx server:/home /client/somewhere for x=3 or x=4. No?

I suppose that'll work, though it's a little messy: if someone looks at
your exports e.g.  with shomwount it'll look like:

	# showmount -e myserver
	export list for myserver:
	/home *
	/path/to/pseudoroot/home *

And v4 clients who try to mount the latter will get an error.

--b.

> >So, if you have no v3 clients, i don't think there is any reason to
> >avoid fsid=0 if it makes things cleaner for you.  And removing fsid=0
> >will require you to change /etc/fstab (or your automounter config) in
> >all of your clients.
> Please accept my apologies for butting in on this. I'm simply trying
> to get some facts together.
> Cheers,
> Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html