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.

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"

$ 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@

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.

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 🙈

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.

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.

.

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

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.

    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

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

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.

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.

• step 1: use named volumes
• step 2: stop your containers or just wait for them to crash/stop unnoticed for some reason
• step 3: run docker system prune --all as one should do periodically to clean up the garbage docker leaves on your system. Lose all your data (this will delete even named volumes if they are not in use by a running container)
• step 4: never use named or anonymous volumes again, use bind mounts

The fact that you absolutely need to run docker system prune --all regularly to get rid of GBs of unused layers, test containers, etc, combined with the fact that it deletes explicitely named volumes makes them too unsafe for my taste. Just use bind mounts.