Confusion in Docker Compose volume mappings (ref#3ODQBL)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Confused, in the volumes section of the docker compose file (yaml code) specifically the 1st (roon data ...) and 3rd (backups) are pointing inside the container. Is this not dangerous you could loss everything. Can I put both outside of the container as long as the storage mapping points the them. ie. /share/datavol1/roonserver/roon:roon

Tell us about your home network

· Blast U6 fibre 1 G

2

Hey @June_Coll,

Thanks for writing in, and excellent eye you have here! If roon_data is a named Docker volume (defined in a volumes: block at the bottom of the compose file), it is managed by Docker but stored in Docker’s internal storage area (e.g. /var/lib/docker/volumes/). This means:

  • If the container is accidentally removed with docker rm -v, the data can be wiped
  • It's harder to back up, inspect, or recover manually
  • On some NAS systems (QNAP, Synology etc.), Docker's internal storage is on the OS drive, not your data volume — so it's both less safe and using the wrong disk
Your solution is correct, use bind mounts. Replacing named volumes with host-path bind mounts is the standard safe approach:

yaml

volumes:
 - /share/datavol1/roonserver/roon:/roon # was: roon_data
 - /share/datavol1/roonserver/music:/music # already fine if it was like this
 - /share/datavol1/roonserver/backups:/backups # was: some named volume

The format is always host_path:container_path. As long as the right side (container path) matches what the application expects, you can put the left side (host path) anywhere you like on your NAS or server.

A good thing to note: create the host directories before starting the container, or Docker will create them owned by root, which can sometimes cause permission issues depending on what user the container runs as.

Let me know if this helps! :folded_hands: