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=E2=80=99ve 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. >=20 > problem: when using chown as root on a nfs4 filesystem on newer linux > releases file owners get sets to nobody. > the user type doesn=E2=80=99t seem to matter (/etc/passwd, LDAP, > Samba4) >=20 > 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 ) >=20 > clues: >=20 > 1. working and non-working systems get to the same fchownat() system > call with the same arguments (via strace). >=20 > 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 +++ >=20 > 2. working system sends NFSV4 SETATTR request with owner set to: > matlab@nimgs.com and non-working as 11111 (via wireshark) >=20 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 >=20 >=20 > 3. I can=E2=80=99t rule out misconfiguration. but I=E2=80=99ve configure= d as > identically as I could, and tried a lot of small vairations. these > are my current settings (the pipefs settings are the distro > defaults) >=20 > _______________________________________________ > 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" >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1901966946.615625.1398991683337.JavaMail.root>