this post was submitted on 01 Feb 2025
49 points (98.0% liked)

Selfhosted

41623 readers
499 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud
Loki
CannaVet
devve
HybridSarcasm
[email protected]
49
Why use Named volume vs Anonymous volume in Docker? (reddthat.com)
submitted 19 hours ago by [email protected] to c/selfhosted
21 comments fedilink hide all child comments
 

What are the pros and cons of using Named vs Anonymous volumes in Docker for self-hosting?

I've always used "regular" Anonymous volumes, and that's what is usually in official docker-compose.yml examples for various apps:

volumes:
  - ./myAppDataFolder:/data

where myAppDataFolder/ is in the same folder as the docker-compose.yml file.

As a self-hoster I find this neat and tidy; my docker folder has a subfolder for each app. Each app folder has a docker-compose.yml, .env and one or more data-folders. I version-control the compose files, and back up the data folders.

However some apps have docker-compose.yml examples using named volumes:

services:
  mealie:
    volumes:
      - mealie-data:/app/data/
volumes:
  mealie-data:

I had to google documentation https://docs.docker.com/engine/storage/volumes/ to find that the volume is actually called mealie_mealie-data

$ docker volume ls
DRIVER    VOLUME NAME
...
local     mealie_mealie-data

and it is stored in /var/lib/docker/volumes/mealie_mealie-data/_data

$ docker volume inspect mealie_mealie-data
...
  "Mountpoint": "/var/lib/docker/volumes/mealie_mealie-data/_data",
...

I tried googling the why of named volumes, but most answers were talking about things that sounded very enterprise'y, docker swarms, and how all state information should be stored in "the database" so you shouldnt need to ever touch the actual files backing the volume for any container.

So to summarize: Named volumes, why? Or why not? What are your preferences? Given the context that we are self-hosting, and not running huge enterprise clusters.

all 22 comments
sorted by: hot top controversial new old
[–] [email protected] 2 points 1 hour ago* (last edited 1 hour ago) (1 children)

I don’t have to deal with a permissions nightmare when using a named volume, it’s seamless and ensures persistence. No more messing around with PUID and PGID. I rarely need to access the files, and when I do, I’m fine sacrificing a bit of convenience. I can still reach them via cd /var/lib/docker/volumes/(Container_Name), and I’ve added a WinSCP shortcut for quick access. Avoiding permission errors is far more valuable for my sanity and time than easy file access.

[–] [email protected] 1 points 43 minutes ago

Yeah that's fair, permission issues can be a pain to deal with. Guess I've been lucky I haven't had any significant issues with permissions and docker-containers specifically yet.

[–] [email protected] 2 points 2 hours ago

Supposedly docker volumes are faster than plain bind mounts; but I've not really noticed a difference.

They also allow you to use docker commands to backup and restore volumes.

Finally you can specify storage drivers, which let you do things like mount a network share (ssh, samba, nfs, etc) or a cloud storage solution directly to the container.

Personally I just use bind mounts for pretty much every bit of persistent data. I prefer to keep my compose files alongside the container data organized to my standards in an easy to find folder. I also like being able to navigate those files without having to use docker commands, and regularly back them up with borg.

[–] [email protected] 2 points 4 hours ago

I like named volumes, because all my data is in one place. Makes backups easy.

[–] ikidd 5 points 6 hours ago (1 children)

I like having everything to do with a container in one folder, so I use ./ the bind mounts. Then I don't have to go hunting all over hells half acre for the various mounts that docker makes. If I backup/restore a folder, I know I have everything to do with that stack right there.

[–] [email protected] 1 points 37 minutes ago

This has been my thinking too.

Though after reading mbirth's comment I realised it's possible to use named volumes and explicitly tell it where on disk to store the volume:

    volumes:
      - my-named-volume:/data/
volumes:
  my-named-volume:
    driver: local
    driver_opts:
      type: none
      device: "./folder-next-to-compose-yml"
      # device: "/path/to/well/known/folder"
      o: bind

It's a bit verbose, but at least I know which folder and partition holds the data, while keeping the benefits of named volumes.

[–] Semi_Hemi_Demigod 25 points 19 hours ago (3 children)

Named volumes let you specify more details like the type of driver to use.

For example, say you wanted to store your data in Minio, which is like S3, rather than on the local file system. You’d make a named volume and use the s3 driver.

Plus it helps with cross-container stuff. Like if you wanted sabnzbd and sonarr and radarr to use the same directory you just need to specify it once.

[–] [email protected] 1 points 58 minutes ago

That makes sense. I've only ever used local storage on the docker-VM, but for sure it can make sense for using external storage

[–] [email protected] 18 points 18 hours ago (4 children)

Or just something as simple as using a SMB/CIFS share for your data. Instead of mounting the share before running your container, you can make Docker do it by specifying it like this:

services:
  my-service:
    ...
    volumes:
      - my-smb-share:/data:rw

volumes:
  my-smb-share:
    driver_opts:
      type: "smb3"
      device: "//mynas/share"
      o: "rw,vers=3.1.1,addr=192.168.1.20,username=mbirth,password=supersecret,cache=loose,iocharset=utf8,noperm,hard"

For type you can use anything you have a mount.<type> tool available, e.g. on my Raspberry this would be:

$ ls /usr/sbin/mount.*
/usr/sbin/mount.cifs*  /usr/sbin/mount.fuse3*       /usr/sbin/mount.nilfs2*  /usr/sbin/mount.ntfs-3g@  /usr/sbin/mount.ubifs*
/usr/sbin/mount.fuse@  /usr/sbin/mount.lowntfs-3g@  /usr/sbin/mount.ntfs@    /usr/sbin/mount.smb3@

And the o parameter is everything you would put as options to the mount command (e.g. in the 4th column in /etc/fstab). In the case of smb3, you can run mount.smb3 --help to see a list of available options.

Doing it this way, Docker will make sure the share is mounted before running the container. Also, if you move the compose file to a different host, it'll just work if the share is reachable from that new location.

[–] [email protected] 1 points 51 minutes ago

Wow thanks for this! Reading the official docker documentation I somehow missed this. Using regular well documented linux mount. tools and options will be so much better than looking for docker-specific documentation for every single type.

And knowing the docker container won't start unless the mount is available solves so much.
Does the container stop or freeze if the mount becomes unavailable? For example if the smb share host goes offline?

[–] theRealBassist 4 points 16 hours ago

Ok I did not know about this at all. I've been just mounting it on the host which has been a bit of a pain at times.

I just did a massive refactor of my stacks, but now I might have to revisit them to do this.

[–] [email protected] 1 points 14 hours ago

There's also an NFSv4 driver which is great when you're running TrueNAS

[–] [email protected] 1 points 16 hours ago

what?? im definetly using this thanks for makong me aware of it.

[–] just_another_person 5 points 18 hours ago

On a simpler level, it's just an organizational thing. There are lots of other ways data from docker is consumed, and looking through a bunch of random hashes and trying to figure out what is what is insane.

[–] [email protected] 4 points 16 hours ago (1 children)

I use NFS shares for all of my volumes so they're more portable for future expansion and easier to back up. It uses additional disk space for the cache of course, but i have plenty.

When I add a second server or add a dedicated storage device as I expand, it has made it easier to move with almost no effort.

[–] [email protected] 1 points 34 minutes ago

How does this work? Where is additional space used for cache, server or client?

Or are you saying everything is on one host at the moment, and you use NFS from the host to the docker container (on the same host)?

[–] [email protected] 2 points 14 hours ago* (last edited 14 hours ago) (1 children)

I don't really have a technical reason, but I do only named volumes to keep things clear and tidy, specially compose files with databases.

When I do a backup I run a script that saves each volumes/database/compose files well organized in directories archived with tar.

In have this structure in my home directory: /home/user/docker/application_name/docker-compose.yaml and it only contains the docker-compose.yml file (some times .env/Docker file).

I dunno if this is the most efficient way or even the best way to do things :/ but It also helps me to keep everything separate between all the necessary config files and the actual files (like movie files on Jellyfin) and it seems easier to switch over If I only need one part and not the other (uhhr sorry for my badly worded English, I hope it makes sense).

Other than that I also like to tinker arround and learn things :) Adding complexity gives me some kind of challenge? XD

[–] [email protected] 1 points 27 minutes ago

I hadn't considered giant data sets, like Jellyfin movie library, or Immich photo library. Though for Jellyfin I'd consider only the database and config as "Jellyfin data", while the movie library is its own entity, shared to Jellyfin

[–] peregus 5 points 18 hours ago* (last edited 12 hours ago)

Good question, I'm interested too. Personally I use this kind of mapping

volumes:
  - /var/docker/contanier_name/data:/data

because it helps me with backups, while I keep all the docker-compose.yaml in /home/user/docker-compose/container_name so I can mess with the compose folder whithout worrying too much about what's inside of it 🙈

[–] BrianTheeBiscuiteer 4 points 18 hours ago

I like named volumes, externally created, because they are less likely to be cleaned up without explicit deletion. There's also a few occasions I need to jump into a volume to edit files but the regular container doesn't have the tools I need so it's easier to mount by name rather than hash value.

[–] [email protected] 2 points 19 hours ago

I choose depending on whether I'll ever have to touch the files in the volume (e.g. for configuration), except for debugging where I spawn a shell. If I don't need to touch them, I don't want to see them in my config folder where the compose file is in. I usually check my compose folders into git, and this way I don't have to put the volumes into gitignore.