# SD card completely full **URL:** \ **Category:** Anthias\ **Created:** [October 21, 2026, 8:00am UTC](https://forums.screenly.io/t/sd-card-completely-full/6778 "2026-10-21T08:00:34Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Martin](https://avatars.discourse-cdn.com/v4/letter/m/73ab20/32.png) [@Martin](https://forums.screenly.io/u/Martin)\ **Post date:** [October 21, 2026, 8:00am UTC](https://forums.screenly.io/t/sd-card-completely-full/6778/1 "2026-10-21T08:00:34Z")
I’m using Anthias successfully - but recently I saw that the sd card is completely full - no more space for uploading additional assets. I’m searching for a solution which I can perform through remote ssh access (pi connect). Here’s some information from the disk - biggest files/dirs: pi@tv02:/var/lib $ sudo du -hxd 1 | sort -h 4.0K ./alsa 4.0K ./dbus 4.0K ./dhcpcd 4.0K ./git 4.0K ./man-db 4.0K ./misc 4.0K ./private 4.0K ./python 4.0K ./udisks2 4.0K ./usb\_modeswitch 4.0K ./wtmpdb 8.0K ./bluetooth 8.0K ./logrotate 8.0K ./plymouth 8.0K ./sudo 8.0K ./vim 12K ./raspberrypi 12K ./sgml-base 16K ./xml-core 20K ./NetworkManager 28K ./pam 32K ./ucf 236K ./cloud 572K ./systemd 2.9M ./docker 32M ./dpkg 147M ./apt 26G ./containerd 27G . so it seems the container is completely full (which was not the case when I installed Anthias from scratch via`bash <(curl -sL https://install-anthias.srly.io)` Can you please advise how to resolve? When trying to update it fails because of disk full… thanks, Martin ---
**Author:** ![vpetersson-bot](https://yyz1.discourse-cdn.com/flex029/user_avatar/forums.screenly.io/vpetersson-bot/32/803_2.png) [@vpetersson-bot](https://forums.screenly.io/u/vpetersson-bot)\ **Post date:** [October 21, 2026, 10:52am UTC](https://forums.screenly.io/t/sd-card-completely-full/6778/2 "2026-10-21T10:52:16Z")
Hi Martin, The 26 GB in `/var/lib/containerd` is Docker’s image store, and it’s holding a complete copy of the Anthias stack for every release you’ve ever upgraded through. Each generation is roughly 3 GB (viewer + server + redis), so 26 GB is about eight of them. Why nothing cleaned them up: each Anthias release pins its own immutable image tag, so when you upgrade, the previous release’s images stay _tagged_ and valid rather than becoming dangling. `docker system prune -f` — which the installer already runs at the end of every upgrade — only reclaims dangling images, so it reclaims exactly 0 bytes of these. I measured this on a Pi 3 here before replying: seeding one superseded release grew `/var/lib/containerd` from 3.0 GB to 4.4 GB, and `docker image prune -f` then reported `Total reclaimed space: 0B` with both images still listed. (Incidentally, `/var/lib/docker` being tiny while `/var/lib/containerd` is huge is expected on Docker 25 and later, which keeps images under containerd. That’s why your `du` looks different from the older `overlay2` threads on here.) This is fixed as of **v2026.09.0** — upgrades now purge superseded images automatically. But you’ll need to free the space first, because the upgrade’s `docker pull` is exactly what’s failing on a full card. Over SSH, safe to run with Anthias live — nothing is stopped, and `docker rmi` needs no free space, so it works at 100% full: ```bash curl -fsSL https://raw.githubusercontent.com/Screenly/Anthias/master/bin/purge_stale_images.sh | bash ``` If sudo asks for a password, run `sudo -v` first — the script is piped into bash and can’t prompt. It only removes images from the Anthias repositories that no container references, so anything of your own running alongside Anthias is left alone. It prints one line per image it reclaims, and you should get most of the 26 GB back. Then re-run the installer to land on v2026.10.0, and it’ll stay tidy from there. If it reclaims much less than you’d expect, something other than stale images is filling the card — most likely a runaway file inside one container layer. This will show it: ```bash sudo find /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots \ -xdev -type f -size +100M -printf '%s %p\n' | sort -rn | head ``` On a healthy device the only hits are legitimate libraries (`libQt6WebEngineCore.so`, `libLLVM.so`). A pile of `core.` files or one giant log would mean a different bug — post the output here and we’ll take it from there. ---
**Author:** ![Martin](https://avatars.discourse-cdn.com/v4/letter/m/73ab20/32.png) [@Martin](https://forums.screenly.io/u/Martin)\ **Post date:** [October 21, 2026, 4:21pm UTC](https://forums.screenly.io/t/sd-card-completely-full/6778/3 "2026-10-21T16:21:05Z")
Hi! Thanks for your reply! I’ve tried to run curl -fsSL [https://raw.githubusercontent.com/Screenly/Anthias/master/bin/purge](https://raw.githubusercontent.com/Screenly/Anthias/master/bin/purge) but it returned curl: (22) The requested URL returned error: 404 Can you please help again, Martin pi@tv02:/var/lib $ sudo find /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots -xdev -type f -size +100M -printf ‘%s %p\n’ | sort -rn | head 178324312 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/14/fs/usr/lib/aarch64-linux-gnu/libQt6WebEngineCore.so.6.8.2 123242120 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/6/fs/usr/lib/aarch64-linux-gnu/libLLVM.so.19.1 123242120 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/5/fs/usr/lib/aarch64-linux-gnu/libLLVM.so.19.1 ---
**Author:** ![vpetersson-bot](https://yyz1.discourse-cdn.com/flex029/user_avatar/forums.screenly.io/vpetersson-bot/32/803_2.png) [@vpetersson-bot](https://forums.screenly.io/u/vpetersson-bot)\ **Post date:** [October 22, 2026, 7:09am UTC](https://forums.screenly.io/t/sd-card-completely-full/6778/4 "2026-10-22T07:09:27Z")
Sorry about that, the link in my last reply got cut short. The file name is longer than it looked. Here is the whole thing: ```auto https://raw.githubusercontent.com/Screenly/Anthias/master/bin/purge_stale_images.sh ``` It is easier to do this in two steps. If the download fails you get a clear message instead of an error being handed straight to the shell, and it also lets the password prompt work properly: ```auto curl -fsSL -o /tmp/purge_stale_images.sh \ https://raw.githubusercontent.com/Screenly/Anthias/master/bin/purge_stale_images.sh bash /tmp/purge_stale_images.sh ``` It prints one line for each old copy it clears out, and nothing at all if there is nothing left to clear. Thanks for running the other command too. It tells us exactly what we needed to know. The three large files it found are all normal parts of Anthias, so nothing has gone wrong on your device: - the web browser engine, about 170 MB - a graphics library, about 118 MB, listed twice There is no runaway file or crash log eating your card. It really is just old copies of Anthias left behind by past upgrades, which is what the script above clears out. Once there is room again, run the installer to update to [2026.10.0](https://forums.screenly.io/t/2026-10-0-is-now-live/6779). From 2026.09.0 onwards Anthias clears out old copies by itself, so your card will not fill up like this again.