Comment 0 for bug 1101292

"Our home directories are mounted via NFSv4 from a server running AIX 7.1.
After an upgrade of my client from Ubuntu 12.04 to 12.10, 'chgrp' fails when
trying to change a file or directory in my home directory:"

username@1210:~/x$ ls -l newfile
-rw------- 1 username groupname 0 Jan 3 16:56 newfile
username@1210:~/x$ chgrp groupname newfile
chgrp: changing group of `newfile': Invalid argument

groupname is his default group.

username@1210:~/x$ chown -v username newfile
chown: changing ownership of `newfile': Invalid argument
failed to change ownership of `newfile' from username to username

The issue was bisected to:
57e62324e469e092ecc6c94a7a86fe4bd6ac5172 is the first bad commit
commit 57e62324e469e092ecc6c94a7a86fe4bd6ac5172
Author: Bryan Schumaker <email address hidden>
Date: Fri Feb 24 14:14:51 2012 -0500

    NFS: Store the legacy idmapper result in the keyring

    This patch removes the old hashmap-based caching and instead uses a
    "request key actor" to place an upcall to the legacy idmapper rather
    than going through /sbin/request-key. This will only be used as a
    fallback if /etc/request-key.conf isn't configured to use nfsidmap.

    Signed-off-by: Bryan Schumaker <email address hidden>
    Signed-off-by: Trond Myklebust <email address hidden>

:040000 040000 0f16d9ec47ae5135d43213a847a87d21e0571c85 69efedae21cc967b00e36a41f934514250012930 M fs
:040000 040000 c0e64c847a273af358fc1234860c4b07c6325203 3eeac805d6bdd30a486bb2077342c1017dc0e651 M include

In addition, a difference was found in the idmapd logs when set to "Verbosity = 3":
when trying chgrp groupname, syslog differences

Working case on kernel 3.3.3:
rpc.idmapd[676]: Client 5: (user) name "<email address hidden>" -> id "5194"
rpc.idmapd[676]: Client 5: (group) name "<email address hidden>" -> id "100003"
rpc.idmapd[676]: Client 5: (group) id "100003" -> name "<email address hidden>"

Failing case on kernel 3.4-rc1 (3.4-rc first with bug, also would be same with 3.5:
rpc.idmapd[2129]: Client 0: (group) id "100003" -> name "<email address hidden>"

Possibly related side issue that impeded testing:
Mainline kernel 3.5-rc7 and up not able to mount on: mount.nfs4: an incorrect mount option was specified
[ 612.739763] gss_create: Pseudoflavor 390004 not found!
[ 612.739771] RPC: Couldn't create auth handle (flavor 390004)
This is quite confusing to me as 3.5 in Quantal can definitely mound the NFS share.

4. Reproduce steps
 4.1. Mount NFSv4 share on AIX 7.1 with Kerberos krb5i
 4.2. Create new file that you should be able to change ownership of
 4.3. Run chown/chgrp. Note error
 a. Actual Results: chgrp: changing group of `newfile': Invalid argument
 b. Expected Results: file has changed permissions

5. Known Workaround: Use a kernel pre-3.4-rc1

Exports on the AIX server (yes different format then Linux):
/cfs -vers=4,sec=krb5:krb5i:krb5p
/cfs/home -vers=4,sec=krb5:krb5i:krb5p
/cfs/share -vers=4,sec=krb5:krb5i:krb5p

Fstab on client:
cfs-nfs.domainname.com:/ /cfs nfs4 sec=krb5i 0 0