>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     [email protected]:/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 '[email protected]'. 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 '[email protected]' 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 '[email protected]' 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:
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"

Reply via email to