problems with chown as root on nfs4 export

[Rick Macklem]

Craig Yoshioka wrote:
> I’ve 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’t 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) = 0
> close(1)                                = 0
> close(2)                                = 0
> close(4)                                = 0
> exit_group(0)                           = ?
> +++ exited with 0 +++
> 
> 2. working system sends NFSV4 SETATTR request with owner set to:
> matlab at nimgs.com 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.)

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?).

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

> 
> 
> 3. I can’t rule out misconfiguration.  but I’ve 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)
> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe at freebsd.org"
>