Initial mounting issue when first intercept

[guiguan]

We have been getting the following error when initially intercepts a workload:

> telepresence connect --name my-service --namespace my-namespace --docker
> telepresence intercept my-service --use my-service --docker-run -- \
                --platform linux/arm64 --rm -it \
                --mount type=bind,source=/my/host/path/to/my-service,target=/app/my-service -w /app/my-service my-dev-container:latest

Using Deployment my-service
   Intercept name         : my-service
   State                  : ACTIVE
   Workload kind          : Deployment
   Destination            : 127.0.0.1:8080
   Service Port Identifier: http2
   Volume Mount Point     : /var/folders/_h/484b66dx7vz59t911m787j9x_0j0jc/T/telfs-849545687
   Intercepting           : all TCP connections
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/var/lib/docker/plugins/325ab4d238ecec23d85f71cf2beb544908e39b2d9b2eb359af0ff606f58eedb4/propagated-mount/192.168.247.2/60308/my-service/var/run/secrets/kubernetes.io/serviceaccount" to rootfs at "/var/run/secrets/kubernetes.io/serviceaccount": stat /var/lib/docker/plugins/325ab4d238ecec23d85f71cf2beb544908e39b2d9b2eb359af0ff606f58eedb4/propagated-mount/192.168.247.2/60308/my-service/var/run/secrets/kubernetes.io/serviceaccount: no such file or directory: unknown.

it seems the interception was okay, but failed to mount volumes when launch the container with --docker-run. Subsequent runs of the same interception command were fine. Probably a race condition somehow between sshfs and the initial container mounting?