Re: problems with chown as root on nfs4 export

On May 1, 2014, at 5:48 PM, Rick Macklem <[e-mail]> wrote:

> Craig Yoshioka wrote:
>> I=92ve posted this same email to the linux NFS mailing list since I
>> think it might be client-side problem, but thought I might look for
>> input here as well.
>> =

>> problem: when using chown as root on a nfs4 filesystem on newer linux
>> releases file owners get sets to nobody.
>>        the user type doesn=92t seem to matter (/etc/passwd, LDAP,
>>        Samba4)
>> =

>> setup: Server is FreeBSD 10 system with NFSv4 share.
>>      Server and clients are all configured with the same idmap
>>      domain
>>      Network users have consistent uid/gid on server and clients
>>      clients with older linux releases work OK (Ubuntu 12.04, CentOS
>>      5 and 6)
>>      clients with newer linux releases do not work ( Fedora 20,
>>      Ubuntu 14.04, Mint 16 )
>> =

>> clues:
>> =

>> 1. working and non-working systems get to the same fchownat() system
>> call with the same arguments (via strace).
>> =

>> example (identical on working and non-working client):
>> ...
>> fchownat(AT_FDCWD, "/mnt/test", 11111, 4294967295, 0) =3D 0
>> close(1)                                =3D 0
>> close(2)                                =3D 0
>> close(4)                                =3D 0
>> exit_group(0)                           =3D ?
>> +++ exited with 0 +++
>> =

>> 2. working system sends NFSV4 SETATTR request with owner set to:
>> [e-mail] and non-working as 11111 (via wireshark)
>> =

> Yuck. RFC-3530 strongly encouraged use of <user>@<domain> names
> to identify users. rfc-3530bis (not yet an RFC afaik) "clarified"
> this to allow a server to return the number as a string (something
> done early in NFSv4 development for testing).
> =

> This happened because Linux wanted to put the uid in a string so
> that NFSv4 mounted root file systems could be done more easily.
> (My understanding was that the client is now expected to understand
> a uid in a string, but I didn't think the server was required to
> accept it for a setattr.)
> =


From what I was told, trying a uid string is only a fallback scenario for t=
he client.  Instead, it turns out root (uid 0) was improperly triggering a =
conditional that mapped it to nobody on maproot exports.  I just tried a fi=
xed version and it works now.

> There is a configuration option in the Linux nfsd that disables
> this for the Linux server side (sorry, I can't remember what it is
> and I don't know if this same setting changes client behaviour?).
> =


echo N >/sys/module/nfs/parameters/nfs4_disable_idmapping

was suggested for me on the client-side, which also worked after restarting=
 the idmap service and remounting. =


> This is the first time I've heard of the Linux client putting the
> uid in a string (but I guess I'm not surprised).
> =

> Hopefully there is a mount (or configuration) option that tells
> it to use <user>@<domain> for the mount. If there isn't such a
> beast, changing the server to accept the uid as a string is easy,
> although I thought doing so actually violated RFC-3530.
> (I'll admit I haven't looked closely at a recent draft of
> rfc-3530bis to see what it says. This document wasn't supposed
> to change the protocol, but just clarify it, however I think it
> has gone beyond that.)
> =

> If you can find a mount/configuration option, please email with
> that. If not, email and I'll give you a patch that can optionally
> allow the server to handle the uid in a string.
> =

> rick

It seems it is now fixed, or as a workaround, one can set that client side =
nfs parameter.  I=92m kinda glad FreeBSD didn=92t take the uid because it w=
ould probably have masked the bug.  OTH, it seems sending the uid is still =
a possible fallback.  maybe if the server can=92t find and return a user na=
me?, so it=92s likely FreeBSD NFS4 servers will still get calls with uid st=
rings in the future.

> =

>> =

>> =

>> 3. I can=92t rule out misconfiguration.  but I=92ve configured as
>> identically as I could, and tried a lot of small vairations. these
>> are my current settings (the pipefs settings are the distro
>> defaults)
>> =

>> _______________________________________________
>> [e-mail] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to
>> "[e-mail]"

_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[e-mail]"