If you’re doing it from scratch, I’d recommend starting with a filesystem that has parity checks and filesystem scrubs built in: eg BTRFS or ZFS.
The benefit of something like BRTFS is that you can always add disks down the line and turn it into a RAID cluster with a couple commands.
Yep, the problem was that docker started before the NFS mount. Adding the dependency to my systemd docker unit did the trick!
isn’t it an annoyance having to connect to your home network all the time?
It’s less annoying than the gnawing fear that my network might be an easy target for attackers.
So many bad-faith arguments being made about this.
Independent of any arguments about who asked for this to happen and why: A free software project always has the right to choose which contributors it trusts and which it doesn’t. I’ve seen no evidence that these people are banned from submitting patches due to their nationality. They’ve been remove from a particular role in the project due to political reasons. An organization is an inherently political entity.
Remember when codes of conduct destroyed all of free software and nothing ever got built again? Me neither. It’s the same thing.
If you want to move your containers to a different location, look into configuring docker’s
data-root: https://stackoverflow.com/questions/24309526/how-to-change-the-docker-image-installation-directoryYou copy
/var/lib/dockerto a new location and update/etc/docker/daemon.jsonI will say: Moving data-root to an NFS mount isn’t going to work well. I’ve tried it, and docker containers rely on filesystem features to run their overlays. On an NFS, this feature isn’t present, so your services will duplicate the container’s entire filesystem. This will tank your performance and is basically unusable for anything but trivial examples. Docker data-root basically needs to be a “physical” disk.
I’ve had no issues using NFS shares mounted as docker volumes. It’s just the data-root where it’ll fail.