Unter Centos7 & Docker 1.8.2 konnte ich die Lösung von Zgr3doo nicht verwenden, um per Devicemapper zu mounten (ich glaube, die Antwort war, dass das Volume nicht gemountet / gefunden wurde.)
Ich glaube, ich hatte auch ein ähnliches Problem mit der Antwort von sk8terboi87: Ich glaube, die Meldung lautete, dass die Volumes nicht abgemeldet werden konnten, und listete die spezifischen Volumes auf, die versucht wurden, die Bereitstellung aufzuheben, um die toten Container zu löschen.
Was für mich funktioniert hat, war, Docker zuerst zu stoppen und dann die Verzeichnisse manuell zu löschen. Ich konnte anhand der Fehlerausgabe des vorherigen Befehls feststellen, um welche es sich handelt, um alle toten Container zu löschen.
Entschuldigung für die vagen Beschreibungen oben. Ich fand diese SO-Frage Tage nachdem ich die toten Container gehandhabt hatte. .. Allerdings habe ich heute ein ähnliches Muster bemerkt:
$ sudo docker stop fervent_fermi; sudo docker rm fervent_fermi fervent_fermi
Error response from daemon: Cannot destroy container fervent_fermi: Driver devicemapper failed to remove root filesystem a11bae452da3dd776354aae311da5be5ff70ac9ebf33d33b66a24c62c3ec7f35: Device is Busy
Error: failed to remove containers: [fervent_fermi]
$ sudo systemctl docker stop
$ sudo rm -rf /var/lib/docker/devicemapper/mnt/a11bae452da3dd776354aae311da5be5ff70ac9ebf33d33b66a24c62c3ec7f35
$
Bei diesem Ansatz ist mir aufgefallen, dass Docker die Bilder mit unterschiedlichen Namen neu erstellt hat:
a11bae452da3 trend_av_docker "bash" 2 weeks ago Dead compassionate_ardinghelli
Dies kann daran liegen, dass der Container immer mit restart = ausgegeben wurde. Die Container-ID stimmt jedoch mit der ID des Containers überein, der zuvor das Volume verwendet hat, das ich zwangsweise gelöscht habe. Es gab keine Schwierigkeiten, diesen neuen Container zu löschen:
$ sudo docker rm -v compassionate_ardinghelli
compassionate_ardinghelli
