You installed Proxmox VE, you've got a second drive sitting in the box doing nothing, and you want Proxmox to actually use it. Maybe you tried clicking around in the storage settings and got confused by ZFS, LVM-Thin, and a handful of other options you've never heard of. Here's the good news: you don't need any of that just to store ISOs, backups, or VM disks on a spare drive. You need directory storage, and it's the simplest storage type Proxmox offers.
This guide walks through adding a directory-based storage in Proxmox VE from a completely blank second disk, all the way to a working, tested storage entry you can actually use. No ZFS pools, no RAID controllers, no cluster filesystems — just a formatted disk, a mount point, and a few commands.
What You Will Learn
- What directory storage actually is and how it differs from ZFS, LVM, and NFS storage in Proxmox
- How to prepare and permanently mount a second disk on your Proxmox host
- How to add that mounted disk as storage, both through the web interface and the command line
- Which content types to enable and why it matters
- How to fix the errors that trip up almost everyone the first time they do this
What Is This Feature?
Directory storage in Proxmox VE is exactly what it sounds like: a regular folder on a regular filesystem that Proxmox has been told to treat as a storage location. Under the hood it's usually ext4 or XFS — nothing exotic. Proxmox creates a predictable folder structure inside it (a dump folder for backups, a template/iso folder for ISO images, an images folder for VM disks, and so on) and then lets you pick that storage from the GUI whenever you upload an ISO, run a backup, or create a new VM disk.
Compare that to ZFS, which is a combined filesystem and volume manager that adds checksumming, snapshots, and optional redundancy across multiple disks. Or LVM-Thin, which carves a single disk into thin-provisioned logical volumes for fast VM disk allocation. Directory storage skips all of that. It's just a path on disk. That simplicity is the whole appeal — and also its main limitation, which we'll get to.
Why Would You Use It?
If you've got exactly one spare disk and no interest in running ZFS on it, directory storage is the fastest path to using that disk. It's also the right call when you already have a disk formatted and mounted for some other reason — say, an old data drive you're repurposing — and you just want Proxmox to see it.
A lot of homelab users also use directory storage specifically for backups. Keeping backups on a separate physical disk from your VM disks means a failed OS drive doesn't take your backups down with it. You don't need ZFS's snapshot features for that use case; you just need somewhere else to write files.
Where directory storage falls short: it can't do storage-level snapshots (raw disk images, at least — more on that below), it isn't clustered or shared by default, and it won't give you the self-healing checksums ZFS provides. If you're building a "real" production cluster with live migration between nodes, you'll eventually want shared storage like NFS, Ceph, or a SAN. For a single-node homelab or a small business box, directory storage is often all you need.
Prerequisites
- A working Proxmox VE installation — this guide was written against Proxmox VE 8.x and 9.x, and the steps are the same on both
- Root access, either via the web GUI (Datacenter view) or SSH to the host's shell
- A spare disk or partition. It can be completely blank — we'll format it — or already formatted with data you want to keep
- About fifteen minutes, most of which is waiting for
mkfsto finish on a large disk
One thing you don't need: a second physical machine. Everything here happens on the Proxmox host itself.
Step-by-Step Tutorial
Step 1: Find and identify your disk
Open a shell on your Proxmox host — either through the Shell button on the node in the web GUI, or over SSH — and run:
lsblkYou'll see a list of block devices. Your boot disk is probably sda with partitions already carved out for the Proxmox install. Look for the unused disk — it'll show up as a device with no partitions and no mount point, something like sdb with a size matching the drive you installed. Double-check the size against what you know the drive to be. Grabbing the wrong disk here is the single most common mistake in this whole process, and it's not reversible once you format it.
Step 2: Partition and format the disk
If the disk is genuinely blank, the quickest path is a single partition covering the whole disk, formatted as ext4:
parted /dev/sdb --script mklabel gpt mkpart primary ext4 0% 100%
mkfs.ext4 /dev/sdb1Replace /dev/sdb with whatever device lsblk showed you. The parted command creates a GPT partition table with one partition spanning the entire disk, and mkfs.ext4 formats that partition. On a 4 TB spinning disk this can take a couple of minutes; on an SSD it's usually done in seconds.
ext4 is the safe default here. XFS works just as well if you prefer it — swap mkfs.ext4 for mkfs.xfs and nothing else in this guide changes.
Step 3: Mount the disk permanently
Create a mount point and get the partition's UUID:
mkdir /mnt/extra-storage
blkid /dev/sdb1blkid prints a UUID like UUID="a1b2c3d4-e5f6-7890-abcd-1234567890ab". Use that value — not the device name — when you edit /etc/fstab, because device names like /dev/sdb can shift around after a reboot if you add or remove drives. UUIDs don't.
Open /etc/fstab in a text editor and add a line at the bottom:
UUID=a1b2c3d4-e5f6-7890-abcd-1234567890ab /mnt/extra-storage ext4 defaults 0 2Then mount everything in fstab and confirm it worked:
mount -a
df -h /mnt/extra-storageIf df -h shows your disk mounted at /mnt/extra-storage with the size you expect, the disk side is done. Reboot the host once here if you can spare the downtime — it's the easiest way to confirm the fstab entry actually survives a restart, rather than finding out during your next scheduled maintenance window.
Step 4: Add the storage in the Proxmox web GUI
In the Proxmox web interface, click Datacenter in the left tree, then go to Storage, then click Add and choose Directory from the dropdown.
Fill in the dialog:
- ID — a short name for this storage, like
extra-storage. This is what you'll see in dropdown menus later, so make it descriptive. - Directory — the absolute path,
/mnt/extra-storage - Content — tick the content types you want this storage to hold: Disk image, ISO image, Container template, VZDump backup file, Snippets
- Nodes — leave this on "All" unless you specifically want the storage restricted to certain nodes in a cluster
There's also an Is Mountpoint checkbox on this dialog. Tick it. It tells Proxmox to treat the path as an externally managed mount and mark the storage offline if the disk isn't actually mounted — instead of silently writing to your root filesystem. We'll come back to why this matters in the Best Practices section.
Click Add. The new storage shows up immediately in the storage tree on the left, with a status of "active" if everything's working.
Step 5: Add the storage from the command line (alternative to Step 4)
If you'd rather script this or you're comfortable skipping the GUI, the CLI equivalent is one command:
pvesm add dir extra-storage --path /mnt/extra-storage \
--content images,iso,vztmpl,backup,snippets \
--is_mountpoint yesThis does exactly what the GUI dialog did — registers the storage in /etc/pve/storage.cfg with the content types and mountpoint safety check you specified. You only need to do this once, either through the GUI or the CLI, not both.
Step 6: Verify and test
Run:
pvesm statusYou should see your new storage listed with a status of active and the correct total and available size. If it says inactive, the mount isn't there — jump to Troubleshooting below.
For a real test, go to the storage in the GUI, open the ISO Images tab, and upload a small ISO file. If the upload completes and the file shows up, your directory storage is fully working and ready to hold VM disks, backups, and templates.
Commands Explained
| Command | What it does |
|---|---|
lsblk | Lists block devices attached to the system, so you can identify which one is your unused disk before touching anything. |
parted /dev/sdb --script mklabel gpt mkpart primary ext4 0% 100% | Creates a GPT partition table and one partition spanning the full disk, without the interactive prompts. |
mkfs.ext4 /dev/sdb1 | Formats the partition with the ext4 filesystem, wiping anything that was on it before. |
blkid /dev/sdb1 | Prints the partition's UUID, which you use in /etc/fstab instead of a device name that can change. |
mount -a | Mounts every entry in /etc/fstab that isn't already mounted — the quickest way to confirm your new fstab line has no typos. |
pvesm add dir <id> --path <path> | Registers a directory as Proxmox storage with the given ID, writing the entry into /etc/pve/storage.cfg. |
pvesm status | Shows every configured storage, whether it's active, and how much space is used and free. |
Common Errors
"directory is expected to be a mount point" — you ticked Is Mountpoint but the path isn't actually mounted right now. Run mount -a and check df -h again before retrying.
Storage shows as "unknown" right after a reboot — this almost always means the fstab entry is wrong or the disk didn't spin up in time before Proxmox tried to read it. Check journalctl -b for mount errors around boot time.
"mkdir /mnt/extra-storage/dump: Permission denied" during a backup job — the mount point's ownership got reset, usually because something remounted the filesystem without preserving permissions. Run chown root:root /mnt/extra-storage and chmod 0755 /mnt/extra-storage.
ISO upload fails with "no space left on device" even though df shows free space — check inode usage with df -i. It's rare, but if you're storing thousands of tiny snippet or template files, you can run out of inodes before you run out of bytes on some ext4 configurations.
Troubleshooting
Start with pvesm status. If your storage shows inactive, the problem is almost always that the underlying path isn't mounted. Confirm with:
mount | grep extra-storageNothing returned means it's not mounted. Try mount -a and read whatever error comes back — it usually points straight at the fstab line that's wrong, whether that's a typo in the UUID or a filesystem type mismatch.
If the mount works fine manually but doesn't survive a reboot, check systemctl status for any mount unit related to your path, and look at journalctl -b -1 (logs from the previous boot) for errors during startup. A common cause is a USB-connected drive that simply isn't ready by the time fstab mounts run — external drives are best avoided for this reason, or you'll want to add the nofail option to the fstab line so a missing drive doesn't stall the whole boot.
If Proxmox can see the storage but VM disk creation fails, double check that Disk image is actually ticked in the storage's content types. It's an easy checkbox to miss during setup, and the resulting error message ("content type images not available") doesn't make the fix obvious.
Best Practices
Always enable Is Mountpoint for storage backed by a separate disk. Without it, if that disk ever fails to mount — a loose cable, a drive that dies, a typo that creeps into fstab during some unrelated change — Proxmox will happily write backups and VM disks straight onto your root filesystem instead. You won't notice until your root disk fills up or, worse, until you need a backup that was never actually written to the disk you thought it was on.
Keep backups on a physically different disk from the one holding your VM images. If a disk dies, you don't want to lose the VMs and the only copy of their backups in the same failure.
Don't enable the Shared option unless the underlying path really is a shared filesystem reachable identically from every node in a cluster. Marking a purely local directory as shared will cause failures the moment Proxmox tries to migrate a VM and assumes the storage is reachable from the target node.
Name your storage IDs for what they hold, not just where they are — backups-hdd tells you more six months from now than storage2 does.
Frequently Asked Questions
Can directory storage be used across a Proxmox cluster?
Only if the path is genuinely shared, like an NFS or CIFS mount every node can reach. A plain local directory on one node's disk is only usable by that node.
Does directory storage support snapshots?
Storage-level snapshots aren't supported. If your VM disks use the qcow2 format, though, qcow2's own internal snapshot support still works fine on directory storage.
Do I have to use ext4?
No. XFS works identically for this purpose. Avoid filesystems without proper Linux permission and ownership support, since Proxmox relies on those.
Is directory storage slower than ZFS or LVM-Thin?
Not inherently — a single disk performs about the same regardless of the storage layer on top of it. What you lose isn't speed, it's features: no checksumming, no built-in redundancy, no thin provisioning.
Can I convert directory storage to ZFS later without losing data?
Not directly on the same disk without wiping it. You'd migrate VM disks off (using Move Disk in the GUI) to another storage first, then reformat the drive as a ZFS pool and move things back.
Conclusion
Directory storage isn't glamorous, and it's not what you'll want for a serious multi-node cluster. But for a single Proxmox box with a spare disk, it does exactly what you need with almost nothing that can go wrong — provided you remember the Is Mountpoint checkbox and use UUIDs in fstab. Once this storage is up and active, every ISO upload, VM disk, and backup job in Proxmox will offer it as a destination right alongside your default local storage, no different from any other option in the list.