There's nothing wrong with the NFS mount itself – if its contents are already accessible to shell commands, then that means it is still mounted, and equally accessible to Telegraf or whatever else.

It doesn't look like your issue is caused by autofs; rather, your Telegraf configuration doesn't match the actual mounts.

Specifically, your configuration asks to monitor .../TIG_backups, but the container has nothing mounted at that path, as your df output shows. The container only has a mount at .../TIG_backups/telegraf_backups which is not set up to be monitored.

Directories on the mounted drive are accessible from inside the container. It is as if the drive is still mounted (but I can see from the journalctl logs on the host that it was in fact auto-unmounted)

It is indeed still mounted. What was auto-unmounted on the host is not the same as what's still mounted inside the container – these are two separate mounts representing the same filesystem.

For explanation:

• Bind mounts are more like hardlinks than symlinks, in the sense that both mounts (the original and the "bind") have equal standing. There's no "master" mount – if the original is unmounted, the bind mount doesn't disappear and doesn't become inoperative; the filesystem as a whole in fact remains mounted and the bind mount continues to work like if it were the original.

• An automount is set up as a separate layer: a special "autofs" mount. Whenever that mount is touched, the real NFS mount is stacked on top of that autofs mount at the same path (you can see this in findmnt).

  The NFS mount has none of the autofs magic; operations such as statfs() don't trigger an automount, because the filesystem is in fact already mounted. Once it is unmounted, the NFS layer would disappear and the autofs mount would be uncovered, allowing operations to trigger it again.

  But when you bind the NFS mount (or part of it) into a container, you're binding only the NFS mount but not the autofs mount that's underneath. If the container were to unmount it, there would be nothing underneath except a regular empty directory – nothing that could trigger a re-mount.

To work around this – if it were the cause, which it most likely isn't – you would have to bind the parent directory that contains the autofs mount (e.g. /mnt/nfs) with options to make the bind recursive and to set its cross-namespace propagation mode to 'shared' or 'slave' (allowing submounts or unmounts from the host side to propagate into the container). To do this in Docker you'd need bind-propagation=rshared or bind-propagation=rslave.

But it doesn't look like an 120s idle unmount makes any sense here, as the filesystem seems to be expected to be permanently available for hourly access (if it were unavailable, Telegraf would hang), so you aren't saving anything by unmounting it. Just let autofs mount it once without expiry, and continue binding only the NFS mount into the container as you're doing now.