Yes — your assumption is correct and still practical in 2025: most container and cloud job systems can mount directories, but not individual files.

Mounting a file directly into a container’s filesystem is usually an edge case.

Here’s how it breaks down across systems:

🧩 Kubernetes

Kubernetes volumeMounts only support mounting directories, not single files — unless you use specific volume types that simulate it (like configMap, secret, or projected volumes).

Even then, these are internally implemented as directories containing a file, not true file-level mounts.

For example:

volumeMounts:

- name: my-volume

mountPath: /app/config.json

subPath: config.json

works, but it’s a subPath hack — it still mounts the parent directory underneath.

When using sidecars and shared volumes, this can break easily because subPath mounts aren’t dynamically updated and don’t behave like a live mount point.

🧩 Docker / OCI Containers

Native Docker supports -v /host/path:/container/path, but it also expects a directory or a full file path that already exists on the host.

If the file doesn’t exist beforehand, the bind mount fails.

So while technically you can bind a single file, in practice pipeline systems and orchestration layers prefer directory mounts — they’re safer, portable, and more flexible for FUSE or remote mounts.

🧩 Cloud Batch / Vertex AI / Other Managed Runtimes

Most managed job systems (Google Cloud Batch, Vertex AI CustomJob, AWS Batch, SageMaker, etc.) abstract away low-level mounts, but when you provide mount specs, they’re all directory-based.

These platforms assume that you’re mounting a dataset, a model directory, or a temporary workspace — not individual blobs.

Even if they allow specifying a single object (like gs://bucket/file.txt), they’ll copy or download it into a temporary directory under the hood, not mount it as a file.

⚙️ Practical Implication

So, your design — where each output artifact lives inside its own directory and the actual content is always named consistently (/data) — is solid and future-proof.

It keeps mounts predictable, works with sidecar FUSE setups, and avoids subPath limitations.

Even in advanced container systems, true file-level mounts are rare, non-portable, and fragile.

Directory-level granularity is the reliable common denominator across Docker, Kubernetes, and cloud execution frameworks.

💡 In Short

File-level mounts = possible only in specific, fragile cases.

Directory mounts = universally supported, portable, and sidecar-friendly.

Your “/data suffix under a unique directory” pattern is a good long-term choice.

✅ TL;DR:

Keep the /data directory convention — file mounts aren’t widely or consistently supported, and your approach avoids nearly all real-world portability issues.