the first time an autofs(4) filesystem is mounted, fts(3) (e.g., find(1) or du(1)) will fail to traverse it. running the same command a second time works correctly. # df /home/ft Filesystem 512-blocks Used Avail Capacity Mounted on map auto_home 0 0 0 100% /home # find /home/ft /home/ft /home/ft/.mutt_header_cache-lock /home/ft/.ssh /home/ft/.ssh/authorized_keys /home/ft/.ssh/known_hosts /home/ft/.ssh/known_hosts.old find: fts_read: No such file or directory # df /home/ft Filesystem 512-blocks Used Avail Capacity Mounted on /export/home/ft 1719233272 752 1719232520 0% /home/ft # find /home/ft /home/ft /home/ft/.mutt_header_cache-lock /home/ft/.ssh /home/ft/.ssh/authorized_keys /home/ft/.ssh/known_hosts /home/ft/.ssh/known_hosts.old /home/ft/.k5login /home/ft/.vimrc /home/ft/.zcompdump /home/ft/Mail /home/ft/Mail/new /home/ft/Mail/new/1730888987.V2b6429de6e936a53Idf1d2M757967.hemlock.eden.le-fay.org [...] this is repoducible every time, as long as the filesystem is not mounted. /etc/auto_master: /home auto_home -nosuid /etc/auto_home: * -fstype=nullfs :/export/home/& using src f5aff1871d3273b3cd3621ea5d3e37cdd807e66f on amd64, /export/home is a ZFS filesystem.
Look at the ktrace/kdump to see what exactly is failing.
33368 find CALL write(0x1,0x28240d651000,0x1e) 33368 find GIO fd 1 wrote 30 bytes "/home/ft/.ssh/known_hosts.old " 33368 find RET write 30/0x1e 33368 find CALL open(0x2675923a9781,0x120000<O_RDONLY|O_DIRECTORY|O_CLOEXEC>) 33368 find NAMI ".." 33368 find RET open 5 33368 find CALL fstat(0x5,0x267590a00240) 33368 find STRU struct stat {dev=687931149, ino=34, mode=040700, nlink=6, uid=10020, gid=10006, rdev=0, atime=1740008641.500888000, mtime=1730971526.664459000, ctime=1740008836.602277000, birthtime=1730971526.664459000, size=18, blksize=4096, blocks=17, flags=0x800 } 33368 find RET fstat 0 33368 find CALL close(0x5) 33368 find RET close 0 33368 find CALL write(0x2,0x2675909ffb80,0x6) 33368 find GIO fd 2 wrote 6 bytes "find: " the device is (as expected) different from when it first opened the directory: 33368 find CALL statfs(0x28240d644000,0x28240d63a058) 33368 find NAMI "/home/ft" 33368 find RET statfs 0 33368 find CALL fstat(0x5,0x267590a00170) 33368 find STRU struct stat {dev=18446744072887533315, ino=7, mode=040755, nlink=3, uid=0, gid=0, rdev=0, atime=1740015874.694741010, mtime=1740015874.694741010, ctime=1740015874.694741010, birthtime=1740015874.694741010, size=512, blksize=4096, blocks=1, flags=0x0 } i suspect this trips the check in fts.c:fts_safe_changedir(): if (p->fts_dev != sb.st_dev || p->fts_ino != sb.st_ino) { errno = ENOENT; /* disinformation */ ret = -1; goto bail; }
so, setting vfs.autofs.mount_on_stat=1 fixes the problem: # stat /home 18446744072887533315 1 drwxr-xr-x 3 root wheel 0 512 "Feb 20 00:17:28 2025" "Feb 20 00:17:28 2025" "Feb 20 00:17:28 2025" "Feb 20 00:17:28 2025" 4096 1 0 /home # stat /home/ft 18446744072887533315 7 drwxr-xr-x 3 root wheel 0 512 "Feb 20 01:44:34 2025" "Feb 20 01:44:34 2025" "Feb 20 01:44:34 2025" "Feb 20 01:44:34 2025" 4096 1 0 /home/ft # sysctl vfs.autofs.mount_on_stat=1 # stat /home 18446744072887533315 1 drwxr-xr-x 3 root wheel 0 512 "Feb 20 00:17:28 2025" "Feb 20 00:17:28 2025" "Feb 20 00:17:28 2025" "Feb 20 00:17:28 2025" 4096 1 0 /home # stat /home/ft 687931150 34 drwx------ 6 ft users 0 18 "Feb 19 23:44:01 2025" "Nov 7 09:25:26 2024" "Feb 19 23:47:16 2025" "Nov 7 09:25:26 2024" 4096 17 0x800 /home/ft (and find now works.) this is rather unfortunate as default behaviour though, especially since this particular interaction doesn't seem to be documented in autofs(4).
(In reply to Lexi Winter from comment #3) FTS could be made more forgiving for the case where the detected mishap occurs on the automounted mount point. I am not sure if it is worth the change, because it would make the check slightly less strict.
It’s off by default because it’s terrible when you have a nontrivial number of mounts. I wonder if we could loosen up the fts(3) check iff the filesystem type is autofs?
(In reply to Edward Tomasz Napierala from comment #5) This is same as what I suggested. The change is not tested https://reviews.freebsd.org/D49094
i had to turn off vfs.autofs.mount_on_stat because even with only a few (~5) home directories, it absolutely murdered performance, e.g. mutt took several seconds to reload my inbox. this might be a separate bug. i am personally in favour of the fts(3) to change to make this work transparently; would it help if i tested the proposed patch to see if it fixed the original problem?
(In reply to Lexi Winter from comment #7) Of course I cannot commit the change unless it is tested. I do not have a setup to reproduce the problem.
i've tested the patch from D49094, it seems to fix the issue (tested with find and du).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e59991206b1463b7e85cc8aafde7f1dc03fcedcf commit e59991206b1463b7e85cc8aafde7f1dc03fcedcf Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2025-02-21 13:07:43 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2025-02-25 07:09:29 +0000 fts(3): be less strict when automount does its job under us walking autofs mount Namely, allow the file id change if the resulting file belongs to automounted filesystem. If it is, remember the updated id. This allows the ids from the automounted volumes to change without restrictions, might be a further refinement would be to only allow such inconsistency once. PR: 284914 Reported and tested by: Lexi Winter <lexi@hemlock.eden.le-fay.org> Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D49094 lib/libc/gen/fts.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9460df357344a2848f9cab07a5228cd9615800e1 commit 9460df357344a2848f9cab07a5228cd9615800e1 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2025-02-21 13:07:43 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2025-03-04 04:19:08 +0000 fts(3): be less strict when automount does its job under us walking autofs mount PR: 284914 (cherry picked from commit e59991206b1463b7e85cc8aafde7f1dc03fcedcf) lib/libc/gen/fts.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)