Difference between down and stop command? How to properly edit compose file?

TOMillr · Apr 26th 2025

I don't really understand the difference between the stop and down commands in the Docker Compose menu:

Let's say I'm running a Plex Media Server inside a container and hit den "down" instead of the "stop" command. Am I going to basically erase the Plex database and have to start over, when I run the container again?

What do I do, when I have to make an edit to the Docker Compose file? Change the path to the data volume for example. Simply stop the container, edit the compose file and restart the container again?

Zafkiel · Apr 26th 2025

Refer to the official Docker documentation:

docker compose down

docs.docker.com

docker compose stop

docs.docker.com

docker compose up

docs.docker.com

I usually modify the compose file, save it, and then run "up". The compose plugin will automatically restart the container.

theking2 · Apr 26th 2025

Here's a super quick visual for you:

Code

┌──────────────────────┬───────────────────────────────────────────┐
│ Command              │ What it does                              │
├──────────────────────┼───────────────────────────────────────────┤
│ docker stop          │ Stops a running container (no removal).   │
│                      │                                           │
│ docker compose down  │ Stops containers + removes containers,    │
│                      │ networks, and (optionally) volumes.       │
└──────────────────────┴───────────────────────────────────────────┘

Even quicker memory trick:

Quote

stop = pause the party,
down = pack up and clean the house.

TOMillr · Apr 26th 2025

Thanks. I'm still struggling to understand how compose down affects data and settings the container has written to disk. Dockerdocs says:

Quote

Networks and volumes defined as external are never removed.

Anonymous volumes are not removed by default. However, as they don’t have a stable name, they are not automatically mounted by a subsequent up. For data that needs to persist between updates, use explicit paths as bind mounts or named volumes.

So in my example of Plex running in a container, the data written to /config would be "reused" after an down-up-circle as long as I don't change the volume paths in the compose file?

Code

services:
  plex:
    container_name: plex
    image: plexinc/pms-docker
    restart: unless-stopped
    environment:
      - PUID=1001
      - PGID=100
      - TZ=Europe/Berlin
      - PLEX_CLAIM=XYZ
    network_mode: host
    volumes:
      - CHANGE_TO_COMPOSE_DATA_PATH/plex/config:/config
      - CHANGE_TO_COMPOSE_DATA_PATH/plex/transcode:/transcode
      - /srv/dev-disk-by-uuid-7f281e78-cec0-4bf2-a4b9-6d9003ebcb4e/Video:/data
    devices:
      - /dev/dri:/dev/dri

Display More

theking2 · Apr 26th 2025

All those volumes are bind volumes. That means they stay on the host and will be there whatever you do on docker. You might remove the container but with the same compose.yaml they will just be there when you (re)create the container.

Everything not bound will be lost if you (re)create the container.

EDIT: I do not know what CHANGE_TO_COMPOSE_DATA_PATH are.

Btw. the Settings section in your omv-compose define what is put where. I have

created a shared folder appdata sitting somewhere on my zfs pool
in Serivices/Compose/Settings I've specified Compose Files to use this share

And for each container (Services/Compose/Files) it will contain a folder named after the name of the container. The root of each container is that folder.

Zafkiel · Apr 26th 2025

Quote from TOMillr

So in my example of Plex running in a container, the data written to /config would be "reused" after an down-up-circle as long as I don't change the volume paths in the compose file?

Yeah, just like the /srv/dev-disk-by-uuid-7f281e78-cec0-4bf2-a4b9-6d9003ebcb4e/Video:/data in your compose file, running "down" will not delete it.

Quote from theking2

EDIT: I do not know what CHANGE_TO_COMPOSE_DATA_PATH are.

You'll find it mentioned in the compose plugin settings and the Docker documentation for OMV.

omv7:docker_in_omv [omv-extras.org]

theking2 · Apr 27th 2025

Quote from Zafkiel

You'll find it mentioned in the compose plugin settings and the Docker documentation for OMV.
https://wiki.omv-extras.org/do…cker_in_omv#configuration

Yes but it has to set/changed, doesn't it?

theking2 · Apr 27th 2025

Ok. now I get it.

It's a magical OMV variable when used in Compose/Files will be replaced by whatever is in Settings.

In my settings it is pointed to a volume on my zfs pool but stays empty.

The persistant storage is in appdata on another volume on another volume. Compose neatly keeps this organized by docker name so I fail to se the use case for CHANGE_TO_COMPOSE_DATA_PATH.

chente · Apr 27th 2025

Quote from theking2

I fail to se the use case for CHANGE_TO_COMPOSE_DATA_PATH.

It all depends on your intended use. For example, it can be very useful on systems with a single storage file system. If you define the variable to point to that file system, all volumes will be placed there.

ryecoaaron · Apr 27th 2025

Quote from theking2

so I fail to se the use case for CHANGE_TO_COMPOSE_DATA_PATH.

Don't use it then. It is completely optional. It is just a simple way to put the path of a shared folder set on the Setting tab in your compose file without using a variable.

The actual CHANGE_TO_COMPOSE_DATA_PATH string is only shown in the File editor in the plugin and database. When the compose file is written to the filesystem, the string is changed to the absolute path of the shared folder.

It also allows me to set a non-named, non-relative path in the example compose files and they will just work. If I put a variable in the example compose files, people would get data in unexpected places if they forgot to set the variable. I use it in all of my compose files as well. It works quite well no matter how many filesystems you have but it does work better with a single filesystem when using the setup style of the compose wiki.

Participate now!