Open pjonsson opened 3 months ago
Hi Team, Same Issue here. My Images got deleted after install drive through snap
And also all the containers in the which are running in process
I started getting permission denied errors when doing docker compose down
. Turns out that is caused by AppArmor. After some more digging, it turns out I had somehow gotten docker through snap, which mixed with the Debian docker packages from Docker.com that I want to use:
# docker info
Client: Docker Engine - Community
Version: 27.1.2
Context: default
...
Server:
Containers: 6
Running: 5
Paused: 0
Stopped: 1
Images: 16
Server Version: 24.0.5 <<--------------------- THIS
...
# snap list | grep docker
docker 24.0.5 2915 latest/stable canonical** -
Removing the snap-installed docker killed my running containers, and then ran tar+gzip for half an hour:
# snap remove docker
2024-08-19T14:22:10+02:00 INFO Waiting for "snap.docker.dockerd.service" to stop.
Save data of snap "docker" in automatic snapshot set 3
until it finally said docker removed
, so I guess I should have run docker system prune -af --volumes
to remove my docker images+cache+volumes before asking snap to remove docker. While snap was running tar+gzip, docker info
looked like this:
Client: Docker Engine - Community
Version: 27.1.2
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.16.2
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.29.1
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
errors pretty printing info
So suddenly getting a new containerd when doing snap install dive
explains why the images disappeared. It would be nice with a big warning both in the README and in the dive-snap-package that it's not "compatible" with the upstream Docker packages.
it's a disaster without any warning. I got traped too. The snap approach is not fully tested and should get removed from the README.md.
The after-trap solution is:
disconnect, then remove the stupid snap pkgs:
sudo snap disconnect dive:docker-executables docker:docker-executables
sudo snap disconnect dive:docker-daemon docker:docker-daemon
sudo snap remove dive
sudo snap remove docker
kill all docker associated processes:
sudo systemctl stop docker
sudo pkill -9 -f docker
restart the docker deamon process:
sudo systemctl restart docker
sudo nohup dockerd &
And, never try snap approach again, if your docker is installed by apt-get.
+1 how to push this issue more? It's not self explanatory that it requires docker installed via snap (who does this anyway?) and it just install it without asking (Or did I miss this? I did not install it with 'snap install docker'). @wagoodman
I was trying to get a better understanding of what was taking space in a local image, so I ran
docker inspect ...
just before installing dive through snap, and after doingsnap install dive
my images indocker images
were gone.The
snap install dive
downloaded something and then entered some "configuration stage" (don't recall what it said, but the terminal replaced the line withdive 0.12.0 from Guillaume Belanger (gruyaume) installed
when it completed) that took quite a long time. I had 30-40 images, so the time in the "configuration stage" is on par with how long it would take to delete the images withdocker system prune
.I do not have Docker installed through snap, I'm using the Docker deb packages from Docker.com on Ubuntu 24.04, currently with Docker 27.1.1. I also only have the default Docker context.
It seems @RafaelWO had the same problem a couple of weeks ago:
Originally posted by @RafaelWO in https://github.com/wagoodman/dive/issues/542#issuecomment-2257812333