Every good bugreport should start with an error, so here is one :) olympia stefaan.ulyssis.org # pwd /afs/stefaan.ulyssis.org olympia stefaan.ulyssis.org # find > /dev/null find: WARNING: Hard link count is wrong for .: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched. find: ./homes/sderoeck/OldFiles/OldFiles: No such device find: ./homes/vergauwe/OldFiles/OldFiles: No such device ... and so on olympia stefaan.ulyssis.org # /tmp/find > /dev/null olympia stefaan.ulyssis.org # Where /tmp/find is, in my opinion, a partially fixed version. Now the problem then: the findutils ebuild claims to support afs, but I think it doesn't. The only thing that changes currently when the afs USE-flag is set, is that two extra libraries (pam_afs.so.1 and pam.so) are linked with the executable. The only afs-relevant code that I could find was in find/fstype.c. In there, there is some code that includes afs-specific includes when AFS is defined, and does special recognition of the filesystem type. However, this variable is never defined. I would therefore recommend something like: use afs && append-flags -DAFS Furthermore, it seems very weird to me that a pam module has to be linked to recognize a filesystem. After trying to link without, it seems to me that the only missing symbol is "pioctl". This symbol is also defined in libafsauthent.so, another library installed by the openafs ebuild. For the moment, this library is incomplete (unresolved symbols) in stable ebuilds, and the unstable ebuilds (proposed in bug #100837) fix this for all archs except for amd64 (in the pipeline). I would therefore recommend keeping the current added libraries, but I wanted to state this for the record anyway. Might be a good idea to change this later. Now, I've seen that the afs-aware find doesn't traverse the whole directory structure (seems to stop at mountpoints at tree depth > 1 or something), but that is a different matter.
Almost forgot the most important part... The newer openafs ebuilds in the tree (still all in testing), being openafs-1.2.13 and openafs-1.3.85, put their files in FHS-compliant locations. Hence, pam_afs.so is now in $(get_libdir)/security, trying to link with the old location will fail. Searching includes in /usr/afsws/include is now unnecessary, as they're located in /usr/include.
Fixed in 4.2.23.
