I set up an Ubuntu Server virtual machine in Proxmox to run Docker through Portainer. The virtual disk is about 150 GB, but the root logical volume mounted at / is only 15 GB. Docker's /var/lib/docker is reporting 95% usage: 14 GB used with roughly 837 MB available.
Docker reports six active images using about 8.6 GB, six containers using only a few MB, two volumes using about 824 MB, and no build cache. The container JSON logs are also relatively small, ranging from a few KB to about 4 MB. I have already run Docker cleanup commands, but the filesystem is still nearly full.
What commands should I use to identify exactly which directories or files under /var/lib/docker or /var/lib/containerd are consuming the space? Is 14 GB reasonable for this setup? If the Docker data is normal, how can I expand the existing root logical volume to use more of the VM's 150 GB disk?
3 Answers
Another valid approach is to place Docker's data root on a separate, larger filesystem. Stop Docker and its socket, copy the existing data while preserving ownership and attributes, set `"data-root": "/data/docker"` in `/etc/docker/daemon.json`, then start Docker and confirm it is using the new location. For example:
`sudo systemctl stop docker.socket docker`
`sudo rsync -aHAX --numeric-ids /var/lib/docker/ /data/docker/`
After editing the daemon configuration, start Docker and check `docker info` for the Docker Root Dir. Do not delete the old directory until the new location has been verified. Regardless of where the data lives, configure log rotation and make sure databases or other persistent application data use Docker volumes.
First determine whether Docker is actually the main consumer. Running `sudo ncdu -x /var/lib/docker` is convenient, or use `sudo du -xhd1 /var/lib/docker | sort -h` and repeat that command inside the largest directory. Also check the whole root filesystem with `sudo du -xhd1 / | sort -h`.
The usual large directory is `overlay2`, often because an application is writing data inside its container filesystem instead of to a declared Docker volume. If you find large application data there, move it to a volume rather than repeatedly pruning images. It is also worth checking for deleted-but-still-open files with `sudo lsof +L1`, since `du` will not show space held by a process after the file was deleted.
Your Docker accounting does not include every possible use of the filesystem, and the VM's 150 GB virtual disk has not been allocated entirely to `/`. From the partition layout, the disk is about 152 GB, but `/dev/sda3` is only 30 GB and the root logical volume is only 15 GB. That explains why `/` fills even though the virtual disk has plenty of unused capacity.
If `/dev/sda3` really extends to the end of the disk and there are no important partitions after it, the general expansion sequence is:
`sudo growpart /dev/sda 3`
`sudo pvresize /dev/sda3`
`sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv`
For an ext4 filesystem, finish with:
`sudo resize2fs /dev/ubuntu-vg/ubuntu-lv`
You can usually use `lvextend -r` instead of the last two commands because it extends the filesystem automatically. Verify the filesystem type with `findmnt -no FSTYPE /` first; XFS uses `xfs_growfs /` instead of `resize2fs`. Take a VM backup or snapshot and verify the layout with `lsblk` and `sudo pvs; sudo vgs; sudo lvs` before changing partitions.
That matches my layout: the disk is about 152 GB, `/dev/sda3` is 30 GB, and the root LV is 15 GB. I was confusing the virtual disk size with the size actually assigned to `/`. I’ll verify the partition boundaries and filesystem type before expanding it.