Everyone who's tried pointing an NLE at a mounted S3 bucket has hit the same wall. Browsing folders is slow. Scrubbing stutters or hangs. The usual fix people reach for is downloading the whole file before touching it, which defeats the entire point of using cheap, scalable object storage in the first place.
The reason is simple once you see it: object storage — S3, MinIO, Ceph RGW, TrueNAS's S3-compatible gateway — isn't a filesystem. There's no directory tree, no stat(), no partial reads in the POSIX sense. Everything is a flat key with a GET and a PUT. Any workflow that wants to browse and edit media stored this way has to build a filesystem-shaped illusion on top of an object-shaped reality.
Tools like LucidLink made that illusion feel seamless enough that people forget it's an illusion at all. But the trick isn't magic, and it isn't proprietary to any one product — it's a handful of well-understood pieces working together. Worth breaking those apart before looking at any specific implementation.
The naive approach: mount and download
The simplest way to make an S3 bucket look like a drive is a FUSE mount (s3fs, goofys, rclone mount, etc.). These translate filesystem calls into API calls in real time. That works fine for sequential access — copying a file, reading a log — but post-production workloads are not sequential. Scrubbing a timeline, seeking to a mark, or letting a codec read its index atoms means constant, unpredictable jumps around a file. Each of those can turn into a separate HTTP request under a naive FUSE translation layer, and latency stacks up fast.
