problems with chown as root on nfs4 export

[Craig Yoshioka]

On May 1, 2014, at 5:48 PM, Rick Macklem <rmacklem at uoguelph.ca> wrote:

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

From what I was told, trying a uid string is only a fallback scenario for the 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 fixed 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’m kinda glad FreeBSD didn’t take the uid because it would probably have masked the bug.  OTH, it seems sending the uid is still a possible fallback.  maybe if the server can’t find and return a user name?, so it’s likely FreeBSD NFS4 servers will still get calls with uid strings in the future.

> 
>> 
>> 
>> 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"