How to Fix 'Could Not Activate Storage' in Proxmox VE (NFS, CIFS, ZFS, and LVM Explained)

Introduction

You click Create VM, get through the wizard, and right before the disk step Proxmox throws back a wall of red text: could not activate storage 'nfs-backup', directory '/mnt/pve/nfs-backup' does not exist or is unreachable (500). Or maybe it isn't that dramatic — you just notice a storage pool showing a grey question mark in the GUI, or a nightly backup job that failed silently and your phone buzzed with the notification at 3 a.m. Either way, this is one of the most common errors homelab users and small IT shops run into with Proxmox VE, and it almost never means your data is gone. It means Proxmox currently can't reach or mount whatever your VMs and backups actually live on.

The good news is that the fix is usually fast once you know where to look. The error message itself tells you the storage type, and each backend — NFS, CIFS/SMB, ZFS, and LVM — fails for its own specific reasons. This guide walks through all four, with the exact commands to diagnose and repair each one.

What You Will Learn

• What "storage activation" actually means in Proxmox VE, and why it's separate from just having the storage configured
• How to read the exact wording of a "could not activate storage" error to identify which backend is failing
• Step-by-step fixes for NFS, CIFS/SMB, ZFS pool, and LVM/LVM-thin activation failures
• The commands behind the GUI: pvesm, zpool, vgscan, and journalctl
• How to tell a genuine hardware or network problem apart from a stale configuration entry
• A few habits that stop this error from becoming a recurring 3 a.m. problem

What Is This Feature?

Every storage pool you see under Datacenter → Storage is really just an entry in a text file called /etc/pve/storage.cfg. That file lives in Proxmox's cluster filesystem (pmxcfs), so every node in a cluster reads the same definitions. Adding a storage in the GUI doesn't touch a single disk — it just writes a block of config describing a type (nfs, cifs, zfspool, lvm, dir, and a handful of others), a path or pool name, and which content types it's allowed to hold (VM disks, ISOs, backups, and so on).

A background service called pvestatd (the Proxmox VE Statistics Daemon) polls every configured storage roughly every ten seconds to see if it's actually reachable — is the NFS export mounted, is the ZFS pool imported, is the volume group present. That poll is what "activation" refers to. When it succeeds, the storage shows green in the GUI and VMs can read and write to it. When it fails, you get the red status icon and, if a task tried to use that storage at the same moment, the "could not activate storage" error in the task log. The config existing and the storage being active are two different things, and that distinction is the whole reason this error exists.

A Quick Primer on the Four Common Backends

If you're newer to Proxmox, here's the short version of each storage type this article covers:

• NFS (Network File System) is a way for Linux servers to share a folder over the network. Proxmox mounts an NFS export the same way your laptop might mount a network drive.
• CIFS/SMB is the Windows-style equivalent — the protocol behind Windows file sharing, also used by Synology and QNAP NAS boxes.
• ZFS is a combined filesystem and volume manager built into Proxmox. A ZFS storage pool has to be "imported" before the OS can see it, which is different from just having the disks physically plugged in.
• LVM (Logical Volume Manager) is a Linux layer that lets you carve one or more physical disks into flexible logical volumes. Proxmox uses it a lot for local VM storage on top of plain disks or iSCSI LUNs.

Why Would You Use It?

Understanding this error matters because storage activation failures rarely announce themselves loudly at the moment they happen. A ZFS pool that didn't import after a reboot will just sit there quietly — no VMs will start, but the host itself boots fine, so it's easy to assume everything's okay until you actually try to use a guest. An NFS share that goes offline mid-backup will fail the backup job and move on; if nobody checks the backup log for a week, you find out about it the hard way. Knowing the difference between "my network died," "my ZFS pool didn't import," and "my LVM volume group lost a disk" saves you from randomly rebooting the host and hoping, which fixes some of these problems by accident and none of them reliably.

There's also a cluster angle. In a multi-node setup, a storage failure on one node doesn't necessarily mean the storage itself is broken — it might just be that one node's network path to the NFS server is down while the other two nodes are fine. Recognizing that pattern quickly tells you where to actually look instead of chasing the wrong node for twenty minutes.

Prerequisites

• Root access to the Proxmox VE host, either via the web shell or SSH
• Proxmox VE 8.x or 9.x — the commands here are unchanged between the two; this was verified against the current 9.2 release
• Basic comfort with a Linux terminal (you don't need to be an expert, just able to copy and paste commands)
• Network access between the Proxmox host and whatever the storage actually is (a NAS, a SAN, or local disks)
• Knowing which storage ID is failing — check the GUI or run pvesm status first

Step-by-Step Tutorial

Step 1: Read the Exact Error Text

Don't skip this one. The wording after "could not activate storage" tells you almost everything. Open Datacenter → Tasks or the failed job's log and copy the full line. A few real examples:

• could not activate storage 'nfs-iso', directory '/mnt/pve/nfs-iso' does not exist or is unreachable — an NFS or CIFS mount problem
• could not activate storage 'local-zfs', zfs error: cannot import 'rpool': no such pool available — a ZFS import problem
• could not activate storage 'vmstore', vgs command failed - check syslog — an LVM problem, often a missing disk

Step 2: Check Overall Storage Status

pvesm status

This lists every configured storage, its type, and whether it's active. Anything showing a status other than active is your target. Cross-reference the storage ID against /etc/pve/storage.cfg to confirm the backend type if you're not sure:

cat /etc/pve/storage.cfg

Step 3a: Fixing NFS Activation Failures

First, confirm the NFS server is actually reachable and exporting what Proxmox expects:

showmount -e 10.0.0.10

If that command hangs or errors out, the problem is network-level or the NFS server itself is down — check the NAS, check the switch, check whether the export was renamed. If showmount works but Proxmox still can't mount it, try a manual mount to isolate the issue:

mount -t nfs -o vers=3,soft 10.0.0.10:/export/data /mnt/test

A stuck mount here usually points at NFSv4 locking weirdness or a mismatched export path. Forcing vers=3 fixes more of these than you'd expect — I've lost track of how many "random" NFS hangs on a homelab NAS turned out to be an NFSv4 lock daemon that just wasn't behaving. If the manual mount succeeds, re-enable the storage:

pvesm set nfs-iso --disable 0
systemctl restart pvestatd

Step 3b: Fixing CIFS/SMB Activation Failures

CIFS storage in Proxmox keeps its credentials in a separate file at /etc/pve/priv/storage/<storage-id>.pw. A surprisingly common cause of activation failure is a NAS admin changing the share password and nobody updating that file. Test the share directly:

smbclient -L //10.0.0.11 -U anna

If authentication fails there, update the password through Datacenter → Storage → [your CIFS entry] → Edit rather than editing the credentials file by hand. If authentication works but Proxmox still won't activate it, check the SMB protocol version — some NAS firmware updates disable SMB1 by default, which breaks storage entries still configured with an old smbversion setting.

Step 3c: Fixing ZFS Pool Activation Failures

This one bites people most often right after a reboot, a motherboard swap, or moving disks to a different controller. Check what ZFS itself sees:

zpool status
zpool import

The second command lists pools that exist on disk but aren't currently imported. If your pool shows up there, import it:

zpool import rpool

If that fails with a complaint about the pool being "potentially in use" or a mismatched hostid — common after cloning a disk or restoring to different hardware — you can force it, but only if you're certain nothing else has that pool mounted:

zpool import -f rpool

After a successful import, tell ZFS to remember it for next boot so you're not doing this again after every reboot:

zpool set cachefile=/etc/zfs/zpool.cache rpool

Step 3d: Fixing LVM Activation Failures

LVM failures almost always mean a physical volume went missing — a disk that got unplugged, a SAN LUN that dropped, or a disk that came back with a different device name after reboot. Check what's actually visible:

pvs
vgs
lvscan

If vgs reports the volume group as missing a device, that physical disk isn't showing up to the OS at all — that's a hardware or iSCSI connectivity problem, not a Proxmox one. If the volume group is present but just not active, activate it:

vgchange -ay myspace

Step 4: Confirm the Fix

Whichever backend you were chasing, finish with:

pvesm status

and confirm the storage now shows active. Then try the operation that originally failed — creating a disk, running the backup job, whatever it was — to be sure it wasn't just a stale GUI cache.

Commands Explained

Common Errors

Troubleshooting

Sometimes the fix above doesn't stick, and the storage flips back to inactive within a minute or two. A few things worth checking:

• Check whether it's cluster-wide or node-specific. Run pvesm status on every node — if only one node shows the failure, the problem is that node's network path or local hardware, not the storage config itself.
• Look at the daemon's own log for context beyond the one-line error: journalctl -u pvestatd -n 50 --no-pager. It'll often show the exact underlying command that failed and why.
• For NFS, a firewall change is a very easy thing to overlook. NFS uses more than one port depending on version, and a switch or router ACL update elsewhere on the network can quietly block it without anyone touching Proxmox at all.
• If a storage was recently renamed in storage.cfg but VM configs still reference the old ID, you'll see activation succeed while individual VMs still error out — check each guest's Hardware tab for a disk pointing at a storage ID that no longer exists.
• Rebooting the whole host "to fix it" sometimes works by accident for ZFS import issues, but it does nothing for NFS/CIFS network problems and just costs you downtime. Diagnose first.

Best Practices

• Set NFS mount options to soft rather than the default hard-mount behavior, so a dead NFS server doesn't hang the whole Proxmox host waiting on I/O.
• Run zpool set cachefile=/etc/zfs/zpool.cache <pool> after any manual ZFS import so the pool comes back automatically on the next boot.
• Keep a copy of CIFS credentials somewhere other than just /etc/pve/priv/storage/, since that directory isn't something you'll casually browse when troubleshooting under pressure.
• Test storage reachability after every host reboot, not just after changes — a surprising number of ZFS-import and NFS-mount failures only show up after a cold boot, not a live session.
• Avoid making a single NAS or NFS server a hard dependency for anything that needs to boot unattended; a network blip at 2 a.m. shouldn't be able to stall your whole cluster.
• Set up email or webhook notifications for failed backup and replication tasks. Honestly, most people only find out about a dead storage pool because a backup job finally failed loudly enough to notice.

Frequently Asked Questions

Will a failed storage activation delete my data?

No. This error means Proxmox can't currently reach or mount the storage — the underlying data is untouched unless there's a separate hardware failure involved.

Does restarting pvestatd actually fix anything?

Sometimes, if the underlying problem (network, ZFS import, LVM) has already been resolved and the GUI just hasn't refreshed. On its own it won't fix a genuinely broken mount or missing disk.

Why does only one node in my cluster show this error?

That almost always points to a node-specific issue — a bad network cable, a firewall rule applied to one host, or a disk that's only physically present on that one machine.

Is it safe to force-import a ZFS pool with zpool import -f?

Usually yes on a single-host setup, but be careful if the pool could still be mounted somewhere else (a cloned disk, a shared SAN LUN) — forcing an import in that situation risks corruption.

Can I just delete the storage entry and re-add it?

You can, and it often "fixes" the symptom, but it doesn't explain why it failed in the first place. Diagnose the actual cause first so it doesn't come back next week.

What's the difference between a disabled storage and an inactive one?

Disabled means you (or someone) intentionally turned it off with pvesm set --disable 1. Inactive means Proxmox tried to activate it and couldn't, regardless of the disable setting.

Conclusion

Storage activation errors look scarier than they usually are, mostly because the GUI message is terse and the actual cause could be four completely different things hiding behind one wording. Once you know that NFS problems live in the network layer, ZFS problems live in the import state, and LVM problems live in missing physical volumes, the troubleshooting stops feeling random. Most of these take under fifteen minutes to resolve once you're looking in the right place, and a lot of them take under a minute. The bigger win is catching them before a VM actually needs that storage — a quick pvesm status check after any reboot or network change is a cheap habit that saves you from finding out the hard way.