LinuxI'm curious what sets this apart from the existing JuiceFS approach? JuiceFS is a commercial product, but with a foss community edition. It doesn't appear as a block device, but it does allow you superimpose an ext4-like filesystem complete with metadata etc. over S3 block storage (and others I believe). I've been using it for years and it's excellent.
Anyone know if this an improvement over the JuiceFS solution, and in what way(s)?
I'm starting to wonder if we have to many FS's now.
And they all seem to do similar things with one minor detail changed.
This sounds a lot like juicefs. I wonder what the motivation was to make this when juicefs exists and is reasonably mature already.
If the benchmarks are to be believed, it's much, much faster than juicefs.
One kinda scary thing is that for use with NFS, all writes are basically unsafe. The server says it has committed everything to disk immediately.
This sounds like a very expensive way to abstract away access to S3-type files, unless I'm missing something. Sounds pretty easy to make a very costly mistake here.
Might be sort of useful on R2 since they don't charge for ingress/egress.
You can self host S3.
https://garagehq.deuxfleurs.fr/
I use it as the joplin (note taking app) sync target. I originally tried webdav but I couldn't get it to work behind the reverse proxy (nginx proxy manager) so I tried garage/s3 and got it working.
I'm aware, but why would you self-host an S3-compatible storage implementation when you can host what this tool does via NFS or NBD? Makes no sense.
the most simple answer is that you selected s3 as your sole storage backend for whatever services/apps you have deployed. But now, you want to integrate something that does not support s3 into your stack. So you'll look at stuff like this.
Now, why would you self host S3 in the first place:
The big reason is security. NFS is a security nightmare that believes connections when they claim to be root. It has no encryption and basically no authentication by default [1]
NBD is a little better, but both NBD and NFS have the problem in that services run in the kernel, exposing frightening attack surface to privileged parts of linux systems. Also, NBD is block storage and a lot less supported as a storage backend for various services.
S3 on the other hand, is actually designed to be exposed over the internet. http based, you can use https for encryption, and http basic auth or other methods for authentication trivially. So if you ever end up running something distributed over the internet, NFS is basically not an option, and S3 is a much better solution.
[1] Was posted to lemmy: https://programming.dev/post/34520407
That's just...a bad idea then. You have every opportunity to not do that, and you're using a solution like this as a patch to solve for other issues you had. Not a good use-case.
This is one of the most popular methods to handle apps that are using a storage backend directly over the internet for increased bandwidth, and separation of deployment and state.
If I'm hosting something like Nextcloud at a massive scale, it simply isn't feasible to use internal networks because they don't have enough bandwidth, and overlay/vpn network solutions have too much overhead. A common solution is to just run the services and directly connect to them over the internet. So I point my 10,000 node Nextcloud instance at S3, either my own cluster or somebody else's and S3 handles encryption while remaining reasonably performant. And scalable.
Garage uses their software internally for something similar: https://garagehq.deuxfleurs.fr/documentation/design/goals/ . On this page, they describe using it as their matrix image/file storage cache. Same thing there, they probably have a large distributed matrix cluster that needs storage that scales with it, while also being secure over different networks.
Okay, as I said before, you had a technical issue you couldn't fix for one specific use-case. Jumping down to a less efficient (which this is) abstract to solve for that problem isn't a good solution, ESPECIALLY if you're self-hosting as you describe.
If I go to a store to buy hot dogs, and they're out of hot dogs, I wouldn't buy hamburgers to cut in half and try to pass it off as hot dogs just because they fit in a hot dog bun.
Do you have an alternative solution to the technical challenges I have mentioned above?
It is useful because you don't need to migrate the fs if you need to expand later
This has zero to do with anything. Please explain why you wouldn't be able to expand storage otherwise, and how this solution helps with that. You're aware of LVM, btrfs, or ZFS?
Too entitled.
How is this anything like entitlement?
I don’t think these people deserve downvotes for answering questions.
You're providing misguided information. You shouldn't be ranked higher for that.
Man, it's a shame they block me (probably because of my IP range)
Can you read this? https://github.com/Barre/ZeroFS
If not I can send you a PDF later
Yeah, thanks. I can open github just fine. I was just curious about what the author thinks. Usually articles on a blog will have more opinions of the author than the repo
I got you:
ZeroFS Turns S3 Buckets Into Linux Filesystems and Block Devices
ZeroFS is a new open-source project that exposes S3-compatible storage over NFS, 9P, and NBD for Linux systems.
ByBobby BorisovOnJune 15, 2026
ZeroFS Turns S3 Buckets Into Linux Filesystems and Block Devices
Most people know S3-compatible storage, an object storage that follows Amazon S3’s API model, as a place to keep backups, archives, images, logs, or application data. This includes AWS S3, commercial S3-compatible cloud services, and self-hosted platforms such as Garage, SeaweedFS, and RustFS.
It is cheap, widely available, and works well at large scale, but it does not normally behave like the storage Linux users deal with every day. ZeroFS tries to change that.
It is a new open-source project that presents S3-compatible object storage as Linux-accessible filesystems and block devices, enabling broader use of object storage beyond backup, archival, or application-specific workflows.
On the technical side, ZeroFS operates between the storage backend and the operating system, serving data as a POSIX-style filesystem over NFS or 9P, or as raw block storage via NBD. This allows the same S3-compatible backend to be accessed as files and directories or as a block device that can be formatted with filesystems like ext4 or used by storage stacks such as ZFS.
The project’s main goal is simple: making object storage usable where Linux systems expect filesystem or block-device access. Rather than relying on FUSE mounts or custom S3 API applications, ZeroFS uses protocols already supported by operating systems. According to the documentation, this includes file-level access through NFS and 9P, and block-level access through NBD.
Here’s a little more about them. NFS provides ZeroFS with broad compatibility, as NFS clients are practically available on almost every Unix-like OS. The 9P option targets Linux environments specifically, offering stronger POSIX compliance and advanced caching. NBD (Network Block Device protocol) is unique in that it enables S3-compatible storage to appear as a raw block device.
According to the project’s documentation, NBD devices created by ZeroFS can be used for ext4 filesystems, ZFS pools, databases, and VM boot disks. In other words, ZeroFS is not limited to presenting files from object storage, but it also supports Linux storage layers on top of an S3-compatible backend.
On the security side, ZeroFS enforces mandatory encryption. Data is encrypted before upload using XChaCha20-Poly1305, with keys derived from a password via Argon2id. There is no unencrypted mode, ensuring object storage providers only receive encrypted data.
Additionally, file data is compressed before encryption, with zstd as the default and LZ4 as a faster alternative. Plus, the compression method can be changed without migrating existing data, and previously written chunks remain accessible.
Regarding performance, and more specifically caching, ZeroFS supports memory and local disk caching to mitigate object-storage latency, a well-known limitation when using S3-compatible storage as a traditional filesystem. Additional features include checkpoints, read replicas, TRIM support, optional WAL storage, a standalone compactor, and a web UI with a file manager, dashboard, and browser terminal.
Still, ZeroFS should be evaluated carefully. Object storage differs significantly from local disks or traditional network storage in latency and consistency, and using it as a filesystem or block device introduces operational trade-offs.
But even with that in mind, ZeroFS is a compelling option for testing cloud-backed filesystems, self-hosted storage, encrypted remote storage, and experimental block-device workflows on object storage. The project is written in Rust and released as free and open-source software under the AGPL-3.0 license.
Additional details, installation instructions, and configuration examples are available on the project’s official website and GitHub repository.
Thanks!
