Date: Thu, 1 May 2014 20:48:03 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Craig Yoshioka <craigyk@me.com> Cc: freebsd-stable@freebsd.org Subject: Re: problems with chown as root on nfs4 export Message-ID: <1901966946.615625.1398991683337.JavaMail.root@uoguelph.ca> In-Reply-To: <CC0E663B-B8F1-41C8-950B-AA949BA25F0A@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1901966946.615625.1398991683337.JavaMail.root>