Example usecase, inside a nfs3 mounted volume: # cp /bin/ls /somenfsmount/ls # chmod 4540 /somenfsmount/ls (/somenfsmount/ls does have 4540 now) # strip /somenfsmount/ls (/somenfsmount/ls has 0540 now!) This only seems to happen on NFS mounted volumes if the user has no write (ugo-w) access to the file to strip. root can strip anyway, but the sticky bits are reset unless the file is writable. 7555 -> 1555 but 7755 -> 7755 and 7311 -> 7311 This effectively is a showstopper for using emerge on nfs root, when binaries are u-w for root like wireshark (/usr/bin/dumpcap, 6550) or virtualbox-bin. This problem seems to be closely related to NFS and to strip but while I don't know the expected behaviour it might as well just being portage that should strip binaries _before_ calling fperms? sys-devel/binutils-2.19.1-r1 sys-apps/portage-2.2_rc33 Reproducible: Always Steps to Reproduce:
not specific to binutils/strip in any way. nfs itself is resetting these perms. simple test code shows the differences between ext3 and nfs mounts $ ./a.out /mnt/ext3/foo /mnt/ext3/foo does not exist mode of /mnt/ext3/foo: 104540 mode of /mnt/ext3/foo: 104540 $ ./a.out /mnt/nfs/foo /mnt/nfs/foo does not exist mode of /mnt/nfs/foo: 104540 mode of /mnt/nfs/foo: 100540
Created attachment 203561 [details] simple test code
Wow, that is interesting, thanks for breaking that down. Do you know if that is a feature or a bug? NFSv4 does not seem to have this issue but rootfs on NFSv4 is not supported. Doesn't that affect all thinclient installations using nfsroot?
I work around this issue by adding nostrip to FEATURES, but it isn't an ideal solution.
