Run cpcmd misc:release-fsghost /usr/sbin/postdrop. Given the timestamp of that file and last package release September 2024, it’s an old file handle.
# ls -l /usr/sbin/postdrop /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/sbin/postdrop /home/virtual/site268/{fst,shadow}/usr/sbin/postdrop
ls: cannot access '/home/virtual/site268/shadow/usr/sbin/postdrop': No such file or directory
-rwxr-sr-x 2 root postdrop 312512 Nov 21 23:47 /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/sbin/postdrop
-rwxr-sr-x 2 root postdrop 312512 Nov 21 23:47 /home/virtual/site268/fst/usr/sbin/postdrop
-rwxr-sr-x 2 root postdrop 312512 Nov 21 23:47 /usr/sbin/postdrop
File attributes should agree between FST, vfs, and rootfs as in the above example.
The fact there’s zero hardlinks would be your first hint something is askew, which means there’s no physical reference to that file on disk presently. Terminating all processes that hold an open file handle will allow the layer to refresh and that should fix the setuid permissions as well once the updated postdrop binary propagates.
