This thread got me wondering how Docker on DSM manages container data when the persistent/generated data is not mapped to a DSM folder.

Having read this Manage data in Docker and then poked around inside DSM I find that 'volumes' are located here: /volume1/@appstore/Docker/docker/volumes/ which is a link to /volume1/@docker/volumes. In this folder I have 45 'volume' folders for five containers.

I created a new container from an image (postgresql) and noted that a new folder is created in .../volumes. When the container runs the psql DB folder hierarchy is created in subfolder _data.

I then stopped the container and did the Clear action: nothing happened to the data (ok the folder hierarchy), but a new empty folder in .../volumes was now created. When I ran the cleaned container it was in here that a new set of psql DB folders were created.

So what to think?

• DSM's Clear action dissociates a container from its current Docker volume (and data).
• It's not easy to associate a container to a volume folder (random-unique folder names), so copying data from one Docker volume to another is guesswork.
• DSM's Clear action doesn't actually delete all container data as it claims: it just creates a growing archive of old folders.
• There's a reason Clear doesn't delete old volume folders and that's because Docker (not just DSM's implementation) allows containers to access other volumes and there's probably no map of when a volume folder is no longer required.
• Be aware that containers might store sensitive data in these forgotten folders.

So while Docker docs say that they recommend using volumes over bind mounts, unless it can be otherwise argued, I'd lean towards using bind mounts for container data ... until DSM Docker provides a more transparent method to manage volumes, both deleting obsolete volumes and re-attaching volumes to cleaned containers.

I'd be really interested in anyone's thoughts on this.

Edit:
Read the Docker docs, took a gamble and ran sudo docker volume prune. It removed all but two volume folders and recovered 300MB of space ... mostly psql DB and sqlite DB files.

Docker is usally used with an operator like Swarm or Kubernetes. Image your your container respawn on a different host, bind mounts are not cut out for this type of scenario, are they? Though for a single host usage, bind mounts are the most convinient way.

Named volumes are first class citizens in the docker world, bind mounts are not. While for named volumes, the default behavior is to copy the content of the target folder into the volume, a bind mount "replaces" the target folder. The Syno Docker UI does not allow to create named volumes. Fun fact: It is possible to create named volumes from the command line that use the local driver and the type bind to actualy get benefits of both worlds *cough*

Whenever a VOLUME is declared in a Dockerfile, but neither a named volume, nor a bind mount is mapped to the target folder, an anonymous volume with a random alphanum characters name is created. Even on the command line, when you delete a container, you have to specificly provide an argument to delete anonymous volumes with container.

On the command line, you can re-attach a known anonymous volume to a new container. Noone realy does that.

The clear action simply removes the old container and creates a new one using the old parameters. A container is always bound to a specific sha256 id of the image, which the tag pointed to the time of container creation. If the underlying image gets replaced on Dockerhub and pulled localy, the tag points to a new sha256 id.

If you'd run portainer, you could see which volumes are orphaned and clean them up easily.
On the command line, you can run docker volume prune to get rid of orphaned volumes.

Was about to say, portainer ftw

I had read around Docker before and (along with your posts) know the DSM Docker implementation [by which I mean via the Syno. GUI] is 'lite' vs what the Docker-sphere can do. Yet I'm a bit surprised it how DSM Docker works and leaves stale data behind when it claims to remove it.

What DSM Docker does at the backend makes sense when considering Docker usage generally but it doesn't do what it tells the DSM user. I'd also say that the GUI should have a self-contained set of GUI features for the general user to fully manage their containers and data. For power-users then there are other resources, as you mention.

And the Synology documentation is pretty slim on this matter (where 'slim' also can be interpreted as vague and ambiguous).

one-eyed-king said:

On the command line, you can re-attach a known anonymous volume to a new container. Noone realy does that.

Click to expand...

I wouldn't've guessed, what with those easy to track unique names! Anonymous naming does sort-of imply you don't consider portability.

one-eyed-king said:

If you'd run portainer, you could see which volumes are orphaned and clean them up easily.
On the command line, you can run docker volume prune to get rid of orphaned volumes.

Click to expand...

Rusty said:

Was about to say, portainer ftw

Click to expand...

Yeah, I found 'volume prune' and did it. But if I wanted to work lots on the command line I'd have got a Mac or Linux server. Been there, bought the t-shirt, spilt coffee down it, and slept in it slumped across a desk. Many years ago!

Will have a look at portainer. Thx

Actualy, it would be an amazing addition to the ui if it provides volume management.
It should allow to create named volumes as bind or for cifs/nfs remote shores. It should highlight orphaned volumes and allow to prune them on a button click. The same thing should be implemented for images as well.
The volume mapping tab would need to be enhanced to either pick a file/folder or a named volume.

Also, I would like to see a feature to manage docker-compose.yml files directly in the ui, like you can do with Portainer. This would allow non shell users to benefit from docker-compose without struggling with the command line.

Now where DDSM is gone, they should completly replace their self maintained docker package with the unmodified binaries or at least compile unmodified sources in order to be able to update the package more frequently.