[1]: https://du.nkel.dev/blog/2026-05-16_rootless_docker_virtiofs...
2,095 karma · joined April 12, 2021
[1]: https://du.nkel.dev/blog/2026-05-16_rootless_docker_virtiofs...
> Network file systems can cause UID/GID mismatches and add network overhead. With VirtIO-FS, I use the Linux kernel's Virtual File System to translate the hypervisor's UID to the guest's unprivileged UID. This avoids exposing the host file structure. I utilize the `X-mount.idmap` fstab option for this. Documentation on this specific implementation is not easy to find. It builds upon the idmapped mounts feature introduced by Christian Brauner in Linux 5.12 [1] and its later integration with util-linux v2.39 into the standard `mount` utility [2].
[1]: https://github.com/brauner/mount-idmapped + https://docs.kernel.org/filesystems/idmappings.html
[2]: https://github.com/systemd/systemd/releases/tag/v254> Podman vs Docker You may point to Podman here because Podman is natively rootless and doesn't require a daemon and additional workarounds to run rootless. I agree. However, Docker in rootless user nesting is also robust and possible, and I decided to stick to the docker-compose.yml because it is still the industry (and homelab) standard. This minimizes the time I need to translate examples or templates. Docker in rootless and Podman are mostly interchangeable at this level. Both run processes in isolated Linux namespaces on your host VM (not the Hypervisor!).
This is not 100% and may change anytime. I guess, for me, at this time, the difference between Docker in rootless and Podman is just too small, and the time needed to migrate all my docker-compose.yml's too much, to make the jump. Overall, it is not a critical decision for this architecture, more a choice.
Regarding Debian is similar, I just stick with what I am familiar with. Debian also never lost me.
[1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...
[1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...
- 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-15869532I would need to create a separate file tree, splitting my work between nextcloud maintained files and working files. That feels cumbersome. On Windows, I could directly add my whole drive to nextcloud as a virtual file system.
[1]: https://gist.github.com/Sieboldianus/280afdb2f994fae6e5f6b18...
Btw. asking once is enough ^^
[1]: https://github.com/crabby-rathbun/mjrathbun-website/blob/83b...