From owner-freebsd-stable@FreeBSD.ORG Fri May 2 00:48:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFBCF319 for ; Fri, 2 May 2014 00:48:11 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7384D1123 for ; Fri, 2 May 2014 00:48:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEABvqYlODaFve/2dsb2JhbABQCoNVV4JnujWGbVGBKnSCJQEBAQMBAQEBICsgCxsYAgINGQIpAQkmBggHBAEcBIgYCA2mAaN0F4EqjEYGCgIBGwEzB4JvgUoEllKEGZEzg08hMYE9 X-IronPort-AV: E=Sophos;i="4.97,968,1389762000"; d="scan'208";a="119794100" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 01 May 2014 20:48:03 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 552D9B3F44; Thu, 1 May 2014 20:48:03 -0400 (EDT) Date: Thu, 1 May 2014 20:48:03 -0400 (EDT) From: Rick Macklem To: Craig Yoshioka Message-ID: <1901966946.615625.1398991683337.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: problems with chown as root on nfs4 export MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 00:48:12 -0000 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 @ 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 @ 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