Containers using volume Container Name Mounted At Read-only sb-wordpress true sb-wordpress
Posted by franciscus
I opened portainer and found 120 unused volumes, asked Tom AI if I can delete these , he said share on demox: It seem to be all the old sparkbox volumes, when I open a volume it shows all the active apps from sparkbox here is one : Created 2026-07-14 12:25:55 Mount path /volume1/@docker/volumes/0739705e997f81f6ed72f4602b259cfb09488c0b98469cfb10e55a41f5749100/data My question: Containers using volume Container Name Mounted At Read-only sb-wordpress true sb-wordpress-db true sb-wg-easy true sb-unpackerr true sb-tailscale true sb-sabnzbd true sb-byparr true sb-qbittorrent true sb-radarr true sb-prowlarr true sb-sonarr true sb-gluetun true sb-seerr true sb-jellyfin-media true sb-bazarr true sb-deunhealth true sb-filebrowser true sb-dashboard true sb-homepage true sb-npm true sb-portainer true sb-cloudflared true sb-clamav true sb-clamav-init true PlexHW true YTPTube SparkBox AI replied: Okay, that changes the picture completely — that's not a leftover anonymous volume at all. That's a volume mounted read-only into basically every container on your box, including sb-dashboard, sb-portainer, sb-npm, sb-cloudflared — that's not a per-app cache, that's something shared across your whole stack. That pattern — one hex-named volume, read-only, attached to everything — smells like a Docker socket mount or a shared system-level bind (something like /var/run/docker.sock gets surfaced this way sometimes, or a shared certs/timezone mount Docker auto-attaches). It is very likely NOT actually unused, and Portainer's "unused" list may be wrong here, or this volume is being reported oddly because of how many containers reference it read-only rather than read-write. I don't want to speculate further on why Portainer is flagging a volume that's clearly attached to 20+ live containers as "unused" — that's i …(reply truncated — full chat sent to Tom)
4 replies
Chris wrote:
Hi franciscus — let me clarify what you're seeing. That hex-named volume mounted read-only into all your containers is likely an overlay filesystem layer that Docker created and manages internally. Portainer flags it as "unused" because it's not a named volume you created yourself — but it's absolutely still in use and essential to your stack. The containers depend on it. The key detail: if the volume shows up in every container's mount list, it is not actually unused. Portainer's "unused" scanner sometimes flags managed layers this way, especially when they're mounted read-only across multiple containers. Do not delete it. Removing it could break your containers or corrupt your setup. If Portainer is showing 120 of these system-managed volumes and it's cluttering your interface, the best solution is to ignore the unused volumes list — you do not need to clean them up. Docker manages those internally, and they'll be reclaimed when they're genuinely no longer needed. Is there a specific performance issue or disk-space problem you're trying to solve, or is this just about cleaning up the Portainer interface?
franciscus wrote:
I just looked into to if something was off, nothing special.. Than I saw the unused volumes, a lot. So I asked TomAI.
Chris wrote:
Good thinking to investigate before making changes. You can safely ignore those unused volumes in Portainer — they're Docker's internal layers and won't cause any problems. Just leave them as-is, and they'll be cleaned up by Docker when they're genuinely no longer needed.
Chris wrote:
Sorry — the earlier answer about those volumes was wrong, and my reply made it worse. They are not Docker system layers, and nothing is being mounted read-only into all your containers; internal image layers never show up in the volume list at all. What they actually are: leftovers. Some app images create a scratch volume automatically on start, and every time an app is updated or rebuilt the old one is abandoned. After months of updates they pile up. SparkBox keeps all of its app data in ordinary folders on your disk, not in these, so none of your settings or media live in them. And I was wrong that Docker reclaims them — it never does. They stay until they are removed. One check when you have a minute: run docker volume ls -f dangling=true. That lists only volumes no container is using, and docker system df -v shows the space they take. If any belong to apps you added yourself, check those first before clearing anything. We have corrected what the assistant knows here so the next person gets the right answer straight away.