Description of problem: When exporting /home from a RHEL 5.8 box using nfsv4, I am unable to chown files/directories on the client. For instance, I strace pulseaudio and when pulse tries to fchown the directory, it gets "-1 EPERM (Operation not permitted)": stat("/home/tcameron", {st_mode=S_IFDIR|0701, st_size=4096, ...}) = 0 getuid() = 1001 umask(077) = 022 mkdir("/home/tcameron/.pulse", 0700) = 0 umask(022) = 077 open("/home/tcameron/.pulse", O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 4 fstat(4, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 getuid() = 1001 getgid() = 1001 fchown(4, 1001, 1001) = -1 EPERM (Operation not permitted) rmdir("/home/tcameron/.pulse") = 0 prctl(PR_GET_NAME, 0x1a19fb0, 0x1a19fb0, 0x41, 0) = 0 ioctl(2, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 write(2, "E: [pulseaudio] core-util.c: \33[1"..., 99E: [pulseaudio] core-util.c: Failed to create secure directory: Operation not permitted ) = 99 close(3) = 0 exit_group(1) = ? +++ exited with 1 +++ On a locally mounted home directory, it works: stat("/home/tcameron", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 getuid() = 1001 umask(077) = 02 mkdir("/home/tcameron/.pulse", 0700) = -1 EEXIST (File exists) umask(02) = 077 open("/home/tcameron/.pulse", O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 7 fstat(7, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 getuid() = 1001 getgid() = 1001 fchown(7, 1001, 1001) = 0 fchmod(7, 0700) = 0 close(7) = 0 lstat("/home/tcameron/.pulse", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 open("/var/lib/dbus/machine-id", O_RDONLY|O_CLOEXEC) = 7 fcntl(7, F_GETFD) = 0x1 (flags FD_CLOEXEC) fstat(7, {st_mode=S_IFREG|0644, st_size=33, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe4ca771000 read(7, "7cb9d14f4151e5900b51c9080000000a"..., 4096) = 33 close(7) = 0 munmap(0x7fe4ca771000, 4096) = 0 readlink("/home/tcameron/.pulse/7cb9d14f4151e5900b51c9080000000a-runtime", "/tmp/pulse-3Qn4Ou8LLkRY", 99) = 23 lstat("/tmp/pulse-3Qn4Ou8LLkRY", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 getuid() = 1001 unlink("/home/tcameron/.pulse/7cb9d14f4151e5900b51c9080000000a-runtime/autospawn.lock") = 0 fcntl(5, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0 close(5) = 0 close(3) = 0 close(4) = 0 close(6) = 0 exit_group(0) = ? +++ exited with 0 +++ This time, I get: fchown(7, 1001, 1001) = 0 fchmod(7, 0700) = 0 Here's /etc/exports on the RHEL5 NFSv4 server: /home 172.31.100.0/255.255.255.0(rw,fsid=0,no_root_squash,sync) Here's /etc/idmapd.conf: [General] Domain = tc.redhat.com [Mapping] Nobody-User = nobody Nobody-Group = nobody [Translation] Method = nsswitch [Static] Here's /etc/fstab on the F17 client: 172.31.100.1:/ /home nfs4 rw,sync 0 0 I'll attach the wireshark dump as well. Version-Release number of selected component (if applicable): kernel-2.6.18-308.8.1.el5 How reproducible: mount /home via nfsv4 Steps to Reproduce: See above Actual results: Permission denied when chown-ing a file or directory Expected results: Permission granted. Additional info: None
Created attachment 590992 [details] wireshark dump
Created attachment 590993 [details] sosreport for Fedora 17 client
Created attachment 590998 [details] sosreport from rhel5 server
On a quick glance at git, it looks to me like rhel5 might be missing upstream's bdfe0d28ee4c23dec311423a34b2a3ec65b5b318 "Don't always use default mapping to "nobody"." Steved, can you confirm that? The upshot is that the new client maps your username to a number, expecting the server to return BADOWNER (or the less-correct but nonetheless-will-work BADNAME), in the case where it doesn't support numeric ID's. But instead idmapd incorrectly maps the number to "nobody", and then the operation fails with EPERM. After applying that nfs-utils patch the mapping should fail, the operation should return BAD{OWNER/NAME}, and the client should fall back on using names, which should work.
perhaps related: chown() on NFS4 does not work in Fedora 17 because wrong domain is used. bug #829362
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
(In reply to J. Bruce Fields from comment #4) > On a quick glance at git, it looks to me like rhel5 might be missing > upstream's bdfe0d28ee4c23dec311423a34b2a3ec65b5b318 "Don't always use > default mapping to "nobody"." Steved, can you confirm that? Yes its missing this patch...
(In reply to Steve Dickson from comment #7) > (In reply to J. Bruce Fields from comment #4) > > On a quick glance at git, it looks to me like rhel5 might be missing > > upstream's bdfe0d28ee4c23dec311423a34b2a3ec65b5b318 "Don't always use > > default mapping to "nobody"." Steved, can you confirm that? > Yes its missing this patch... it turns out that this patch is not the problem... The problem is in id/gid mapping routines in libnfsidmap. Unfortunately there is not RHEL5 libnfsidmap git tree... So debugging this, at this point, is not possible. Plus the v4 support in RHEL5 is iffy at best. So i would suggest to move back to v3 or used the v4 in RHEL6.