Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 Jul 2010 21:07:44 -0400
From:      Joe Auty <joe@netmusician.org>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: NFSv4 permissions issues
Message-ID:  <4C54C8E0.8020504@netmusician.org>
In-Reply-To: <763314735.215468.1280622736448.JavaMail.root@erie.cs.uoguelph.ca>
References:  <763314735.215468.1280622736448.JavaMail.root@erie.cs.uoguelph.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
Rick Macklem wrote:
> From: "Joe Auty" <joe@netmusician.org>
>   
>> To: freebsd-fs@freebsd.org
>> Sent: Wednesday, July 28, 2010 3:31:25 AM
>> Subject: NFSv4 permissions issues
>>
>> Hello,
>>
>> In FreeBSD 8.1 when mounting an NFSv4 share (hosted by Solaris 10/ZFS) I
>> cannot create or alter any files on this share nor any other share
>> mounted from this same ZFS server. When I try to do so I get permission
>> denied error messages. This same share does not give me any problems
>> when mounted with identical mount options except for specifying NFSv3
>> rather than NFSv4... i.e.
>>
>> mount -t nfs -o rw,tcp,intr,noatime,nfsv3 myip:/path /path
>>
>> works fine, and:
>>
>> mount -t nfs -o rw,tcp,intr,noatime,nfsv4 myip:/path /path
>>
>> exhibits the above problems...
>>
>>
>> Any idea why this is so and what I ought to do to test using NFSv4 on
>> this machine?
>>     
>
> 1 - look to see if the username/groupname mappings are working. (NFSv4
> uses name and not#s.)
>     - just do an "ls -lg" on some NFSv4 mounted dir. to see if they
>       look ok. (lotsa "nobdy"'s --> busted) If it's busted, look at
>       the setup of nfsuserd and the "domain" specified, which is
>       usually the domain part of the host's name, but can be overridden
>       by a flag option on nfsuserd and in a config file on Solaris10.
>
> 2 - Make sure you user/group names and uid/gid numbers are consistent
>       between client and server. NFSv4 always specifies the groupname
>       of a newly created file object, so those groups/gids must be
>       correct.
>
> If the above doesn't resolve it, look at a snoop trace for the failed
> access and see what the user/group names (and uid/gid #s in the RPC
> header) look like.
>
> This is most likely something related to the user/group name and
> number mapping, rick
>   

At the time the user/groups were showing up as root:joe. Doing a chown
as root would not generate an error message, it just simply did not
work. There are no numbers appearing the user/group assignments, and
these same permissions work fine when the share is mounted as NFSv3, for
whatever reason. Because I gave root read and write permissions, I
should be able to change the permissions to whatever I want on the
client end, right?

Is snoop trace an strace?



-- 
Joe Auty, NetMusician
NetMusician helps musicians, bands and artists create beautiful,
professional, custom designed, career-essential websites that are easy
to maintain and to integrate with popular social networks.
www.netmusician.org <http://www.netmusician.org>;
joe@netmusician.org <mailto:joe@netmusician.org>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C54C8E0.8020504>