misc/173479: chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client

Jason Keltz jas at cse.yorku.ca
Thu Nov 8 17:20:01 UTC 2012

>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
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 08 17:20:00 UTC 2012
>Originator:     Jason Keltz
>Release:        9.1RC3
FreeBSD f.cs.yorku.ca 9.1-RC3 FreeBSD 9.1-RC3 #0 r242324: Tue Oct 30 00:58:57 UTC 2012     root at farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

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 at 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 at domainname string.

When the server returns the uid on chown its '1004 at 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 at 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.

RHEL63 client as root on NFSv4 share: touch file
RHEL63 client 15 seconds later: ll file



More information about the freebsd-bugs mailing list