Your Nextcloud container just filled up its root disk again. Or maybe you're two weeks into running a Pi-hole or a small game server, and you've noticed every bit of data is crammed inside the same 8 GB volume Proxmox created the day you spun up the container. You could grow that root disk, and Proxmox will let you, but that's not really how LXC containers are meant to work day to day. There's a cleaner tool built for exactly this: mount points. Attach one, point it at wherever your data actually needs to live, and you can rebuild or reinstall the container itself without touching the data sitting on it.
This guide walks through adding extra storage to an existing container using both the Proxmox web interface and the pct command line tool. It applies to Proxmox VE 8.x and 9.x — the mount point system hasn't changed in any meaningful way between the two.
What You Will Learn
- What an LXC mount point actually is, and how it's different from a virtual machine's virtual disk
- How to add a new storage-backed mount point through the GUI
- How to do the same thing with a single
pct setcommand - How to bind-mount an existing host folder into a container, and why that's riskier with unprivileged containers
- How to resize a mount point later, and what to check when a container won't start after you've added one
What Is This Feature?
An LXC container is a lightweight way to run an isolated Linux environment on the same kernel as your Proxmox host, rather than a full virtual machine with its own emulated hardware. Because there's no separate kernel or virtual BIOS involved, containers start in a couple of seconds and use a fraction of the RAM and CPU a comparable VM would need. The tradeoff is that a container can only run the same kernel as the host, so it has to be Linux, and it shares more of the host's internals than a VM does.
Every container has one required piece of storage called rootfs — that's the disk holding the operating system itself, sized when you first create the container. Beyond that, you can attach additional volumes numbered mp0 through mp255. These are what people mean when they say "mount points," and they show up in the container's configuration file as lines like mp0: local-lvm:vm-105-disk-1,mp=/data,size=20G.
There are really three flavors of mount point, and it's worth knowing the difference before you pick one:
- Storage-backed volumes — Proxmox carves out a chunk of one of your configured storages (local-lvm, a ZFS pool, a directory, whatever you've got) and presents it to the container as its own volume. This is the one you'll use most often.
- Bind mounts — an existing directory on the Proxmox host filesystem, exposed straight into the container. Nothing new gets created; the container just gets a window into a folder that already exists on the host.
- Device mounts — a raw block device (like
/dev/sdb1) passed through directly. Rare for beginners, and not something this guide covers in depth.
One more term you'll bump into here: unprivileged container. By default, new containers in Proxmox are unprivileged, meaning the root user inside the container isn't actually root on the host — it's remapped to a high, unprivileged UID range (typically starting around 100000). That's a real security boundary, and it's the reason bind mounts sometimes show up with strange ownership. We've got a full breakdown of privileged versus unprivileged containers in another guide; here, just know that it affects how bind-mounted folders behave.
Why Would You Use It?
The most common reason is separating your data from your operating system. If your Pi-hole container's rootfs gets corrupted, or you just want to reinstall the OS inside it fresh, a mount point holding your actual configuration and logs survives that rebuild untouched. Delete the container, create a new one, reattach the same storage volume, and your data is right where you left it.
It's also how you get around resizing headaches. Growing a root filesystem inside a container after the fact works, but it involves the container's internal filesystem tooling and can be fiddly depending on what's inside. Adding a second, dedicated mount point for a media library or a database is usually simpler than trying to make the root disk bigger every few months.
Bind mounts solve a different problem: sharing one host folder across several containers. Say you keep all your downloaded media in /mnt/media on the Proxmox host. You can bind-mount that same folder into a Jellyfin container, a Sonarr container, and a Radarr container simultaneously, and they'll all see the exact same files without you copying anything around.
Prerequisites
- A Proxmox VE 8.x or 9.x host with at least one existing LXC container
- Root or sudo access to the Proxmox shell (or an account with the VM.Config.Disk permission for the GUI method)
- Some free space on the storage you plan to use — check Datacenter → Storage in the GUI if you're not sure what's available
- The container's ID number, which you can find in the left-hand resource tree (it's the number next to the container's name)
Step-by-Step Tutorial
Adding a Storage-Backed Mount Point Through the GUI
This is the easiest route if you're not comfortable on the command line yet, and honestly it's what most people end up using anyway.
- Click the container in the left-hand tree, then open the Resources tab.
- Click Add and choose Mount Point from the dropdown.
- Pick a Storage target — this can be different from where the container's rootfs lives.
- Set a Disk size (GiB). Unlike rootfs, you can grow this later, so don't overthink the exact number.
- In the Path field, type where you want it to appear inside the container, for example
/data. - Leave Backup checked if you want
vzdumpto include this volume in scheduled backups — for most data volumes, you'll want this on. - Click Add, then restart the container from the Summary tab so the new mount is actually attached.
Log into the container's console and run df -h. You should see the new volume mounted at the path you chose, already formatted and ready to write to.
Doing the Same Thing With pct
If you'd rather skip the GUI entirely, one command does the same job:
pct set 105 -mp0 local-lvm:20,mp=/dataReplace 105 with your container's ID. This tells Proxmox to carve out a new 20 GB volume from the local-lvm storage, attach it as mp0, and mount it at /data inside the container. If mp0 is already taken, use mp1, mp2, and so on — you get up to 256 slots, though nobody's realistically using more than a handful.
Confirm it landed correctly with:
pct config 105You should see a new mp0: line in the output. Then restart the container with pct reboot 105 and check df -h inside it, same as the GUI method.
Bind-Mounting an Existing Host Folder
If you want to share a folder that already exists on the Proxmox host — rather than creating a brand new volume — the syntax looks almost identical, you just point at a path instead of a storage name:
pct set 105 -mp0 /mnt/media,mp=/mediaThis one comes with a catch. On an unprivileged container, the UID remapping mentioned earlier means files owned by your regular host user (say, UID 1000) can show up owned by some huge, meaningless number inside the container, or vice versa. If you're bind-mounting a folder you already have permissions set up on, expect to spend a few minutes fixing ownership with chown inside the container, or adjusting the host folder's permissions to something wide enough (like chmod 775) that it doesn't matter which UID owns it.
If that sounds like more trouble than it's worth, it often is for a first attempt — a lot of people are better off starting with a storage-backed mount point and only reaching for bind mounts once they understand why the permission shift happens.
Resizing a Mount Point Later
Storage-backed mount points can grow without recreating anything:
pct resize 105 mp0 +10GThat adds 10 GB to the existing volume. The container needs to be running for the filesystem inside to actually pick up the new space — Proxmox handles the underlying volume resize, but the container's own filesystem needs a moment (usually automatic on next mount, sometimes a quick resize2fs inside the guest for ext4) to recognize it's bigger. Bind mounts and device mounts can't be resized this way, since they're not volumes Proxmox is managing — you'd resize the underlying host filesystem instead.
Commands Explained
| Command | What it does |
|---|---|
pct set <id> -mp0 storage:size,mp=/path | Creates a new storage-backed mount point and attaches it to the container |
pct set <id> -mp0 /host/path,mp=/path | Bind-mounts an existing host directory into the container |
pct config <id> | Prints the container's full configuration, including every mount point currently attached |
pct resize <id> mp0 +10G | Grows an existing storage-backed mount point by the given amount |
pct reboot <id> | Restarts the container so newly added mount points are actually mounted |
df -h | Run inside the container to confirm a mount point is present and see how much space is free |
Common Errors
A handful of messages show up often enough that they're worth knowing on sight.
- "mp0: could not activate storage 'xyz', not enough space" — the storage you picked doesn't have room for the size you requested. Check Datacenter → Storage for actual free space before retrying with a smaller number.
- "directory '/data' is not empty" when using a bind mount — Proxmox is warning you that the mount point path inside the container already has files in it, which will be hidden (not deleted, just hidden) once the mount is attached. Pick an empty directory or accept that the existing contents will be temporarily inaccessible.
- Permission denied errors inside the container after a bind mount — this is the UID remapping issue from earlier. It's not a bug, it's the unprivileged container security boundary doing its job.
- Container fails to start after adding a mount point — usually means the storage backing it went offline, or you referenced a storage type that doesn't support the content type needed for container volumes.
Troubleshooting
Start with pct config <id> and read the mount point line carefully. Most problems trace back to a typo in the storage name or path, and this output shows you exactly what Proxmox thinks it's attaching.
If the container won't boot at all after you added a mount point, check whether the backing storage is actually online under Datacenter → Storage — a greyed-out storage entry means the container can't reach its volume, and it'll fail to start rather than start without it.
For bind mount ownership headaches, run id inside the container to see what UID your processes are actually running as, then compare it against the file ownership on the host with ls -la on the bind-mounted path. Nine times out of ten the fix is either a chown on one side or the other, or widening permissions with chmod if the data isn't sensitive.
Still stuck? The container's syslog is usually the fastest place to look — run journalctl -xe on the Proxmox host right after a failed start, and look for lines mentioning the container's ID.
Best Practices
- Keep your rootfs small and let mount points hold the data that actually grows — logs, media, databases, uploads.
- Leave the Backup checkbox on for any mount point holding data you'd actually miss. It's off by default for some volume types, and that's an easy thing to forget until you need a restore that isn't there.
- Prefer storage-backed volumes over bind mounts unless you specifically need to share one folder across multiple containers. They're easier to back up, resize, and reason about.
- If you do use bind mounts on unprivileged containers, plan for the UID shift up front rather than debugging it after the fact.
- Name your mount paths something obvious —
/dataor/media, not/mnt/mp0— future-you will thank present-you during the next 2 a.m. troubleshooting session.
Frequently Asked Questions
Can I add a mount point without restarting the container?
The configuration is written immediately, but the actual mount usually only appears after a restart. Save yourself the confusion and just reboot the container right after adding one.
What's the difference between a mount point and just resizing rootfs?
Resizing rootfs grows the same disk your OS lives on — everything stays mixed together. A mount point is a separate volume you can back up, resize, or move independently of the operating system.
Do mount points work the same way on privileged containers?
Storage-backed volumes behave identically either way. Bind mounts are simpler on privileged containers since there's no UID remapping to fight with, though that comes with the security tradeoffs covered in our privileged-versus-unprivileged guide.
Can I move a mount point to different storage later?
Yes — right-click the mount point in the Resources tab and choose Volume Action → Move Storage, or use pct move-volume from the shell.
Will deleting the container delete my mount point data too?
By default, yes, if the mount point is a storage-backed volume owned by that container. Detach it first (there's a "Do not delete now" style option in the removal dialog) if you want the data to survive.
Conclusion
Mount points are one of those Proxmox features that seem like a small detail until the first time you need to rebuild a container and realize your data was never at risk in the first place. Once you've added one — through the GUI or with a single pct set command — the habit sticks, and you'll probably find yourself reaching for a dedicated mount point by default any time a new container is going to hold anything worth keeping.
Start small: pick one container that's currently storing its data on rootfs, add a mount point, and move the data over. It's a ten-minute job the first time and a two-minute one every time after that.