[Bug]: A pod container fails to start when another container boots from the directory it mounts

[MayCXC]

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

Steps to reproduce

In one pod:

1. Start a container whose rootfs is a virtiofs share of some host directory.
2. Hotplug a second container into the same pod with that same directory as an additional mount.

Current behavior

The second container fails to start, and its bind mount fails with ENOENT.

A container's additional virtiofs mounts are bind-mounted from /run/virtiofs/<tag>, so those tags are what belongs under that directory. A virtiofs rootfs is mounted at the container's own rootfs path and nothing binds it, but the per-tag boot walk puts its tag under /run/virtiofs anyway, and the hotplug join then counts that tag as already satisfying /run/virtiofs for every other container. The joining container is skipped as already mounted, so the path its bind needs was never created.

Expected behavior

A container mounts what it binds from, regardless of what another container in the pod happens to boot from. Sharing a directory between one container's rootfs and another's mount is a legitimate arrangement.

The guest kernel permits the same tag being mounted in several places: virtio_fs_get_tree resolves each mount of a tag to the device instance's single superblock (fs/fuse/virtio_fs.c, sget_fc with virtio_fs_test_super).

Environment

• OS: macOS 26.6
• Go: n/a
• Xcode: 26.x

Relevant log output

bind mount fails with ENOENT at container start

Code of Conduct

• I agree to follow this project's Code of Conduct