91–100 of 130 posts
That repo is a fork of this project: https://github.com/johannesboyne/gofakes3
They bill it as being for testing, but it works great if all you want is a no-fuss S3-compatible API on top of a filesystem. I've run it on my NAS for a few years now to provide a much faster transfer protocol compared to SMB.
Earlier quoted context omitted.
RustFS is the poster child in my mind for the worst kind of vibe-coded slop. it might be "simple" but it's not something I would ever trust with persistent data. last year they had a security vulnerability where they allowed a hardcoded "rustfs rpc" token to bypass all authentication [0] and even worse, if you read the resulting reddit thread [1] someone tracked down the culprit commits - it was introduced in July [2…
I am building an S3 client [1] where I have a test matrix that tests against common S3 implementations, including RustFS. That test matrix uncovered that post policies were only checked for exsitence and a valid signature, not if the request actually conforms to the signed policy. That was an arbitrary object write resulting in CVE-2026-27607 [2]. In the very first issue for this bug [3], it seemed that the authors o…
Garage has worked well for me and gives a good sense of stability. They provide helm charts for deployment and a CLI. There's also very few concepts to learn to start to use it, while e.g. for SeaweedFS I feel like you need to parse a lot of docs and understand more specific terminology.
- MinIO [3] is somewhat deprecated and not really open source anymore. Its future is unsure.
- GarageHQ [4] looks pretty great and I wished I could have used this, but it is not yet feature-complete with S3 protocol and specifically missing the versioning feature (I reported this [5])
- Zenko Scality works out of the box; it is a bit too "big" for my context (aimed at thousands of parallel users) and uses 500MB memory; but it does the job for now.
I posted my compose here [6]. Since then (~months ago), it works really well and I am happy with Zenko Scality S3.
[1]: https://github.com/gristlabs/grist-core
[2]: https://github.com/scality/cloudserver
[3]: https://www.min.io/
[4]: https://garagehq.deuxfleurs.fr/
[5]: https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/166
[6]: https://github.com/scality/Zenko/discussions/1779#discussioncomment-15869532Earlier quoted context omitted.
Then why nobody forked minio?
Maybe nobody wants to spend effort maintaining it? I imagine it's simpler to build your own S3 alternative than maintain minio. Also nobody wants to test AGPL liability in court: https://www.reddit.com/r/minio/comments/1fnuv46/does_interac...
Also think there is an abstraction mismatch with the object stores that store the objects with a 1:1 mapping into the file system. Obvious issues are that you only get good listing performance with '/' as delimiter and things like "keys with length up to 1024 bytes" break.
I've used Garage to some success, the garage.toml configuration file could be a bit more user friendly https://garagehq.deuxfleurs.fr/documentation/reference-manua... but with some tweaks there I could get it working nicely both for HDD and SSD use cases, e.g. storing a bunch of Sentinel-2 satellite tiles, alongside thumbnails and some metadata. SeaweedFS and RustFS both look nice though, last I checked Zenko was kin…
S3 isn't "simple" tho. It doesn't need to care about POSIX mess but there is whole swathes of features many implementations miss or are incomplete, both on frontend side (serving files with right headers, or with right authentication) and backend (user/policy management, legal hold, versioning etc.) It gets even more messy when migrating, for example migrating your backups to garagefs will lose you versioning, which…
If they just want webfile interface then a webserver with simple auth and webDAV would work more than well enough.
The problem is that they then go onto talk about lots of projects that all have posix interfaces. Which is slap bang into shared filesystem land.
S3 is not a filesystem, and nothing shows that more than when you use it as an object store _for_ a filesystem.
Depending on the access requirements, if you're doing local to local, then NFSv4 is probably more than enough. Unless you care about file locking (unlucky, you're in shit now)
Personally I would suggest that the "easiest S3" would be simply using NFS. You can get replication with RAID. S3 is simple for the users, not the operators. For replicating something like S3 you need to manage a lot of parts and take a lot of decisions. The design space is huge: Replication: RAID, distributed copies, distributed erasure codes... Coordination: centralized, centralized with backup, decentralized, logi…
NFS in practice is too different from S3 to make this work. I’ve been at a couple companies where somebody tried putting an S3 interface in front of an NFS cluster. In practice, the semantics of S3 and NFS are different enough that I’ve had to then deal with software failures. Software designed to work with S3 is designed to work with S3 semantics and S3 performance. Hook it up to an S3 API on what is otherwise an NF…
I mean you can, it would simplfy the locking somewhat.
But if you are doing file sharing for apps inside a network you manage, just use NFS, and maybe worry about the locking later.
microceph is pretty nice and straightforward for throwaway s3 endpoints https://canonical-microceph.readthedocs-hosted.com/stable/tu...
Its also not that useful even if you have enough machines to run it properly.
NVME and zfs is fast enough for virtually anything now. With snapshot and snapshot sending you get decent backups for half the hardware cost of ceph.
I also had quite a hard time to chose one for my homelab too. Settled on garage too but why is it that complicated ? I just want a "FS api" for remote storage in my app. Over http so that i dont have to do weird custom setup just to have a network share and handle everything manually