Proxmox “Unable to activate storage”: Diagnose LVM, NFS, and CIFS the right way

What “unable to activate storage” actually means in Proxmox

In Proxmox, “storage” is a plugin-driven abstraction over very different realities: a local LVM volume group, a mounted NFS export, a CIFS mount, iSCSI LUNs, ZFS pools, directory paths, and so on. When Proxmox says it can’t “activate” storage, it generally means one of these things:

• The backend isn’t present (VG not found, mount not mounted, path missing).
• The backend is present but not usable (permissions, stale handle, read-only, wrong options, auth failure).
• Proxmox can’t run the activation step (tool missing, command fails, service ordering, lock contention).
• The node thinks it’s in charge when it isn’t (cluster config mismatch, node-specific storage definitions, split-brain-y symptoms).

The key is to treat it like an SRE incident: define blast radius (one node or all), isolate the failing backend, gather evidence, then change one variable at a time.

One quote worth keeping on your wall:

“Hope is not a strategy.” — General Gordon R. Sullivan

Storage troubleshooting is where hope goes to die. That’s good. It forces you to measure.

Joke #1: Storage outages are like toddlers: the louder they get, the more likely the problem is something basic you ignored.

Fast diagnosis playbook (first/second/third)

If you’re on call and you need signal fast, don’t start by editing random Proxmox configs. Do this:

First: confirm the scope and the specific storage ID

• Is it one node or multiple?
• Is it one storage entry or all of them?
• Is it only VM starts, or also container starts and backups?

Goal: name the failing storage exactly (its storage ID in Proxmox), and identify the affected node(s).

Second: validate the OS-level truth (mounts/VGs/paths), not the GUI’s feelings

• For NFS/CIFS: is it actually mounted at the expected path?
• For LVM: does the VG exist and are LVs visible?
• For everything: can you read/write the path as root?

Goal: prove whether the backend exists and is usable from the node’s shell.

Third: look at Proxmox task logs and journal for the real error string

• Proxmox wraps backend errors. The wrapper message is rarely the fix.
• Find the underlying command that failed (mount, vgchange, lvcreate, etc.).

Goal: get the precise error: “permission denied”, “no such device”, “protocol not supported”, “unknown filesystem type”, “wrong fs type”, “stale file handle”, “timed out”. That string determines the next move.

Interesting facts and context (because history repeats)

1. LVM2 became the standard on Linux after lessons learned from LVM1 and vendor volume managers; it’s stable, but activation depends on device discovery and udev timing.
2. NFSv3 is stateless (mostly), which is why it can “work” until it suddenly doesn’t and then recovers in odd ways; NFSv4 changed the model with stateful sessions.
3. “Stale file handle” is an NFS classic that dates back decades; it’s basically your client holding an inode reference the server no longer recognizes.
4. SMB1 (CIFS) was a security dumpster fire and modern systems often disable it; mismatched SMB dialect negotiation is a quiet cause of mount failures.
5. systemd changed mount ordering for many admins who grew up with sysvinit; what “worked on boot” before can now fail unless dependencies are declared.
6. Cluster filesystems and shared storage are different problems; Proxmox can share configuration via corosync, but your storage still has to be reachable and consistent.
7. Multipath and LVM don’t automatically love each other; if you activate VGs on the wrong underlying devices, you can create duplicate PV detection or “device mismatch” weirdness.
8. NFS performance tuning can break correctness when people get cute with caching or timeouts; the fastest bug is still a bug.

Triage: identify the backend and scope of failure

Before you go deep: identify what type of storage Proxmox thinks it’s activating. Proxmox storage entries live in cluster config, but the activation happens on each node. That’s why one node can fail while others are fine.

Practical rule: if Proxmox storage is “Directory”, “NFS”, or “CIFS”, failures usually map to mount problems or permissions. If storage is “LVM” or “LVM-thin”, failures map to device discovery, VG activation, or locking.

Also decide whether you’re in “restore service” mode or “forensic correctness” mode. In restore mode, you prioritize getting VMs running without making the next outage worse. In forensic mode, you preserve evidence and change less. Pick one; don’t oscillate every 10 minutes.

LVM: activation failures that look like Proxmox problems

LVM failures are often boring and local: the node can’t see the block device, the VG isn’t active, or LVM is confused about which device is the “real” PV. Proxmox reports it as “unable to activate storage” because from its perspective the LVM storage plugin can’t do its job.

Common LVM failure categories

• VG not found: the PV device isn’t present (disk missing, iSCSI not logged in, multipath not ready).
• VG exists but inactive: activation didn’t happen at boot or failed due to locking.
• Duplicate PVs: same LUN visible via multiple paths without proper multipath configuration.
• Thin pool problems: thin metadata full, pool read-only, or activation blocked by errors.
• Filter problems: lvm.conf device filters exclude the real devices, so discovery is inconsistent.

What “activate” means for LVM in Proxmox terms

For LVM-thin storage, Proxmox expects the volume group to be discoverable and the thin pool LV to be active. It will run LVM commands under the hood. If those commands return non-zero, Proxmox gives you the umbrella error.

If you’re troubleshooting LVM, your first question should be: “Does the node see the block device, and does LVM agree?” Not “What does the GUI say?”

NFS: mounts that fail, hang, or lie

NFS is popular in Proxmox because it’s simple: mount an export and treat it like a directory. It also fails in ways that look like Proxmox bugs but are really network, DNS, firewall, server exports, or version negotiation issues.

NFS failure categories that trigger “unable to activate storage”

• Mount never happens: wrong server address, wrong export path, firewall, RPC services blocked.
• Mount happens but is read-only: export options or server-side permission mapping (root squash, UID mapping).
• Stale file handle: server-side changes (filesystem remount, failover, snapshot promotion) invalidate handles.
• Timeouts that look like hangs: NFS I/O stuck can block Proxmox tasks and make the node feel “slow” rather than “down”.
• Wrong NFS version: client tries v4 but server only supports v3 (or vice versa), or v4 requires a different export layout.

With NFS, “activation” is basically “ensure mount is present and responsive”. A mountpoint that exists but is unresponsive is worse than a clean failure because it causes processes to hang in uninterruptible I/O sleep.

CIFS/SMB: authentication, dialects, and the cruel joy of permissions

CIFS in Proxmox is just “mount a SMB share and treat it like a directory”. Which means every SMB nuance becomes your problem: dialect negotiation (SMB2/3), NTLM vs Kerberos, domain trust, password rotation, and file ownership semantics.

CIFS failure categories

• Authentication failures: wrong credentials, expired password, domain issues, NTLM policy changes.
• Dialect mismatch: server disables older SMB versions; client defaults mismatch; security hardening breaks mounts.
• Permission mapping weirdness: mounted but root can’t write due to server ACLs or mount options.
• DFS/referrals surprises: you mounted a path that redirects and now it doesn’t.
• “Works manually, fails in Proxmox”: because Proxmox uses specific mount options or reads credentials from a file with wrong permissions.

Joke #2: SMB permissions are like office politics: everyone insists it’s “simple,” and then nothing works unless Carol approves it.

Practical tasks: commands, expected outputs, and decisions (12+)

These tasks are ordered roughly from “fast signal” to “deep detail”. Run them on the affected node first. If it’s a cluster, compare a working node to a failing node—diffing reality is underrated.

Task 1: Confirm which storage Proxmox thinks is failing

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active       1024000000        12345678       987654321        1.2%
nfs-backup        nfs     inactive              0               0               0          0%
lvm-thin          lvmthin inactive              0               0               0          0%

What it means: “inactive” here is Proxmox’s view, not a diagnosis. It tells you which storage IDs to focus on (e.g., nfs-backup, lvm-thin).

Decision: Pick one failing storage ID and follow the matching backend section. Don’t shotgun-fix everything at once.

Task 2: Inspect the storage definition as Proxmox sees it

cr0x@server:~$ pvesm config nfs-backup
nfs-backup: nfs
        export /exports/proxmox-backup
        path /mnt/pve/nfs-backup
        server 10.20.30.40
        content backup,iso
        options vers=4.1

What it means: You get the authoritative mountpoint and server/export parameters Proxmox will use.

Decision: Validate the mountpoint exists and whether it’s mounted, and validate network reachability to the server IP/hostname.

Task 3: Check Proxmox task logs for the real error

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:pve01:0000A1B2:0001C3D4:676D0F00:vzdump::root@pam:
UPID:pve01:0000A1B3:0001C3D5:676D0F10:mount::root@pam:storage=nfs-backup:

cr0x@server:~$ journalctl -u pvedaemon -u pvestatd -u pve-storage -n 200 --no-pager
Dec 26 10:11:12 pve01 pvestatd[1234]: storage 'nfs-backup' is not online
Dec 26 10:11:13 pve01 pvedaemon[2345]: storage activate failed: mount error(13): Permission denied

What it means: You’re hunting the underlying errno: here it’s permission denied (error(13)) from CIFS-like semantics or server-side access control.

Decision: Stop. “Permission denied” is not fixed by rebooting. Go check credentials/export permissions.

Task 4: Validate the mountpoint state (NFS/CIFS/dir)

cr0x@server:~$ findmnt /mnt/pve/nfs-backup
TARGET             SOURCE                    FSTYPE OPTIONS
/mnt/pve/nfs-backup 10.20.30.40:/exports/proxmox-backup nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

What it means: If findmnt returns nothing, it’s not mounted. If it returns NFS/CIFS but the system still errors, the mount may be stale or permissioned wrong.

Decision: If unmounted, attempt a controlled mount and capture the exact error. If mounted, test I/O responsiveness.

Task 5: Test read/write and detect “hung mount” fast

cr0x@server:~$ timeout 5 bash -c 'ls -la /mnt/pve/nfs-backup >/dev/null; echo OK'
OK

What it means: If this command times out, the mount is hanging. That’s a network/server problem (or a dead session), not Proxmox.

Decision: For hung mounts, don’t run backup jobs “to see if it clears”. Fix connectivity or unmount/remount safely.

Task 6: Check basic network reachability (don’t overthink it)

cr0x@server:~$ ping -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=0.482 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=0.455 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

What it means: Ping isn’t proof of NFS/SMB health, but failure is a strong hint you’re chasing the wrong layer.

Decision: If ping fails, check routing/VLAN/firewall before touching storage config.

Task 7: NFS-specific: verify exports visible from the client

cr0x@server:~$ showmount -e 10.20.30.40
Export list for 10.20.30.40:
/exports/proxmox-backup 10.20.30.0/24

What it means: If the export isn’t listed (or showmount times out), your server-side exports/RPC services/firewall are the issue.

Decision: Fix NFS server export configuration or firewall rules; don’t “fix” Proxmox for a server refusing you.

Task 8: NFS-specific: attempt a manual mount with explicit version/options

cr0x@server:~$ umount /mnt/pve/nfs-backup 2>/dev/null || true
cr0x@server:~$ mount -t nfs -o vers=4.1,proto=tcp,timeo=600,retrans=2 10.20.30.40:/exports/proxmox-backup /mnt/pve/nfs-backup
cr0x@server:~$ dmesg | tail -n 8
[123456.789012] nfs: server 10.20.30.40 OK

What it means: A manual mount isolates Proxmox from the equation. If manual mount fails, the backend is the problem. If it succeeds, compare options with Proxmox’s config.

Decision: If manual mount only works with different vers= or options, update the Proxmox storage options accordingly.

Task 9: CIFS-specific: validate credentials file permissions and contents

cr0x@server:~$ ls -l /etc/pve/priv/storage/cifs-prod.pw
-rw------- 1 root root 64 Dec 26 09:55 /etc/pve/priv/storage/cifs-prod.pw
cr0x@server:~$ sed -n '1,5p' /etc/pve/priv/storage/cifs-prod.pw
username=svc_proxmox
password=REDACTED
domain=CORP

What it means: Proxmox expects credentials files to be readable by root only. Wrong permissions can cause mounts to fail or leak secrets.

Decision: If permissions aren’t 600, fix them. If credentials changed, update them and consider password rotation procedures.

Task 10: CIFS-specific: manual mount with explicit SMB dialect and security

cr0x@server:~$ umount /mnt/pve/cifs-prod 2>/dev/null || true
cr0x@server:~$ mount -t cifs //fileserver01/proxmox -o credentials=/etc/pve/priv/storage/cifs-prod.pw,vers=3.0,sec=ntlmssp,uid=0,gid=0,file_mode=0660,dir_mode=0770 /mnt/pve/cifs-prod
cr0x@server:~$ findmnt /mnt/pve/cifs-prod
TARGET           SOURCE                    FSTYPE OPTIONS
/mnt/pve/cifs-prod //fileserver01/proxmox  cifs   rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=svc_proxmox,uid=0,gid=0,file_mode=0660,dir_mode=0770

What it means: If adding vers=3.0 fixes it, your server likely disabled older dialects. If sec= matters, your domain policy changed.

Decision: Align Proxmox storage options with what actually works, and coordinate with the file server team so they don’t “harden” you into downtime again.

Task 11: LVM: check whether the VG and thin pool exist

cr0x@server:~$ vgs
  VG         #PV #LV #SN Attr   VSize    VFree
  pve        1   7   0  wz--n-  930.00g  12.00g
  vg_vmdata  1   2   0  wz--n-    3.64t  120.00g

cr0x@server:~$ lvs -a -o +devices vg_vmdata
  LV          VG        Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  thinpool    vg_vmdata twi-aotz--  3.40t             62.10  4.20                             /dev/sdb(0)
  thinpool_tmeta vg_vmdata ewi-aotz-- 8.00g                                                   /dev/sdb(870912)
  thinpool_tdata vg_vmdata ewi-aotz-- 3.40t                                                   /dev/sdb(2048)

What it means: The VG exists, and the thin pool is active (twi-a). If you see twi--- without a, it’s not active. If the VG is missing, the underlying block device isn’t visible or discovered.

Decision: If VG missing: check disks/iSCSI/multipath. If thin pool inactive: attempt activation and inspect errors.

Task 12: LVM: attempt controlled activation and capture errors

cr0x@server:~$ vgchange -ay vg_vmdata
  1 logical volume(s) in volume group "vg_vmdata" now active

What it means: Successful activation is immediate and explicit. If it fails, LVM will tell you why (locking, missing PVs, duplicates).

Decision: If activation succeeds, re-check pvesm status. If it fails, follow the error string—don’t improvise.

Task 13: LVM: detect missing PVs or duplicate device paths

cr0x@server:~$ pvs -o+pv_uuid,pv_name,vg_name,dev_size
  PV         VG        Fmt  Attr PSize  PFree  PV UUID                                DevSize
  /dev/sdb   vg_vmdata lvm2 a--  3.64t 120.00g 9Hk3vS-9Qb8-1x2c-7y5n-ABCD-ef01-2345  3.64t

What it means: If you see the same PV UUID on multiple devices (common with multipath misconfig), LVM will refuse to proceed or will behave unpredictably.

Decision: Fix multipath so only one path is used (usually /dev/mapper/mpathX), then update LVM filters if needed.

Task 14: Check kernel and systemd logs around mounts and LVM

cr0x@server:~$ journalctl -b -p warning..alert --no-pager | tail -n 60
Dec 26 09:42:01 pve01 systemd[1]: mnt-pve-nfs\x2dbackup.mount: Mount process exited, code=exited, status=32/n/a
Dec 26 09:42:01 pve01 kernel: CIFS: VFS: cifs_mount failed w/return code = -13
Dec 26 09:42:02 pve01 lvm[987]: device-mapper: thin: Data device (dm-3) discard granularity larger than a block: disabling discards

What it means: systemd gives you exit statuses, kernel logs show mount return codes, and LVM emits device-mapper hints that can indicate underlying block-layer trouble.

Decision: If systemd mount unit failed, check mount options and ordering; if CIFS return code -13, it’s permissions; if kernel shows I/O errors, stop and investigate disk/network storage.

Task 15: Confirm Proxmox can activate now (and it sticks)

cr0x@server:~$ pvesm set nfs-backup --disable 0
cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
nfs-backup        nfs     active        2048000000       123456789      1920000000       6.0%

What it means: This confirms Proxmox’s storage plugin can see and use the backend again.

Decision: Start one VM and run a lightweight storage action (create small disk, list backups). Verify it survives a reboot if this was a boot-order issue.

Common mistakes: symptom → root cause → fix

1) “Storage inactive” only on one node

Symptom: Cluster shows storage offline on pve02, fine on pve01.

Root cause: Node-local problem: network path, mount not present, iSCSI session not logged in, or disk missing.

Fix: Diagnose on the failing node with findmnt/vgs; compare with working node; fix network/mount/iSCSI before touching cluster config.

2) NFS mount exists but Proxmox operations hang

Symptom: VM start, backup, or “browse storage” stalls; SSH sometimes feels slow; unkillable processes.

Root cause: Hung NFS I/O; mount is “there” but unresponsive due to server/network issues.

Fix: Use timeout test; check network; consider remount after restoring connectivity. Avoid “soft” mounts for VM storage—corruption is a worse day.

3) CIFS mount fails after password rotation

Symptom: “mount error(13): Permission denied” suddenly after months of stability.

Root cause: Rotated service account password; credentials file stale; or domain policy changed required auth method.

Fix: Update credentials file; ensure permissions 600; pin vers=3.0 and sec=ntlmssp if required by policy.

4) LVM-thin storage inactive after reboot

Symptom: After reboot, LVM storage inactive; manual vgchange -ay fixes it.

Root cause: Boot ordering: underlying device appears late (multipath, iSCSI), so LVM activation at boot misses it.

Fix: Ensure iSCSI/multipath services start before LVM activation; fix device discovery; avoid race-by-reboot as an “activation strategy”.

5) “Volume group not found” but disks appear present

Symptom: vgs doesn’t list the VG; but lsblk shows the disk.

Root cause: LVM device filter excludes it; or PV signatures are on a different device path than expected.

Fix: Review /etc/lvm/lvm.conf filters; standardize on stable device paths (by-id, mapper for multipath).

6) NFS export works from one subnet but not another

Symptom: One Proxmox node mounts; another gets “access denied by server”.

Root cause: Export restrictions by IP/subnet; new node on a different VLAN; reverse DNS expectations.

Fix: Correct server export access list; keep Proxmox nodes in the expected subnets; don’t rely on reverse DNS if you can avoid it.

7) CIFS mounts manually but Proxmox still claims inactive

Symptom: You can mount the share, but Proxmox plugin still reports inactive.

Root cause: Proxmox mountpoint mismatch, different options, or Proxmox expects it under /mnt/pve/<storageid>.

Fix: Confirm pvesm config path; ensure mount is at that exact path; avoid custom mounts outside Proxmox’s expected directories unless you know the implications.

8) “Stale file handle” after storage maintenance

Symptom: NFS path exists; operations fail with stale handle; sometimes fixed by remount.

Root cause: Server-side filesystem switched, export remapped, or failover moved backing store without preserving inode consistency.

Fix: Coordinate maintenance; remount clients; ensure HA/failover preserves export identity when possible.

Three corporate mini-stories from the storage trenches

Incident caused by a wrong assumption: “It’s a Proxmox bug”

They had a small Proxmox cluster and a “reliable” NFS share for backups. One Monday morning, backups failed with “unable to activate storage.” The team’s first move was a Proxmox upgrade plan, because the GUI said storage was inactive and therefore Proxmox must have broken something.

Meanwhile, the NFS server had been moved behind a new firewall rule set. Ping worked. DNS worked. Even SSH worked. That was enough for everyone to assume storage would too. It didn’t. The firewall blocked the NFS-related traffic, and the mount attempts timed out.

The upgrade got postponed when someone finally ran showmount -e and it hung. That was the clue. Not “Proxmox storage inactive,” but “the node cannot talk NFS to that server.” The fix was a firewall rule adjustment and a remount. Backups resumed.

The uncomfortable lesson wasn’t about NFS ports. It was about process: nobody had a first-responder playbook, so they defaulted to “change the application” rather than “prove the dependency.”

Optimization that backfired: tuning NFS like a race car

A different org used NFS for ISO images and container templates. It was fine. Then someone decided to “optimize” with aggressive mount options they found in a forum post: shorter timeouts, “soft” mounts, and various caching tweaks, because “it’s just ISO storage.”

It worked for weeks. Then a network hiccup hit during a template extraction. The “soft” behavior returned I/O errors up the stack rather than waiting for recovery. The result wasn’t just a failed template download—it produced partial files that looked valid enough to be used later.

Now they had a heisenbug: containers sometimes failed to start, sometimes booted with missing files, and the storage layer looked “active” the whole time. When they finally tested file integrity, they found corrupted artifacts that had been quietly cached and reused.

The fix was to revert to sane defaults: “hard” mounts for anything that affects correctness, explicit NFS version pinning, and a policy that “optimization requires a rollback plan.” Performance tuning without failure testing is just gambling with extra steps.

Boring but correct practice that saved the day: comparing nodes and logging the real error

A mid-sized company ran LVM-thin on top of multipath-attached storage. One morning after a storage firmware change, one node wouldn’t activate the LVM storage. The rest of the cluster was fine. Panic started. The storage vendor got blamed. The hypervisor team got blamed. Everyone practiced their favorite sport: unhelpful certainty.

The on-call engineer did something deeply unsexy: they compared a working node to the broken one. Same Proxmox version. Same storage config. So they ran pvs and noticed the broken node saw the LUN both as /dev/sdX and as /dev/mapper/mpathY. Duplicate PV signatures. LVM refused to activate because it couldn’t guarantee it wasn’t about to corrupt something.

The engineer didn’t “force” anything. They fixed multipath so only the mapper devices were used, then adjusted LVM filters to ignore raw /dev/sd* paths for that SAN. Activation succeeded. No data loss. No heroics.

The day was saved by two practices: always capture the real error string, and always diff working vs failing nodes before touching production settings. It’s boring. It’s also how you keep your weekends.

Checklists / step-by-step plan

Checklist A: First 10 minutes (stop the bleeding)

1. Run pvesm status and identify the failing storage ID(s) and type(s).
2. Check task logs and journal for the underlying error: journalctl -u pvedaemon -u pvestatd -u pve-storage.
3. For NFS/CIFS: verify mount presence with findmnt and responsiveness with a timeout read.
4. For LVM: verify VG/LV visibility with vgs/lvs.
5. If it’s only one node: compare with a working node before changing anything.

Checklist B: NFS step-by-step

1. Confirm Proxmox config: pvesm config <storageid>.
2. Check current mount: findmnt <path>.
3. Check export visibility: showmount -e <server>.
4. Manual mount with explicit version: mount -t nfs -o vers=4.1 ....
5. Test I/O: create and delete a small file under the mountpoint.
6. If you see stale handles: remount and coordinate with the NFS server owner about maintenance/failover behavior.

Checklist C: CIFS step-by-step

1. Confirm Proxmox config and mount path.
2. Verify credentials file exists and is 600.
3. Manual mount with explicit vers= and sec= options.
4. Check kernel logs for CIFS return codes: dmesg | tail.
5. Verify write permissions by creating a file as root on the mountpoint.
6. After fixing, restart Proxmox storage view by re-checking pvesm status; don’t rely on the GUI cache.

Checklist D: LVM step-by-step

1. Check VG existence: vgs. If missing, look at block layer (disks/iSCSI/multipath).
2. Check LV/thin pool status: lvs -a -o +devices.
3. Attempt activation: vgchange -ay <vg>.
4. If you suspect duplicates: pvs -o+pv_uuid and fix multipath/LVM filters.
5. Check thin pool usage; if metadata is full, fix that before you create more volumes.
6. Once stable, validate persistence across reboot (boot ordering, service dependencies).

FAQ

1) Why does Proxmox say “unable to activate storage” without details?

Because it’s a wrapper error from the storage plugin layer. The real detail is in the task output and system logs. Always check journalctl and Proxmox task logs.

2) Can I just reboot the node to fix activation issues?

Sometimes, but it’s a lousy habit. Reboots can mask boot-order races (iSCSI/multipath) and make intermittent NFS issues harder to diagnose. Reboot only after you’ve captured the error string.

3) NFS mount is present but Proxmox still reports inactive—how?

If the mount is stale or unresponsive, Proxmox may mark it offline because stats calls time out or return errors. Use a timeout read test to detect hangs.

4) What’s the fastest way to tell LVM vs NFS vs CIFS is the problem?

pvesm status tells you the storage type. Then validate OS-level state: findmnt for NFS/CIFS, vgs/lvs for LVM.

5) Should I use CIFS for VM disks?

In production, I avoid it for VM disks. CIFS semantics and latency variability can produce unpleasant edge cases. Use it for ISO/backup storage if you must, and test failure behavior.

6) What does “stale file handle” mean, operationally?

The client references a server-side object that no longer exists in the same identity. It usually happens after server-side filesystem changes or failover. Remount is often required; preventing it requires consistent export backing behavior.

7) My LVM VG is missing after reboot, but the disk is there. Why?

LVM may be filtering the device, or it may see it under a different path than expected. Multipath can also present duplicates. Verify with pvs and standardize device naming.

8) What’s the safest way to fix a hung NFS mount?

First restore network/server availability if possible. Then unmount and remount. Be careful: processes can hang in D-state; forced unmounts can be disruptive. Prefer planned remounts during a controlled window if VM I/O is involved.

9) Why does one Proxmox node mount CIFS but another can’t?

Different installed packages, different DNS, different time sync (Kerberos), or different kernel/module behavior. Compare mount options and check dmesg return codes on both nodes.

10) How do I prevent this from happening again?

Make mounts and LVM activation deterministic: pin protocol versions, enforce service ordering (iSCSI/multipath before LVM), monitor mount responsiveness, and document the storage dependencies like they matter—because they do.

Conclusion: next steps that prevent the sequel

“Unable to activate storage” is Proxmox telling you the backend failed a basic reality check. Treat it that way. Identify the storage ID, validate OS-level truth, then use logs to pinpoint the underlying error string. Fix the backend, not the UI.

Next steps that pay off:

• Write a one-page runbook for your environment with the exact storage IDs, mountpoints, and expected NFS/CIFS options.
• Standardize mounts: explicit NFS version, explicit SMB dialect/security, consistent paths under /mnt/pve.
• Make boot ordering explicit when storage depends on iSCSI/multipath, so LVM activation doesn’t race the universe.
• Monitor the right thing: mount responsiveness (not just “is it mounted”), thin pool metadata usage, and recurring kernel mount errors.

Do that, and the next time Proxmox complains, it’ll be a five-minute fix instead of an afternoon of ritual rebooting and blame roulette.