Błąd dokera: brak miejsca na urządzeniu

329

Zainstalowałem dokera na maszynie Debian 7 w następujący sposób

$ echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list
$ sudo apt-get update
$ curl -sSL https://get.docker.com/ubuntu/ | sudo sh

Po tym, jak po raz pierwszy spróbowałem utworzyć obraz, wystąpił błąd z następującym błędem

 time="2015-06-02T14:26:37-04:00" level=info msg="[8] System error: write /sys/fs/cgroup/docker/01f5670fbee1f6687f58f3a943b1e1bdaec2630197fa4da1b19cc3db7e3d3883/cgroup.procs: no space left on device"

Oto informacje o dokerze

Containers: 2
Images: 21
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 25
Dirperm1 Supported: true
Execution Driver: native-0.2
Kernel Version: 3.16.0-0.bpo.4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
CPUs: 2
 Total Memory: 15.7 GiB


WARNING: No memory limit support
 WARNING: No swap limit support

Jak mogę zwiększyć pamięć? Gdzie są przechowywane konfiguracje systemu?

Z sugestii Kal:

Kiedy pozbyłem się wszystkich obrazów i kontenerów, zwolniło to trochę miejsca, a kompilacja obrazu działała dłużej, zanim zakończyła się tym samym błędem. Pytanie brzmi: do której przestrzeni to odnosi się i jak ją skonfigurować?

user_mda
źródło
1
Czasami możesz osiągnąć limit wielkości dla kontenera , w zależności od zaplecza pamięci. Ten link pokazuje, jak to naprawić dla devicemapper.
jpaugh
4
Miałem ten błąd, gdy na moim dysku brakowało i-węzłów. Sprawdźdf -ih
Kevin Smyth
@KevinSmyth Dziękuję bardzo za zwrócenie na to uwagi. Nie wiedziałem nawet wcześniej o znaczeniu limitów i-węzłów.
yosefrow

Odpowiedzi:

337

Miałem ten sam błąd i rozwiązałem go w ten sposób:

1. Usuń osierocone woluminy w Dockerze, możesz użyć wbudowanego polecenia woluminu dokera. Wbudowane polecenie usuwa również każdy katalog w / var / lib / docker / woluminach, który nie jest woluminem, więc upewnij się, że nie wstawiłeś tam niczego, co chcesz zapisać.

Ostrzeżenie, bądź bardzo ostrożny, jeśli masz jakieś dane, które chcesz zachować

Sprzątać:

$ docker volume rm $(docker volume ls -qf dangling=true)

Dodatkowe polecenia:

Lista wiszących woluminów:

$ docker volume ls -qf dangling=true

Wyświetl wszystkie tomy:

$ docker volume ls

2) Rozważ również usunięcie wszystkich nieużywanych obrazów.

Najpierw pozbądź się <none>obrazów (czasami są one generowane podczas budowania obrazu i jeśli z jakiegoś powodu tworzenie obrazu zostało przerwane, pozostają tam).

oto fajny skrypt, którego używam do ich usunięcia

docker rmi $(docker images | grep '^<none>' | awk '{print $3}')

Następnie, jeśli używasz Docker Compose do tworzenia obrazów lokalnie dla każdego projektu. Skończysz z wieloma obrazami zwykle o nazwie tak jak twój folder (na przykład jeśli folder projektu o nazwie Witaj, znajdziesz nazwę zdjęć Hello_blablabla). więc rozważ również usunięcie wszystkich tych obrazów

możesz edytować powyższy skrypt, aby je usunąć lub usunąć ręcznie za pomocą

docker rmi {image-name}

Mahmoud Zalt
źródło
23
Tylko uwaga: polecenia awk na komputerze Mac muszą być otoczone pojedynczymi cudzysłowami, a nie podwójnymi, w przeciwnym razie zostaną po prostu zignorowane.
ndtreviv
2
Jestem na MAC i to działa dla mnie !! ale dziękuję za radę.
Mahmoud Zalt
2
Jak dziwnie! To nie działa dla mnie. Po prostu drukuje te same wyniki co grep. Ach tak. Dziwniejsze rzeczy się wydarzyły.
ndtreviv
3
W tym momencie możesz użyć tego samego filtra do zdjęć. docker images -qf dangling=truei oczywiście usuń je za pomocą docker rmi $(docker images -qf dangling=true).
Tyler Jones
3
Pojawia się błąd: „wolumin dokowania rm” wymaga co najmniej 1 argumentów.
IgorGanapolsky
330

AKTUALIZACJA
Poniższe polecenia stały się hackami, gdy Docker stał się bardziej rozwinięty. Obecna najlepsza praktyka to

docker system prune

Spowoduje to usunięcie:

- all stopped containers
- all volumes not used by at least one container
- all networks not used by at least one container
- all dangling images

Jak poniżej, to jest nuklearne.


Aby wyczyścić system, najpierw usuń pojemniki

$ docker rm $(docker ps -aq)

następnie usuń obrazy

$ docker rmi $(docker images -q)

Jest to oczywiście kwestia nuklearna i usunie wszystkie pojemniki i wszystkie obrazy. Możesz je usunąć pojedynczo za pomocą docker rm #CONTAINER_ID#i docker rmi #IMAGE_ID.

Joshua Cook
źródło
2
jak zauważył Kevin Smyth, ten błąd jest prawdopodobnie spowodowany brakiem i-węzłów, które można zobaczyć df -ih. Aby zdiagnozować bardziej chirurgicznie, wprowadź, ncdua następnie naciśnij c, aby zliczyć liczbę plików i C, aby posortować według liczby plików, aby uzyskać przybliżone oszacowanie zużycia wszystkich i-węzłów. Jeśli problem rzeczywiście dotyczy dokera, katalogi wykorzystujące najwięcej i-węzłów natychmiast go zauważą.
yosefrow
2
Naprawdę należy to głosować i udzielić odpowiedzi, ponieważ jest to właściwe podejście. Środowisko dla budynku zostało zanieczyszczone i teraz włamuj się tu i tam może go tymczasowo naprawić, ale właściwe podejście powinno byćdocker system prune
zhrist
@zhrist Haha Zgadzam się
Joshua Cook
@ coler-j Może ... jeśli zastanawiasz się nad oryginalnym, wysoce szczegółowym pytaniem. Ale bądźmy ze sobą szczerzy. Większość ludzi nie znajduje tego pytania z powodu niejasnego przypadku użycia OP, ale ponieważ w pamięci podręcznej dokerów po prostu zabrakło miejsca.
Joshua Cook
@JoshuaCook to w rzeczywistości bardzo częsty problem: github.com/docker/for-win/issues/1042 bez prawdziwego rozwiązania. Po prostu próba znalezienia przyczyny tego problemu jest bardzo frustrująca. :(
coler-j
70

Sprawdź, czy masz wolne miejsce w / var, ponieważ Docker domyślnie przechowuje pliki obrazów (w / var / lib / docker).

Najpierw posprzątaj rzeczy za pomocą, docker ps -aaby wyświetlić listę wszystkich pojemników (w tym zatrzymanych) i docker rmusunąć je; następnie użyj, docker imagesaby wyświetlić listę wszystkich zapisanych obrazów i docker rmije usunąć.

Następnie zmień miejsce przechowywania za pomocą opcji -g na demonie dokera lub edytując /etc/default/dockeri dodając -gopcję do DOCKER_OPTS. -gokreśla lokalizację „środowiska wykonawczego Docker”, które jest w zasadzie wszystkim, co Docker tworzy podczas budowania obrazów i uruchamiania kontenerów. Wybierz lokalizację z dużą ilością miejsca, ponieważ używane miejsce na dysku będzie z czasem rosło. Jeśli edytujesz /etc/default/docker, musisz ponownie uruchomić demona dokera, aby zmiana zaczęła obowiązywać.

Teraz powinieneś być w stanie utworzyć nowy obraz (lub pobrać go z Docker Hub) i powinieneś zobaczyć kilka plików tworzonych w katalogu określonym opcją -g.

Kal
źródło
Dzięki Kal, nie mogłem znaleźć dokumentacji dotyczącej DOCKER_OPTS. Co oznacza opcja -g i na co powinna być ustawiona? Czy można również usunąć rzeczy w oknie dokowanym / aufs / mnt?
user_mda,
Hej ruby, nie sądzę, żebym kiedykolwiek znalazł prawdziwy dokument na temat DOCKER_OPTS, ale w dokumentacji są miejsca, które mówią o edycji. Najbliżej mogę znaleźć na końcu docs.docker.com/installation/ubuntulinux/…, gdzie mówi o edycji ustawień DNS w DOCKER_OPTS. Opcje w DOCKER_OPTS są właśnie przekazywane do demona, więc odnośnikiem jest docs.docker.com/reference/commandline/cli/#daemon . -g ustawia podstawową lokalizację „środowiska wykonawczego Docker”
Kal
Czy można również usunąć rzeczy w oknie dokowanym / aufs / mnt?
user_mda
Nie usuwaj tych rzeczy ręcznie. Zamiast tego usuń niepotrzebne pojemniki (w tym opuszczone) i obrazy. Powinieneś to zrobić przed zmianą opcji -g. Służy docker ps -ado wyświetlania wszystkich kontenerów (w tym opuszczonych), a następnie docker rmdo ich usunięcia. Użyj, docker imagesaby wyświetlić listę wszystkich zdjęć, a następnie docker rmije usunąć. Mam nadzieję, że to powinno wszystko wyczyścić (lub większość rzeczy).
Kal
Dzięki, więc wyczyszczenie obrazów i pojemników zwolniło trochę miejsca. Ale czy nowszy obraz nadal potrzebuje więcej. Ale na co powinno wskazywać środowisko wykonawcze dokera ?, czy istnieje sposób na zwiększenie przestrzeni używanej przez dokera do przechowywania obrazów?
user_mda
37

Jak już wspomniano

docker system prune

pomaga, ale z Dockerem 17.06.1 i nowszymi bez przycinania nieużywanych woluminów. Od wersji Docker 17.06.1 następujące polecenie również przycina woluminy:

docker system prune --volumes

Z dokumentacji Docker: https://docs.docker.com/config/pruning/

Polecenie przycinania systemu dokowania to skrót, który przycina obrazy, kontenery i sieci. W Docker 17.06.0 i wcześniejszych woluminy są również przycinane. W Docker 17.06.1 i nowszych wersjach należy określić flagę --volumes dla systemu dokowania przycinaj woluminy.

Jeśli chcesz przyciąć woluminy i zachować obrazy i kontenery:

docker volume prune
RoBeaToZ
źródło
3
docker volume prunepomógł mi dzisiaj, kiedy wszystkie inne rozwiązania tutaj przestały działać.
AVProgrammer,
1
Ogromna pomoc - oprócz naprawienia błędu uwolniło to wiele koncertów na moim dysku twardym.
Matt Browne,
29

Jeśli jest to tylko instalacja testowa Dockera (tj. Nieprodukcyjna), a nie obchodzi Cię czyszczenie nuklearne, możesz:

wyczyść wszystkie pojemniki: docker ps -a | sed '1 d' | awk '{print $1}' | xargs -L1 docker rm

wyczyść wszystkie obrazy: docker images -a | sed '1 d' | awk '{print $3}' | xargs -L1 docker rmi -f

Ponownie używam tego w moich instancjach ec2 podczas opracowywania Dockera, a nie na poważnej kontroli jakości lub ścieżce produkcyjnej. Wspaniałą rzeczą jest to, że jeśli masz plik (i) Docker, łatwo go odbudować i lub docker pull.

James
źródło
1
W mojej instancji boot2docker musiałem zadzwonić docker images -a | sed '1 d' | awk '{print $3}' | xargs docker rmi -f. Wersja OS X BSD xargsobsługuje tę -Lopcję, w przeciwieństwie do wersji boot2docker.
orluke
1
Możesz użyć docker ps -a -qitp., Aby uniknąć manipulacji tekstem, tj. docker rm $(docker ps -a -q); docker rmi -f $(docker images -a -q)Powinieneś załatwić sprawę
Niklas B.
21

aby usunąć wszystkie nieużywane kontenery, woluminy, sieci i obrazy jednocześnie ( https://docs.docker.com/engine/reference/commandline/system_prune/#related-commands ):

docker system prune -a -f --volumes

jeśli to nie wystarczy, najpierw można usunąć działające kontenery:

docker rm -f $(docker ps -a -q)
docker system prune -a -f --volumes

zwiększenie / var / lib / docker lub użycie innej lokalizacji z większą ilością miejsca jest również dobrą alternatywą, aby pozbyć się tego błędu (zobacz Jak zmienić katalog instalacyjny obrazu dokera? )

Guillaume
źródło
docker system prunenie usuwa woluminów.
Bonifacio2
1
docker system prune -a -f --volumesusunie woluminy.
Jimson Kannanthara James
19

Docker na komputery Mac

Tak docker system prunei docker system prune --volumeszasugerowałem w innych odpowiedziach za każdym razem zwalniając trochę miejsca, ale ostatecznie za każdym razem, gdy coś uruchomiłem, pojawiał się błąd.

Tym, co faktycznie rozwiązało problem z rootem, było usunięcie Docker.rawpliku, którego Docker dla komputerów Mac używa do przechowywania, i zrestartowanie go.

Aby znaleźć ten plik, otwórz Docker na Maca i przejdź do *

Preferences > Resources > Advanced > Disk Image Location

* dotyczy to wersji 2.2.0.5, ale w starszych wersjach powinno być podobnie

W nowszych wersjach Docker na komputery Mac ** pokazuje rzeczywisty rozmiar tego pliku na dysku w interfejsie użytkownika, a także jego maksymalny przydzielony rozmiar. Prawdopodobnie zobaczysz, że jest ogromny. Na przykład na moim komputerze było to 41 GB !

** W starszych wersjach nie pokazuje rzeczywistego użycia dysku w interfejsie użytkownika, a MacOS Finder zawsze pokazuje rozmiar pliku jako maksymalny przydzielony rozmiar. Możesz sprawdzić rzeczywisty rozmiar na dysku, otwierając katalog w terminalu i uruchamiającdu -h Docker.raw

Usunąłem Docker.raw, ponownie uruchomiłem Docker na Maca, a plik został automatycznie utworzony ponownie i wrócił do 0 GB .

Wszystko działało tak jak wcześniej , choć oczywiście straciłem pamięć podręczną Dockera. Zgodnie z oczekiwaniami, po uruchomieniu kilku poleceń Dockera plik zaczął się ponownie wypełniać kilkoma GB rzeczy, ale nigdzie blisko 41 GB .


Aktualizacja

Kilka miesięcy później mój Docker.rawznów się napełnił do podobnego rozmiaru. Ta metoda zadziałała, ale musi się powtarzać co kilka miesięcy. Dla mnie to w porządku.

Uwaga na temat tego, dlaczego to działa - muszę założyć, że jest to błąd w Docker na Maca. Wygląda na to, że powinien docker system prune/ docker system prune --volumespowinien całkowicie wyczyścić zawartość tego pliku, ale wygląda na to, że plik gromadzi inne rzeczy, których nie można usunąć za pomocą tych poleceń. W każdym razie usunięcie go ręcznie rozwiązuje problem!

Davnicwil
źródło
15

Docker pozostawia wiszące wokół zdjęcia, które mogą zająć miejsce. Aby wyczyścić po Docker, uruchom następujące czynności:

docker image prune [-af if you want to force remove all images]

lub ze starszymi wersjami Dockera:

docker rm $(docker ps -q -f 'status=exited')
docker rmi $(docker images -q -f "dangling=true")

Spowoduje to usunięcie opuszczonych i wiszących obrazów, co, miejmy nadzieję, wyczyści przestrzeń urządzenia.

punkrockpolly
źródło
14
  1. Wyczyść zwisające obrazy docker rmi $(docker images -f "dangling=true" -q)
  2. Usuń niechciane woluminy
  3. Usuń nieużywane obrazy
  4. Usuń nieużywane pojemniki
josepainumkal
źródło
Dla mnie problemem było zbyt wiele zdjęć. Po ich oczyszczeniu doker działa ponownie.
Tran Triet,
9

możesz także użyć:

docker system prune

lub tylko dla tomów:

docker volume prune
aleksanoid
źródło
7

W moim przypadku instalacja Ubuntu-server 18.04.1 [z jakiegoś dziwnego powodu] stworzyła wolumin logiczny LVM o wielkości zaledwie 4 GB zamiast 750 GB. Dlatego podczas ciągnięcia obrazów pojawia się błąd „brak miejsca na urządzeniu”. Poprawka jest prosta:

lvextend -l 100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
Kostyantyn
źródło
.. zobacz mój opis krok po kroku dotyczący resize2fs w następującym wątku: stackoverflow.com/questions/32485723/…
Alex
7

Ten problem również napotkałem na maszynie RHEL. Nigdzie nie znalazłem żadnego rozwiązania apt na przepełnieniu stosu i społeczności dokerów-hubów. Jeśli napotykasz ten problem, nawet po wykonaniu poniższego polecenia:

przycinanie systemu dokerów - wszystkie

Rozwiązanie, które w końcu zadziałało:

  1. informacje o dokerze
    • Aby sprawdzić bieżący sterownik magazynu dokerów
    • Mój był: Storage Driver: devicemapper; Jeśli masz sterownik pamięci jako nakładkę2, nie musisz się martwić. Rozwiązanie będzie nadal działać dla Ciebie.
  2. df -h
    • Ma to na celu sprawdzenie dostępnych systemów plików na komputerze i ścieżki, w której są zamontowane. Dwie zamontowane ścieżki do notatki:
    • / dev / mapper / rootvg-var 7.6G 1.2G 6.1G 16% / var
    • / dev / mapper / rootvg-apps 60G 9.2G 48G 17% / apps
    • Uwaga - Domyślnie ścieżka pamięci dokera to / var / lib / docker. Ma dostępną przestrzeń ~ 6 GB, a zatem wszystkie problemy związane z przestrzenią. Zasadniczo muszę przenieść pamięć domyślną do innej pamięci, w której jest więcej dostępnego miejsca. Dla mnie jest to ścieżka do pliku „/ dev / mapper / rootvg-apps”, która jest zamontowana na / apps. Teraz zadaniem jest przeniesienie / var / lib / docker do czegoś takiego jak / apps / newdocker / docker.
  3. mkdir / apps / newdocker / docker
  4. chmod -R 777 / apps / newdocker / docker
  5. Zaktualizuj plik docker.serive w systemie Linux, który znajduje się w katalogu: / usr / lib / systemd / system
    • vi /usr/lib/systemd/system/docker.service
  6. jeśli urządzenie pamięci jest devicemapper, skomentuj istniejącą linię ExecStart i dodaj poniżej w [Service]:
    • ExecStart =
    • ExecStart = / usr / bin / dockerd -s devicemapper --storage-opt dm.fs = xfs --storage-opt dm.basesize = 40 GB -g / apps / newdocker / docker --exec-opt native.cgroupdriver = cgroupfs
  7. Lub jeśli urządzenie pamięci masowej jest nałożone2:
    • po prostu dodaj -g / apps / newdocker / docker do istniejącej instrukcji ExexStart.
    • Coś w stylu ExecStart = / usr / bin / dockerd -g / apps / newdocker / docker -H fd: // --containerd = / run / containerd / containerd.sock
  8. rm -rf / var / lib / docker (Usunie wszystkie istniejące dane dokera)
  9. doker systemctl stop
  10. ps aux | grep -i docker | grep -v grep
    • Jeśli powyższe polecenie nie wygenerowało danych wyjściowych, załaduj ponownie demona systemd, wykonując poniższe polecenie.
  11. systemctl daemon-reload
  12. systemctl start docker
  13. informacje o dokerze
    • Sprawdź dostępną przestrzeń danych: 62,15 GB po moutowaniu do dokera do nowego systemu plików.
  14. GOTOWY
Mayank Chaudhary
źródło
Szukałem w dokumentach, jak to osiągnąć! Dziękuję Panu. Czy możemy to oznaczyć jako jedną z odpowiedzi?
Vulegend
6

Wyczyść Docker za pomocą następującego polecenia:

docker images --no-trunc | grep '<none>' | awk '{ print $3 }' \
| xargs docker rmi
Ashok Waghmare
źródło
4

Twoje grupy mają cpusetwłączony kontroler. Ten kontroler jest najbardziej użyteczny w środowisku NUMA, gdzie pozwala dokładnie określić, który procesor / bank pamięci mogą być uruchamiane twoje zadania.

Domyślnie obowiązkowe cpuset.memsi cpuset.cpusnie są ustawione, co oznacza, że ​​„nie ma już miejsca” na twoje zadanie, stąd błąd.

Najłatwiejszym sposobem, aby to naprawić, jest włączenie cgroup.clone_children1 w głównej grupie cg. W twoim przypadku tak powinno być

echo 1 > /sys/fs/cgroup/docker/cgroup.clone_children

Zasadniczo poinstruuje system, aby automatycznie inicjował kontener cpuset.memsi cpuset.cpusod jego nadrzędnej grupy.

Yadutaf
źródło
1
To jest poprawna odpowiedź. Naprawdę po prostu uaktualnienie Dockera do czegokolwiek> = Docker 1.8 powinien go rozwiązać. Jest to związane z github.com/opencontainers/runc/issues/133 Z tego problemu można rozwiązać jeszcze jeden problemecho 0 > /sys/fs/cgroup/cpuset/system.slice/cpuset.mems
cpuguy83,
2

Jeśli używasz obrazu boot2docker za pośrednictwem Docker Toolkit, problem wynika z faktu, że na maszynie wirtualnej boot2docker zabrakło miejsca.

Po wykonaniu docker importlub dodaniu nowego obrazu obraz zostanie skopiowany do tego, /mnt/sda1który mógł być pełny.

Jednym ze sposobów sprawdzenia, ile miejsca masz na obrazie, jest ssh do vm i uruchomienie df -hi sprawdzenie pozostałej przestrzeni w / mnt / sda1

Komenda ssh to docker-machine ssh default

Gdy masz pewność, że rzeczywiście jest to problem z miejscem, możesz albo wyczyścić zgodnie z instrukcjami w niektórych odpowiedziach na to pytanie, albo możesz zmienić rozmiar samego obrazu boot2docker, zwiększając przestrzeń na /mnt/sda1

Możesz wykonać instrukcje tutaj, aby zmienić rozmiar obrazu https://gist.github.com/joost/a7cfa7b741d9d39c1307

Nerrve
źródło
2

Jeśli używasz Docker Desktop, możesz zwiększyć rozmiar obrazu dysku w Ustawieniach zaawansowanych , przechodząc do Preferencji Dockera .

Oto zrzut ekranu z systemu macOS:

Docker Desktop na macOS, zasoby, zaawansowane, rozmiar obrazu dysku

kenorb
źródło
1

Może to być spowodowane domyślnym miejscem do przechowywania ustawionym na 40 GB (domyślna ścieżka, / var / lib / docker)

możesz zmienić wolumin pamięci, aby wskazywał inną ścieżkę

  • edytuj plik -> / etc / sysconfig / docker-storage
  • aktualizuj poniżej linii (dodaj, jeśli nie istnieje)

DOCKER_STORAGE_OPTIONS = '- sterownik pamięci = nakładka --graph = CUSTOM_PATH'

  • Zrestartuj okno dokowane systemctl zatrzymaj okno dokowane systemctl demon-przeładuj systemctl start docker

jeśli uruchomisz informacje o oknie dokowanym (powinien pokazać sterownik pamięci jako nakładkę)

Ajit Ganiger
źródło
0

Wydaje się, że może to nastąpić na kilka sposobów. Problemem było to, że obraz dysku dokującego osiągnął maksymalny rozmiar (Docker Whale -> Preferencje -> Dysk, jeśli chcesz zobaczyć, jaki rozmiar jest w OSX).

Przekroczyłem limit i byłem gotowy do startu. Jestem pewien, że oczyszczenie nieużywanych obrazów również by działało.

SnellyBigoda
źródło
0

Uruchamiam poniższe polecenia.

Nie ma potrzeby późniejszej odbudowy zdjęć.

docker rm $(docker ps -qf 'status=exited')
docker rmi $(docker images -qf "dangling=true")
docker volume rm $(docker volume ls -qf dangling=true)

Usuwają one wychodzące / wiszące pojemniki i wiszące woluminy.

M3RS
źródło
0

Dla mnie docker system prunezałatwił sprawę. Mam Mac OS.

Bildad N. Urandu
źródło
Tak naprawdę działało to również na moim, gdy próbowałem oczyścić miejsce zużyte w Mac OS. użycie polecenia docker volume lsnic nie zwracało, więc wydawało się, że pamięć była w większości używana przez pamięci podręczne i wiszące obrazy.
Tuhin
-3
$ docker rm $(docker ps -aq)

To zadziałało dla mnie

docker system prune 

wydaje się być lepszą opcją w najnowszej wersji

htnawsaj
źródło