No images in `docker images` after `snap install dive`

[pjonsson]

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 doing snap install dive my images in docker 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 with dive 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 with docker 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.

$ snap info dive
name:      dive
summary:   A tool for exploring each layer in a docker image
publisher: Guillaume Belanger (gruyaume)
store-url: https://snapcraft.io/dive
license:   MIT
description: |
  Dive is a tool for exploring a docker image, layer contents, and
  discovering ways to shrink the size of your Docker/OCI image. To learn more
  about dive, see https://github.com/wagoodman/dive.

  **Usage**

  Install the Docker and Dive snaps and connect them:

     sudo snap install docker
     sudo snap install dive
     sudo snap connect dive:docker-executables docker:docker-executables
     sudo snap connect dive:docker-daemon docker:docker-daemon

  Run `dive`:

     dive ubuntu:latest
snap-id: MudyYZqdJlVtqfObbi6wN5bOzZM7JKft
channels:
  latest/stable:    0.12.0 2024-03-03 (20) 7MB -
  latest/candidate: 0.12.0 2024-03-03 (20) 7MB -
  latest/beta:      0.12.0 2024-03-03 (20) 7MB -
  latest/edge:      0.12.0 2024-03-10 (26) 7MB -

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

[thowbikdustan]

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

[pjonsson]

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.

[YuanfengZhang]

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:

1. 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

2. kill all docker associated processes:

sudo systemctl stop docker
sudo pkill -9 -f docker

3. 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.

[Hawxxer]

+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

[jinshengye-git]

Same issue, using snap install and it ruined my life 👎👎👎👎👎

[pbanuru]

I installed Dive (likely with sudo snap install), and afterward, my containers disappeared. I rebuilt them the next day, but then ran into numerous Docker issues. Even with help from O1 and claude3.5sonnet for an entire day, I couldn’t resolve the problems (didn't connect the dots to dive and find this thread) and ended up reinstalling Linux.

Here’s the error I was getting:

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy'
nvidia-container-cli: initialization error: load library failed: libnvidia-ml.so.1: cannot open shared object file: no such file or directory: unknown

I don’t know if Dive caused it, but it’s the only thing I know of that changed before things stopped working.

[anoya-ik]

I had the same issue and this is what i did to solve it:

1. Uninstall dive and Docker snap package:

sudo snap remove dive sudo snap remove docker

2. Ensure all docker services are stopped:

sudo systemctl stop docker sudo systemctl stop docker.socket

3. Modify Docker Service Configuration

sudo nano /lib/systemd/system/docker.service

Locate the line starting with ExecStart and modify it to:

ExecStart=/usr/bin/dockerd --data-root /var/lib/docker -H fd:// --containerd=/run/containerd/containerd.sock

4. Reload system and restart Docker

sudo systemctl daemon-reload sudo systemctl restart docker

5. Verify Docker functionality

docker images docker ps -a

[wagoodman]

Is there anything in what is declared in a snap package that can help here? It might be that the packaging of dive needs to be adjusted (or it's something more environmental).

[maxencealluin]

Has anyone found a way to restore functionality while saving currently running volumes / containers / images? This should be ASAP removed from the readme i am appalled that a 50k star package suggests an installation command that utterly breaks systems. The small warning AFTER the command is not sufficient.

EDIT: For anyone having the same issue, I was able to restore functionality. Installing dive will reinstall docker with snap which uses a different folder to hold docker data. The data from your previous docker installation should still exist under /var/lib/docker/.

Uninstalling docker with snap, stopping the two daemons and restarting them should do the trick.

[anoya-ik]

Is there anything in what is declared in a snap package that can help here? It might be that the packaging of dive needs to be adjusted (or it's something more environmental).

I think that when you install dive via Snap, it may implicitly install the Snap version of Docker as a dependency. This can interfere with your existing Docker setup installed via Debian packages. Specifically, the Snap version of Docker uses a different data root directory (/var/snap/docker/common/var-lib-docker) compared to the standard Docker installation (/var/lib/docker). As a result, Docker commands may no longer recognize your existing images and containers, giving the impression that they have been deleted

[gruyaume]

Hello,

I created and published the snap for Dive, initially out of necessity. Unfortunately, however, I don't have the time, domain knowledge, or interest to maintain it over the long term, and I offered to hand it back to the maintainers here. This offer still stands, of course. While I don't intend to troubleshoot the problem, if someone else identifies the issue and proposes the change in the snap project, I will be happy to review it and merge it. Another option is to archive the snap and point users to other installation methods, but the snap has almost 4k active devices (and growing!), clearly demonstrating interest in it. @wagoodman , you lead this project here so I'll let you make that call.

Cheers,

[jose-lpa]

Hello,

I created and published the snap for Dive, initially out of necessity. Unfortunately, however, I don't have the time, domain knowledge, or interest to maintain it over the long term, and I offered to hand it back to the maintainers here. This offer still stands, of course. While I don't intend to troubleshoot the problem, if someone else identifies the issue and proposes the change in the snap project, I will be happy to review it and merge it. Another option is to archive the snap and point users to other installation methods, but the snap has almost 4k active devices (and growing!), clearly demonstrating interest in it. @wagoodman , you lead this project here so I'll let you make that call.

Cheers,

To be honest, and with full respect for the job and the time you took to do it, I would say it may be better to simply not offer Snap install at this point. It's ruining the systems of so many people, so IMHO it will be better to just remove the Snap package from the repo and let people install in other ways. It is too unsafe for the public, unfortunately, and if you don't have the time to fix it (which is totally understandable), it's better not to offer it.

[julio-gorge]

I'd encourage removing the snap installation method from the README, it breaks existing Docker installation in many cases.

[KonstantinBobrov]

Windows 11 After using 'sudo snap install dive' I've got WSL2 issue - empty process and images list I fixed it by turning on Ubuntu integration in Docker Desktop app Settings -> Resources -> WSL Integration Now Docker works under WSL2, but Ubuntu dive version does not work, I'm getting

ubuntu:~$ dive mysql Image Source: docker://mysql Fetching image... (this can take a while for large images) cannot fetch image could not find 'blobs/sha256/7af7a034b8b97178bcf870b6c177401cbc755d5aa22ffe1c1b7e3a082fbce51b' in parsed layers

Upd. I installed Dive in PowerShell, it works

[Rowamo]

Thank you to those who explained how to revert the this terrible issue. With all due respect to the owner of this repo, I hope no one else uses this because it gave me a slight heart attack.

[Tramis]

I can't believe now after a year, this problem is still here. To make sure everybody after me will be scared by this problem but eventually solve it, I will contribute some related solution:

snap remove dive snap remove docker

If you see: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? But the docker is active(running)

And ls -l /var/run/docker.sock shows ls: cannot access '/var/run/docker.sock': No such file or directory

Then please try restart the socket:

# 1
sudo systemctl stop docker.service
sudo systemctl stop docker.socket

sudo systemctl start docker.socket

# check if it appears
ls -l /var/run/docker.sock

[tapionx]

unbelievable