misc/173479: chown and chgrp operations fail between FreeBSD 9.1
>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:
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"