From owner-freebsd-bugs@FreeBSD.ORG Thu Nov 8 17:20:01 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93CBE28E for ; Thu, 8 Nov 2012 17:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 68D808FC14 for ; Thu, 8 Nov 2012 17:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA8HK1GW054197 for ; Thu, 8 Nov 2012 17:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA8HK1nv054196; Thu, 8 Nov 2012 17:20:01 GMT (envelope-from gnats) Resent-Date: Thu, 8 Nov 2012 17:20:01 GMT Resent-Message-Id: <201211081720.qA8HK1nv054196@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Jason Keltz Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6EEF3D8 for ; Thu, 8 Nov 2012 17:12:52 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 559E68FC0A for ; Thu, 8 Nov 2012 17:12:52 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.5/8.14.5) with ESMTP id qA8HCphY032543 for ; Thu, 8 Nov 2012 17:12:51 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.5/8.14.5/Submit) id qA8HCpBL032542; Thu, 8 Nov 2012 17:12:51 GMT (envelope-from nobody) Message-Id: <201211081712.qA8HCpBL032542@red.freebsd.org> Date: Thu, 8 Nov 2012 17:12:51 GMT From: Jason Keltz To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: misc/173479: chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:20:01 -0000 >Number: 173479 >Category: misc >Synopsis: chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Nov 08 17:20:00 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Jason Keltz >Release: 9.1RC3 >Organization: >Environment: FreeBSD f.cs.yorku.ca 9.1-RC3 FreeBSD 9.1-RC3 #0 r242324: Tue Oct 30 00:58:57 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: I have a FreeBSD 9.1RC3 NFSv4 server exporting a share to a Red Hat 6.3 NFSv4 client. The user and group mapping is working well. The share has enabled root write access. If root writes a file from the RH63 client, the file becomes owned by "root" as would be expected. However, if "root" then tries to chown the file from the client to a user "j" (uid 1004), it becomes owned by "nobody". (A similar thing happens with the chgrp operation). I assumed that the problem was the Red Hat NFSv4 client, and spoke to an NFS expert from Red Hat. He helped me to identify exactly what was happening... When the client does the 'chown j FILE', the uid that is sent to the server is '1004' not 'j@cs.yorku.ca'. This was a recent change that was backported to RHEL from upstream. The client will first try a uid_string. If the server accepts it, so be it. If not, the client will retry with the name@domainname string. When the server returns the uid on chown its '1004@cs.yorku.ca' which the client seems to ignore which the reason that 'll FILE' shows the correct username for a few moments. But after the attribute cache expires and a 'll FILE' is done again, the server again returns the '1004@cs.yorku.ca' string. This is when the id mapping fails and the owner is set to 'nobody' The same test was done between a RH63 NFSv4 client and server, and the same problem does not exist. >How-To-Repeat: RHEL63 client as root on NFSv4 share: touch file RHEL63 client 15 seconds later: ll file >Fix: >Release-Note: >Audit-Trail: >Unformatted: