How to Resize an LXC Container's Root Disk in Proxmox VE (Fix a Full Disk with pct resize)

Introduction

You're running an app inside an LXC container on Proxmox VE, everything's fine for weeks, and then a package install or a bloated log file suddenly hands you "No space left on device." The first reaction is usually panic — did something break? Nothing broke. Your container just ran out of the disk space it was given when you created it, and unlike a lot of things Proxmox handles for you automatically, growing that disk back out is a step you have to do yourself.

The fix itself takes about two minutes once you know which command to run, or which button to click if you'd rather stay in the web interface. What actually trips people up isn't the resize command — it's the handful of assumptions that catch beginners off guard. Resizing only ever goes one direction. A couple of storage types flatly refuse to do it live. And growing the disk in Proxmox doesn't automatically mean the filesystem sitting inside the container knows the extra space is there.

This guide walks through all of that using one real container as the example throughout, so none of it stays abstract.

What You Will Learn

• What a container's root disk actually is, and how it differs from a virtual machine's disk
• How to check how full your container's disk really is before touching anything
• How to grow the root disk from the Proxmox web interface
• How to do the same thing from the command line with pct resize
• Why the extra space sometimes doesn't show up inside the container right away
• Which storage backends support live resizing, and which ones don't

What Is This Feature?

An LXC container is Proxmox's lightweight alternative to a full virtual machine. Instead of emulating hardware and booting its own kernel, a container shares the Proxmox host's kernel and just gets an isolated filesystem, process list, and network stack. That's why containers start in a second or two and use a fraction of the RAM a comparable VM needs — you're not paying the overhead of a second operating system underneath it.

Every container needs somewhere to keep its operating system files, and that's the root disk, labeled rootfs in the container's configuration. Where that rootfs actually lives depends on the storage you picked when you created the container:

Whatever the backend, the rootfs has a fixed size set the moment you create the container — 8 GB by default for a lot of the official templates. Resizing means telling Proxmox to make that underlying volume bigger, then making sure the filesystem sitting on top of it, almost always ext4, actually uses the new space instead of quietly ignoring it.

This is a different feature from adding a second mount point to a container, which creates an entirely separate, independent volume you can back up and move on its own. Resizing grows the disk the operating system is already living on. If you've read our guide on adding extra storage to an LXC container, you may remember it touches on this distinction briefly — this guide goes deeper on the rootfs side specifically.

Why Would You Use It?

Realistically, you'll end up here for one of a few reasons:

• You picked a small default size when creating the container and didn't think about it again until something filled it up
• You're running software that logs heavily — Docker images inside the container, application logs, a database that grows over time
• You moved a workload into the container that needs more room than whatever you originally planned for

The alternative — destroying the container and recreating it with a bigger disk from scratch — is a lot more work, and it's a good way to lose configuration you'd rather keep. Growing the existing disk in place is almost always the better option, and for thin-provisioned storage like ZFS or LVM-thin, it costs you nothing until the space is actually used.

Prerequisites

Before you start, you'll need:

• An existing LXC container in Proxmox VE — this guide assumes you already have one; if you don't, create one first and come back
• Root access to the Proxmox host, either through the web interface or SSH
• Free space available on the underlying storage the container's disk lives on. Resizing doesn't create space out of nowhere — it just lets the container use more of what's already free on that storage
• About five minutes

You don't need to stop the container for most storage types. We'll flag the couple of cases where a quick restart makes life easier.

Step-by-Step Tutorial

Step 1: Confirm the Container Is Actually the Problem

Before resizing anything, check what's actually happening. Run this from the Proxmox host's shell:

pct exec 105 -- df -h /

Replace 105 with your container's ID — you'll find it in the left-hand tree in the web interface, right next to the container's name. This command drops into the container just long enough to run df -h, which lists disk usage for its mounted filesystems in human-readable units. If the Use% column for / is sitting at 100%, or close enough that it's about to be, you've confirmed the diagnosis.

Worth a quick sanity check here too: sometimes what looks like "the disk is full" is actually one runaway log file or a leftover apt cache eating space that could just be cleaned up instead of resized away. Running pct exec 105 -- du -sh /var/log or checking /var/cache takes thirty seconds and occasionally saves you the whole exercise.

Step 2: Resize From the Web Interface

This is the more approachable route if you'd rather avoid the command line entirely.

1. Click your container in the left-hand tree.
2. Open the Resources tab.
3. Click the row labeled Root Disk, then click Resize disk near the top of the panel.
4. In the dialog, enter how much extra space to add — for example, 5 for 5 GB more. This value is always added on top of the current size, never a new total.
5. Click Resize.

Proxmox applies the change immediately in most cases, with no need to stop the container first.

Step 3: Resize From the Command Line

If you're more comfortable in a terminal, or you're scripting this as part of a larger maintenance job, use pct resize instead:

pct resize 105 rootfs +5G

The plus sign matters. It tells Proxmox to add 5 GB on top of whatever the disk's current size already is. Drop the plus sign and type just 5G, and Proxmox treats that as an absolute target size instead — which only works if 5G happens to be bigger than the disk's current size. Get this backwards on a disk that's already 8 GB, and the command fails outright rather than shrinking anything, since pct resize refuses to make a disk smaller under any circumstances.

You can resize any of the container's disks this way, not just rootfs. A mount point named mp0 gets the same treatment: pct resize 105 mp0 +10G.

Step 4: Confirm the Container Actually Sees the New Space

Run the same check again:

pct exec 105 -- df -h /

Most of the time, ext4 — the default filesystem in nearly every official LXC template — picks up the extra space live, with no reboot needed. Occasionally it doesn't show up until the container restarts. If a restart is convenient, it's the fastest way to rule out any doubt:

pct reboot 105

Check df -h one more time afterward. At this point the new size should be reflected correctly.

Commands Explained

Common Errors

• "unable to resize disk (resizing not supported for ...)" — shows up when the underlying storage doesn't support online resize for that volume type. Certain NFS-backed configurations and some legacy image formats fall into this category. Check what storage the container's rootfs actually sits on, under Datacenter, then Storage, before assuming the command itself is broken.
• Disk shows the new size in pct config, but df -h inside the container still reports the old number — the volume grew, but the filesystem inside hasn't caught up yet. A pct reboot almost always clears this.
• "disk shrinking is not supported" — this happens when you accidentally type an absolute size smaller than or equal to the current one, instead of using a plus sign. Revisit Step 3 above.
• Resize command runs, but the container won't start afterward — rare, but worth double-checking pct config for a stray typo if you were editing the config file directly instead of using pct resize.
• "volume ... is locked (snapshot)" — the container has an existing snapshot referencing that disk, and the storage backend won't let you resize it until the snapshot is gone.

Troubleshooting

If the resize command runs without an error but nothing seems to actually change, work through this in order:

1. Run pct config 105 and confirm the rootfs line shows the new, larger size. If it doesn't, the command didn't apply — check for a typo in the container ID or a missing plus sign.
2. If the config shows the new size but df -h inside the container disagrees, restart it with pct reboot 105.
3. If the container has any snapshots, some storage backends — LVM-thin especially — will refuse to resize the disk until those snapshots are removed. Check under the container's Snapshots tab.
4. On ZFS, if the resize still isn't reflected inside the container after a reboot, run zfs list on the host to confirm the underlying dataset itself actually grew.
5. Confirm the storage you're resizing onto actually has the free space you think it does. Datacenter, then Storage, then the relevant entry, shows you real numbers rather than assumptions.
6. If none of the above explains it, check the Proxmox task log (the little list icon at the bottom of the screen) for the resize task's full output — it usually names the exact storage or volume that rejected the operation.

Nearly every stuck resize traces back to one of two things: a storage backend that doesn't support the operation on that particular volume, or a filesystem inside the container that just needed a reboot to notice the change.

Best Practices

• Size containers a bit larger than you think you'll need up front. On thin-provisioned storage like ZFS or LVM-thin, an extra 2-3 GB costs you nothing until it's actually used, and it saves you this entire exercise down the road.
• Check disk usage on a schedule instead of waiting for an app to crash and tell you about it. A quick pct exec <vmid> -- df -h across your containers once a week catches this before it becomes an outage.
• Remember that resize only grows disks, never shrinks them. If you oversize a container by mistake, your real options are recreating it or accepting the extra allocated space.
• Take a snapshot before resizing a container that's holding data you actually care about. It's not that resizing is especially risky — it's that a snapshot is cheap insurance for a two-minute operation.
• If you're consistently running out of rootfs space, ask whether the data belongs on a separate mount point instead. Splitting application data onto its own volume makes it easier to back up and move independently of the operating system disk, and it stops one runaway log directory from taking down the whole container.

Frequently Asked Questions

Can I shrink a container's disk back down after growing it?

pct resize only grows disks. Shrinking one back down isn't supported — your only option is creating a new, smaller container and migrating data into it.

Do I need to stop the container before resizing?

Usually not. Most storage backends support resizing a running container's disk. If the filesystem doesn't pick up the change immediately, a reboot afterward resolves it.

Will resizing affect my existing backups or snapshots?

Existing backups aren't affected. However, if the container currently has a snapshot, some storage types will block the resize entirely until you remove that snapshot first.

What's the actual difference between resizing rootfs and adding a mount point?

Resizing rootfs grows the same disk the container's operating system already lives on. A mount point is a separate, independent volume — better suited to application data you want to back up or move without touching the OS disk at all.

Why did my resize fail with a storage-related error?

Not every storage backend supports online resize for every volume format. Check which storage the container's disk actually sits on, under Datacenter, then Storage, and confirm it supports resizing before troubleshooting further.

Does the container need to be a specific type — privileged or unprivileged — for this to work?

No. Resizing behaves the same on both privileged and unprivileged containers. The privileged-versus-unprivileged distinction affects permissions and isolation, not disk resizing.

Conclusion

Running out of space inside an LXC container looks alarming the first time it happens and takes about ninety seconds to fix once you've done it before. Whether you reach for the web interface or pct resize from the command line, the mechanics stay the same: grow the underlying disk, then make sure the filesystem inside actually notices.

The one habit worth keeping afterward is checking disk usage occasionally instead of waiting for an app to crash and tell you about it. A resized container is a two-minute fix. A container that goes down mid-task because nobody was watching disk usage is a much worse afternoon.