Docker ".../mounts/shm" ? What? Why?

[Telos]

Just curious... When running `df -h`, I have several lines reading:

64M  6.3M   58M  10% /volume1/@docker/containers/5aa0312poewfj76efvevb48640d3cskux82jfb6a804ab1777467c/mounts/shm

Three of my 12 running containers (calibre, jackett, sonarr ... notably, NOT radarr) appear like this. When I stop the container, the entry vanishes.

What is it about these containers that differ from the others. I'm curious... wondering what setting, if any I may have used that has this effect.

Thanks!

 

[one-eyed-king]

There is nothing to worry about, it's shared memory used for inter-process communication. I highly suggest to leave it alone

Update: maybee I am mistaken. Normaly every container should have a mount like this (size can be adapted dending on the application needs): for shared memory:

shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)

Thus said, I am not sure what the mount you see should be, as shm should be of type tmpfs (=in-memory) and not be on a filesystem.

update2: I though you mean inside the container. I do have those on the Syno as well - but on none of my other docker hosts.

update3: I think I understand what it is: it is mountpoint of shm inside the container filesystem - what I wrote in the first line is indeed correct.

You can see that it's the shm of type tmpfs if you check it like this:

mount | grep shm

The output will provide the relevant details:

/dev/shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
shm on /volume2/@docker/containers/df06e86152a9fe9a46ee980c19e53c7c1635ca08ee36ef34ff6b9b2b6ff83855/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)

 

[Telos]

update2: I though you mean inside the container. I do have those on the Syno as well - but on none of my other docker hosts.

To clarify... this was from NAS root "/", not from within a docker container.

 

[one-eyed-king]

I understood that already and updated my post accordingly.

It is nothing to worry about!

 

[Telos]

Why only 3 containers? What distinguishes them that this would be present?

 

[one-eyed-king]

I have no idea ^^ As far as I know every container has shm mounts - if you enter the containers you will see that each one has. Though, I realy have no idea why an additional mountpoint in the container filesystem is created and the shm is mounted into that mountpoint.

I looked at my plex container, which has the mountpoint in its container folder, but inside the contaienr there is no evidance for special treatment that would lead to this.

Does it happen for fresh created container as well - or is it a behavior of containers that have been created long time ago?

-- post merged: 27. May 2022 --

To verify my suspicion I stopped and deleted my watchtower container. It also had a shm mountpoint in its container filesystem. The new created one does not! The same behavior can be observed if the affected container was created with docker-compose.

Some vague theories about why it exists for some containers:
1. it is something the Syno does after a reboot (I doubt it, but I am also not going to test it)
2. it is something watchtower does when replacing the container after an image updaet
3. the affected container where created with a docker version that actualy had that behavior. Since the container is not re-created after updating the docker version, the container still has the old behavior. My affected containers were created 13 months ago.

 

[Telos]

There's no time line break specific to these containers radarr and sonarr were created together, but only sonarr shows this behavior. I'll "recreate" it to see if there is a difference. I have 4 containers created through Portainer "Stacks" (all docker-compose). None of those show this.

As you said, it's probably (hopefully) inconsequential

 

[one-eyed-king]

As you said, it's probably (hopefully) inconsequential

I thought by now you would have understood that we are discusing about an empty folder used as mountpoint to mount an in-memory tmpfs filesystem into, which exists in the container anyways