My setup is as follows:

- /srv/pub is an smb share like this
  [pub]
  acl allow execute always = True
  comment = public file repository
  path = /srv/pub
  public = yes
  writeable = no

- /srv/pub/img contains lots of ISO images...
- which are accessible in /srv/pub/img_loop, managed via autofs.
- Those autofs mountpoints (one per iso image) are visible as
  /srv/pub/img_loop/(iso1|isoB|another_iso)
- accessing such an autofs-managed mount point auto-mounts the
  corresponding iso image and content is accessible


This has been working nicely for years. Only recently I discovered
this setup broke some time in the past - even before my migration to
Debian Bookworm a few months ago. Now, accessing an autofs-managed iso
mount point via the smb-share 'pub' results in an error message.
Depending on the smb client used it would say somethink like not
accessible, not available, you name it. Checking on the server, the
autofs auto-mounter didn't get triggered by those clients' access
attempts and behold, smbd's error message is entirely correct.

Workaround - at least for the sake of reproducing/circumventing this
behaviour: cd'ing into the corresponding directory on the smbd's host
triggers autofs, which mounts the image, which henceforth is
accessible via the share 'pub'.


git bisect'ing revealed 2bbdaca8da8a0f4d4ff6bb5d4a98470db223b265 to be
the problematic commit.


Reverting 2bbdaca8 worked for me both on
- the source tree for Debian Bookworm
- and on master as of ~2 weeks ago.

strace'ing smbd's process tree confirms that in the current state, a
chdir syscall on the iso mount point, which previously triggered
autofs, is now missing. After reverting 2bbdaca8, said chdir call is
visible again.

Please consider undoing the optimization intended by 2bbdaca8, thanks!


Cheers
Daniel