Named Volumes vs Bind Mounts

I began using LinuxServer images quite recently and I can say that I am in love!
The simplicity and the fact that it simply works are big wins for me.
Great job and thank you so much! You deserve all the kudos you can get!

However, as I move from messing around with docker-compose serving a semi-working media server and IRC client on my workstation, to a rpi powered docker swarm serving a fully-working high-availability media server (I have very high demanding clients: my SO), I began to question the usage of bind mounts over named volumes (actually, I have been troubled my this since day zero :sweat_smile:)

Throughout the docker documentation we are always encouraged to use named volumes over bind mounts. And I understand the concept, if docker is capable of handling my storage needs why should I care to maintain the data myself outside of docker?
Slap a driver into the container (like GlusterFS) and you have a replicated volume, great!
Even at work, I’ve had contact with subcontracted docker (supposedly) experts and they always advocate de usage of named volumes over bind mounts (but the also advocate the backing up of data with the services running for “zero downtime backup” so…).

However, I can also understand the need/will to use bind mounts here at LinuxServer: not only data but also configurations live in the /config folder (editing a configuration file inside a named volume is considerably more “dificult” than editing them in a bind mount).
But, it does feel … unnatural to use bind mounts over named volumes.
I mean, there are some cases where I definitely want to use bind mounts, I have no space in all me nodes to replicate my media library, for example.

All that taken into account I have, in fact, three questions:
Why does LinuxServer advocates the usage of bind mounts over named volumes?
Is there anybody using named volumes over bind mounts out there?
If you are, how the hell do you “inject” your configurations into the volumes?

Many thanks in advance.

Bind mounts are simpler for homelab users, that’s why we recommend them in our samples. Also, media folders are typically already existing on host, so you gotta use bind mounts for them. However you can use named volumes just the same for the config folders.

Not familiar with the glusterfs driver, but the regular volume driver automatically mounts the volumes at a location on host where you can access them (I forget the location but you can Google it).

1 Like

I recently started with and docker. At first I used Bind Mounts, but then I wanted to give Named Volumes a try.

Using Named Volumes takes some extra steps, like having to add something like this for volumes to docker-compose.yml.


To access and edit config in volume this can be useful:

sudo docker exec -it (contain_id) /bin/bash

I have also preferred the usage of volumes over bind mounts in most cases (media libraries being the obvious exception).

I guess the argument of simplicity is strong and I can get by with that explanation, thank you @aptalca.