Proxmox storage “not available on node”: why it exists but you can’t use it

November 21, 2025 • February 3, 2026 • Read: 22 min • Views: 12

Was this helpful?

You open the Proxmox GUI, see your storage nicely listed, and then—bam—“not available on node.” The storage is there, like a reserved parking spot with a traffic cone on it. You can’t use it, migrations fail, backups stall, and your next maintenance window starts to look like a hostage negotiation.

This error is Proxmox being blunt: the cluster config knows about a storage ID, but this node can’t access it right now (or is not supposed to). The trick is separating “definition exists” from “storage is reachable, mounted, authenticated, and supports the requested operation.” That separation is where most outages live.

What “not available on node” actually means

In Proxmox VE, storage definitions are cluster-scoped configuration objects, stored in /etc/pve/storage.cfg (a file served via Proxmox’s cluster filesystem). When you define a storage called fast-nfs, Proxmox remembers it everywhere. That doesn’t mean every node can actually use it. Proxmox distinguishes between:

Storage definition exists: the ID is present in the config and appears in the UI.
Storage is active on a node: the node can reach the backend (mount exists, pool imported, Ceph healthy, auth works, path exists, permissions correct).
Storage supports requested content: you’re trying to put VM disks on a storage that only accepts ISO/templates, or vice versa.
Storage is allowed on the node: the storage is restricted by “nodes” setting, or the node name doesn’t match what the config expects.

The message “not available on node” is Proxmox’s way of saying: for this node, the activation check failed or the storage is deliberately excluded. Proxmox often has enough information to show the storage in the list, but not enough working plumbing to perform operations safely.

The common root categories

Most cases fall into one of these buckets:

Scope / targeting issues: storage is configured for a subset of nodes, or node name mismatch after reinstall/rename.
Mount/path issues: NFS/CIFS not mounted, mountpoint missing, wrong path, fstab not persistent, systemd ordering problems.
Auth/permissions: Ceph keyrings, SMB credentials, NFS export permissions, Unix ownership/mode problems.
Backend not healthy: Ceph degraded/down, ZFS pool not imported, LVM VG missing, iSCSI session dead, multipath broken.
Content and format mismatch: trying to store images on dir without proper format, or using local storage for HA migration assumptions.

Proxmox storage is not magic. It’s a set of adapters around Linux storage primitives, and Linux is very literal. If your node cannot mount it, import it, log into it, or see it, Proxmox won’t pretend.

Joke #1: Storage is like a coffee machine: everyone notices when it’s down, and nobody remembers who installed it.

Fast diagnosis playbook (first/second/third)

If you’re on-call, you don’t want a philosophy lecture. You want the shortest path to “is this a config restriction, a mount issue, or a backend outage?” Here’s the order that minimizes wasted time.

First: confirm whether it’s intentionally excluded

Is the storage restricted to certain nodes in storage.cfg?
Does the node name match the config (especially after reinstall)?
Are you in a split-brain / cluster comms issue where /etc/pve differs?

If excluded, the fix is configuration, not infrastructure.

Second: confirm the OS can see/mount/import the backend

NFS/CIFS: is it mounted? Is DNS resolving? Can the kernel reach the server?
ZFS: is the pool imported? Any I/O errors?
LVM: does the VG exist? Are PVs present?
Ceph: does ceph -s look healthy? Do we have monitors/quorum?
iSCSI: are sessions logged in? Multipath healthy?

If the OS can’t use it, Proxmox can’t either. Don’t debug Proxmox until Linux works.

Third: confirm content types and path expectations

Does storage allow images, rootdir, backup, etc.?
For dir storage: does the directory exist and is it writable by root?
For file-based storage: is there space? Are inodes exhausted?

This is where “it mounts fine” still fails because Proxmox refuses to place VM disks on an ISO-only storage, or because the path is read-only.

Storage types and their specific failure modes

Dir storage (local directory, NFS mounted to a directory, etc.)

Why it fails: missing mountpoint, wrong mount options, read-only mount, permission issues, path mismatch, stale NFS handles, or the directory exists but is on the wrong filesystem (you thought it was NFS; it’s actually local root).

What Proxmox checks: that the path exists, is accessible, and that the node is allowed. It won’t sanity-check that you mounted the “right” thing—so you must.

NFS storage

Why it fails: export permissions, firewall, DNS, server down, client stuck in “soft” mount misery, or systemd mounts not ready at boot. NFS failures are often “available” right up until they’re not, because cached metadata masks problems.

Operational opinion: use hard mounts for VM disks, but understand that hung I/O will hang processes. That’s the trade: data integrity vs. availability. For backups, you can be more flexible.

CIFS/SMB storage

Why it fails: credentials expired/rotated, SMB dialect mismatch, AD issues, or the mount helper not installed. Also: Windows fileservers love “helpful” changes.

What breaks quietly: the mount may exist but is actually disconnected; you only discover it when writes start failing.

ZFS (local)

Why it fails: pool not imported after reboot, device renaming, missing by-id paths, degraded pool with I/O errors, or you created the pool on one node and expect it on another (that’s not shared storage; that’s optimism).

HA reality: local ZFS is great. It is not shared storage. If you want live migration without shared storage, you need replication or Ceph—and you need to accept the operational cost.

LVM / LVM-thin (local block)

Why it fails: missing VG because disk not present, PV UUID change, filter rules in lvm.conf, or activation issues. Thin pools also fail in exciting ways if metadata fills up.

Ceph (RBD/CephFS)

Why it fails: monitors not in quorum, OSDs down, networking issues, mismatched keyrings, wrong ceph.conf path, or you’re pointing a node at the wrong cluster name/fSID. Ceph also fails when “mostly healthy” but slow: you can see availability but not usability.

Opinion: Ceph is wonderful when you run it like a product, not a side quest.

iSCSI (often with LVM on top)

Why it fails: sessions drop, CHAP mismatch, multipath misconfigured, LUN IDs change, or you forget persistence across reboot. iSCSI tends to fail at 02:00, because of course it does.

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

These are the production-grade checks I run when “storage not available on node” appears. Each task includes (a) a command, (b) what typical output means, and (c) the decision you make next. Run them on the affected node first.

Task 1: Ask Proxmox what it thinks is active

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active        102334976       22110208        75053056    21.61%
fast-nfs         nfs      inactive               0              0               0     0.00%
ceph-rbd         rbd      active                0              0               0     0.00%

Meaning: Proxmox storage manager (pvesm) declares fast-nfs inactive on this node. That’s the canonical signal: Proxmox can’t activate it.

Decision: move to mount/backend checks. If the status is active but GUI says unavailable, suspect node restrictions or cluster config inconsistency.

Task 2: Confirm the storage definition and node restrictions

cr0x@server:~$ grep -A5 -n "nfs: fast-nfs" /etc/pve/storage.cfg
27:nfs: fast-nfs
28:        export /exports/proxmox
29:        path /mnt/pve/fast-nfs
30:        server 10.20.30.40
31:        content images,backup,iso
32:        nodes pve01,pve02

Meaning: This storage is explicitly limited to pve01,pve02. If you’re on pve03, it will be “not available” by design.

Decision: either add the node to the list (if it should access it) or stop trying to use it from this node.

Task 3: Verify the node name Proxmox uses

cr0x@server:~$ hostname
pve03

Meaning: Node name is pve03. If storage.cfg says pve3 or the old hostname, restrictions won’t match.

Decision: fix storage node list or correct hostname consistently (host rename in Proxmox is non-trivial; prefer fixing config).

Task 4: Check if the mountpoint exists and what filesystem it is

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

Meaning: It’s mounted and it’s actually NFS4 from the expected server/export. Good sign.

Decision: if findmnt shows nothing, mount is missing; if it shows ext4 or zfs, you mounted the wrong thing or didn’t mount at all.

Task 5: If it’s missing, check systemd mount and fstab ordering

cr0x@server:~$ systemctl status mnt-pve-fast\\x2dnfs.mount
● mnt-pve-fast\x2dnfs.mount - /mnt/pve/fast-nfs
     Loaded: loaded (/etc/fstab; generated)
     Active: failed (Result: exit-code) since Fri 2025-12-26 07:12:20 UTC; 3min ago
      Where: /mnt/pve/fast-nfs
      What:  10.20.30.40:/exports/proxmox
      Docs:  man:fstab(5)
             man:systemd-fstab-generator(8)
    Process: 1442 ExecMount=/usr/bin/mount 10.20.30.40:/exports/proxmox /mnt/pve/fast-nfs (code=exited, status=32)

Meaning: The mount unit failed; status 32 usually means mount failure (network, permission, server).

Decision: check network reachability and NFS export permissions next.

Task 6: Verify network reachability and name resolution

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.462 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=0.417 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1012ms
rtt min/avg/max/mdev = 0.417/0.439/0.462/0.022 ms

Meaning: Basic connectivity is fine. This does not prove NFS works, but it eliminates “the server is gone” quickly.

Decision: check TCP/UDP ports and export access.

Task 7: Query NFS exports from the client side

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

Meaning: Export exists and is offered to your subnet. If your node is in another subnet/VLAN, you just found your problem.

Decision: if the export list is empty or access denied, fix server-side NFS exports/firewall.

Task 8: Try a manual mount with verbose errors

cr0x@server:~$ mount -v -t nfs4 -o vers=4.2 10.20.30.40:/exports/proxmox /mnt/pve/fast-nfs
mount.nfs4: timeout set for Fri Dec 26 07:17:40 2025
mount.nfs4: trying text-based options 'vers=4.2,addr=10.20.30.40,clientaddr=10.20.30.53'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting 10.20.30.40:/exports/proxmox

Meaning: Classic: network is fine, export exists, but server denies this client (wrong export rules, root_squash issues combined with expectations, or missing host allowlist).

Decision: adjust exports on the NFS server; Proxmox config changes won’t help.

Task 9: Confirm the directory is writable and not lying to you

cr0x@server:~$ touch /mnt/pve/fast-nfs/.pve-write-test && echo "ok" || echo "fail"
ok

Meaning: The mount is writable as root (or at least this write succeeded). If it fails with “Read-only file system” or “Permission denied,” Proxmox will have a bad day.

Decision: fix mount options, server export permissions, or underlying filesystem health.

Task 10: Check permissions/ownership for dir storage paths

cr0x@server:~$ ls -ld /mnt/pve/fast-nfs
drwxr-xr-x 9 root root 4096 Dec 26 07:11 /mnt/pve/fast-nfs

Meaning: Root has access. That’s typically sufficient because Proxmox storage operations run as root. If you see weird ownership due to squashing or ACLs, expect failures creating subdirs like dump or template.

Decision: ensure the NFS export and filesystem permissions allow root writes (or align to Proxmox’s expectations with proper UID/GID mapping).

Task 11: Verify content types match what you’re trying to do

cr0x@server:~$ pvesm config fast-nfs
content images,backup,iso
export /exports/proxmox
path /mnt/pve/fast-nfs
server 10.20.30.40
type nfs

Meaning: This storage permits VM disk images, backups, and ISOs. If your failure was “unable to create CT volume,” you might be missing rootdir.

Decision: adjust content appropriately. Don’t over-permit content types unless you actually want them there (it reduces guardrails).

Task 12: Look for Proxmox logs that explain activation failures

cr0x@server:~$ journalctl -u pvedaemon -u pve-storage -n 80 --no-pager
Dec 26 07:12:21 pve03 pvedaemon[1321]: storage 'fast-nfs' is not online
Dec 26 07:12:21 pve03 pvedaemon[1321]: mount error: permission denied for 10.20.30.40:/exports/proxmox
Dec 26 07:12:22 pve03 pvedaemon[1321]: TASK ERROR: storage 'fast-nfs' is not available on node 'pve03'

Meaning: You get the real reason: mount permission denied. The GUI rarely tells you this cleanly.

Decision: fix the backend. Stop poking at the UI.

Task 13: If it’s ZFS, confirm pool import and health

cr0x@server:~$ zpool status
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          nvme0n1p3 ONLINE       0     0     0

errors: No known data errors

Meaning: Pool is healthy. If your storage is a ZFS pool called tank and it’s not listed, it’s not imported.

Decision: if missing, attempt zpool import and investigate device paths and by-id stability.

Task 14: If it’s ZFS and missing, list importable pools

cr0x@server:~$ zpool import
  pool: tank
    id: 1234567890123456789
 state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          sdb       ONLINE

Meaning: The pool exists but isn’t imported. After reboot, this usually means auto-import didn’t happen or devices arrived late.

Decision: import it (zpool import tank) and then fix boot ordering or device naming to prevent recurrence.

Task 15: If it’s LVM-thin, confirm VG and thinpool presence

cr0x@server:~$ vgs
  VG         #PV #LV #SN Attr   VSize    VFree
  pve          1   2   0 wz--n-  930.00g  10.00g

Meaning: The VG exists. If Proxmox says LVM storage unavailable and vgs shows nothing, the disk/VG isn’t present or filtered out.

Decision: check pvs, disk visibility, and /etc/lvm/lvm.conf filters.

Task 16: If it’s Ceph, check cluster health quickly

cr0x@server:~$ ceph -s
  cluster:
    id:     2f1d3b0a-6f6d-4a7b-a6b3-9a7b4a0d1c2e
    health: HEALTH_WARN
            1 mons down, quorum mon1,mon2
  services:
    mon: 3 daemons, quorum mon1,mon2
    osd: 9 osds: 9 up, 9 in
  data:
    pools:   3 pools, 128 pgs
    usage:   2.1 TiB used, 4.9 TiB / 7.0 TiB avail
    pgs:     128 active+clean

Meaning: Ceph is mostly fine; a mon is down but quorum exists and PGs are clean. Proxmox should generally still use RBD.

Decision: if health is HEALTH_ERR, or you see many PGs not active+clean, treat it as backend incident, not Proxmox UI drama.

Task 17: Confirm Proxmox can list volumes on the storage

cr0x@server:~$ pvesm list fast-nfs | head
Volid                             Format  Type              Size VMID
fast-nfs:iso/debian-12.iso        iso     iso           657457152    0
fast-nfs:backup/vzdump-qemu-100.vma.zst vma.zst backup  1812034560  100

Meaning: If listing works, storage is at least reachable and readable. If listing fails with an error, it often includes the specific backend failure.

Decision: if list works but create fails, suspect permission, space, content types, or locking issues.

Task 18: Check disk space and inodes (yes, inodes)

cr0x@server:~$ df -h /mnt/pve/fast-nfs && df -i /mnt/pve/fast-nfs
Filesystem                         Size  Used Avail Use% Mounted on
10.20.30.40:/exports/proxmox       20T   19T  800G  96% /mnt/pve/fast-nfs
Filesystem                         Inodes  IUsed   IFree IUse% Mounted on
10.20.30.40:/exports/proxmox       120M    119M    1M   99% /mnt/pve/fast-nfs

Meaning: Space is tight, but inodes are basically gone. That can break backups, ISO uploads, and container storage in ways that look like permission errors.

Decision: clean up, expand filesystem, or reduce tiny-file churn. If inodes are near 100%, treat it as full.

Common mistakes (symptom → root cause → fix)

These are not “theory mistakes.” These are the ones that keep recurring because they feel reasonable in the moment.

1) Storage appears in UI, but on one node it’s “not available”

Symptom: Storage listed cluster-wide; only one node can’t use it.

Root cause: node restriction in storage.cfg or hostname mismatch (node reinstalled with different name).

Fix: update nodes setting for that storage or correct the node identity consistently. Verify with pvesm status on each node.

2) NFS storage “works” until reboot, then becomes unavailable

Symptom: After reboot, Proxmox says storage unavailable; manual mount fixes it.

Root cause: mount not persistent or starts before network; missing _netdev or systemd ordering; sometimes DNS not ready.

Fix: ensure fstab has _netdev, consider systemd mount units, and verify with systemctl status mnt-pve-*.mount. Keep mounts deterministic.

3) “Permission denied” on mount even though export exists

Symptom: showmount -e shows export, but mount fails with access denied.

Root cause: export rules don’t include the node IP, or NFSv4 idmapping expectations differ, or firewall blocks NFS-related ports.

Fix: correct server export allowlist, confirm NFS version, and validate from the client with a verbose mount attempt.

4) Storage is mounted, but Proxmox still says unavailable

Symptom: findmnt shows mount, but pvesm status shows inactive.

Root cause: Proxmox expects the storage at /mnt/pve/<storageid> but you mounted it elsewhere, or the path in storage.cfg is wrong, or the mount is stale/hung.

Fix: align the path with the actual mountpoint; check for stale NFS with a simple ls that hangs; remount if necessary.

5) VM disks won’t create on storage, but ISOs upload fine

Symptom: ISO content works, but creating a disk fails.

Root cause: missing images in content, or storage type doesn’t support the requested format.

Fix: add appropriate content types, or move disks to block storage (LVM/RBD) if you need certain semantics.

6) Ceph storage “not available” only on one node

Symptom: Two nodes can use RBD; one cannot.

Root cause: missing Ceph packages, missing keyring, wrong ceph.conf, or network path to monitors blocked on that node.

Fix: validate ceph -s on that node; compare /etc/ceph and keyrings; confirm firewall rules and monitor reachability.

7) LVM-thin storage disappears after “cleanup”

Symptom: LVM-based storage inactive; vgs empty.

Root cause: someone removed/changed a disk, modified LVM filters, or switched device naming without stable IDs.

Fix: restore disk visibility, use stable by-id paths where possible, and keep LVM filters conservative and explicit.

Checklists / step-by-step plan

Checklist A: Single-node “storage not available” triage (10 minutes)

Run pvesm status. Identify which storage IDs are inactive on that node.
Check /etc/pve/storage.cfg for nodes restriction and path settings.
Verify the node name with hostname and compare to config.
If file-based storage: verify mount exists with findmnt.
Test basic I/O: ls and touch in the storage path (watch for hangs).
Check logs: journalctl -u pvedaemon -u pve-storage for explicit errors.
If NFS/CIFS: test manual mount with verbose output.
If Ceph: ceph -s on that node and verify keyrings exist.
If ZFS/LVM: verify pool/VG visibility and health.
Only after the OS-level checks pass: re-check Proxmox GUI and attempt the operation again.

Checklist B: Cluster-wide sanity check (30–60 minutes, prevents repeats)

On every node: run pvesm status and compare outputs.
Validate that every shared storage has the same mount semantics everywhere (same path, same options).
Standardize node networking assumptions: VLANs, firewall rules, DNS, MTU, routing.
For NFS: ensure exports explicitly include all Proxmox nodes; avoid “works from one subnet” surprises.
For Ceph: ensure each node has correct /etc/ceph configs and keyrings; verify monitor reachability.
Review content types per storage: keep them tight. “Everything everywhere” becomes “everything broken everywhere.”
Add a post-reboot validation step in your change process: mounts imported, VGs active, Ceph OK.

Checklist C: Before enabling HA or scheduling migrations

Identify which workloads require shared storage (true HA, live migration without downtime).
Confirm that storage is accessible from every node that might run those workloads.
Test a live migration and a storage migration during business hours with a rollback plan.
For local storage workloads, explicitly design replication/backup paths and document the limits.

Three corporate-world mini-stories

Mini-story 1: The incident caused by a wrong assumption

They had a tidy three-node Proxmox cluster and a single NFS server. The storage was defined once, visible everywhere, and the team assumed that meant “shared.” It mostly worked—until the first emergency.

A host started throwing ECC errors. The on-call did the right thing: evacuate VMs to the remaining nodes. But several VMs refused to migrate. The UI helpfully said the target node couldn’t use the storage. Confusing, because the storage was “there.”

The root cause wasn’t Proxmox being flaky. The NFS server exported the share only to a specific subnet, and one of the Proxmox nodes lived on a different VLAN due to a past “temporary” network change. The storage definition existed, but the node was never actually authorized.

The fix was boring: update the NFS export allowlist, align network placement, and add a simple “test mount + touch file” check as part of node commissioning. After that, migrations worked—and the team stopped treating the GUI as proof of reality.

They also learned the harsh truth: cluster-visible configuration is not the same thing as cluster-accessible infrastructure. That’s a distinction you only forget once.

Mini-story 2: The optimization that backfired

A different company wanted faster VM disk performance, so they “optimized” NFS mount options. They switched to aggressive timeouts and added options intended to reduce hangs under packet loss. On paper, it sounded responsible: avoid stuck processes, keep the node responsive.

The first few weeks looked fine. Then a routine network maintenance caused a brief interruption—seconds, not minutes. After that, a subset of VMs started logging filesystem errors. Backups began failing inconsistently. Some operations reported storage unavailable, others partially completed. The failure pattern was theatrical and hard to reproduce.

The culprit was the mount behavior under transient failure. The mount options turned a temporary blip into application-visible errors. For VM disks, that’s not a “small inconvenience.” It’s a data-integrity event with paperwork attached.

They reverted to safer mount semantics for disk workloads and split usage: one NFS path for backups (where occasional retries are acceptable) and a different storage backend for VM disks. The optimization had been a clever idea applied to the wrong problem.

Joke #2: Nothing says “high availability” like tuning timeouts until your storage becomes Schrödinger’s filesystem.

Mini-story 3: The boring but correct practice that saved the day

Another team ran Ceph-backed RBD storage for VM disks and a separate NFS share for backups. They also had a habit that looked painfully dull: after every Proxmox update or node reboot, they ran a short, repeatable validation script—pvesm status, a small RBD create/delete test, and a backup write test to NFS.

One morning, a node rebooted after a kernel update and came back with its firewall rules subtly different due to a configuration management drift. The node joined the cluster and looked healthy in the GUI, but RBD operations failed and the storage showed as unavailable only on that node.

Because they ran the validation immediately, they caught it before the scheduler moved workloads there. No late-night surprise migrations, no half-dead VMs, no confusing “it works on node A” tickets. Just a controlled fix: restore the correct firewall rules for Ceph monitor access, re-check, and move on.

This is the unglamorous truth: reliability is mostly practicing the same small checks until you’re tired of them, and then practicing them again. It feels slow. It’s faster than outages.

Interesting facts and a bit of history (that actually helps)

Fact 1: Proxmox stores cluster-wide config in a special filesystem under /etc/pve, backed by a database-like replication mechanism. That’s why storage IDs appear everywhere quickly.
Fact 2: The mountpoints under /mnt/pve are conventionally managed by Proxmox storage plugins; mismatching the path is a common self-inflicted wound.
Fact 3: NFS has been around since the 1980s, and it still powers modern virtualization stacks because it’s simple, debuggable, and “good enough” when designed carefully.
Fact 4: The industry shift from file-based VM disks to block-backed disks (LVM, RBD, iSCSI) happened largely because of latency predictability and locking semantics under contention.
Fact 5: Ceph became popular in virtualization because it offers shared block storage without a traditional SAN, but it trades hardware simplicity for operational complexity.
Fact 6: “Storage is defined” vs. “storage is mounted” mirrors a classic systems divide: control plane vs. data plane. Many outages are one plane lying to the other.
Fact 7: Inode exhaustion is a real production failure mode on backup-heavy NFS shares, especially when retention policies produce many small files.
Fact 8: Hostname consistency matters in clusters because identity shows up in access control, node targeting, certificates, and sometimes in storage allowlists. Renames are rarely “just cosmetic.”
Fact 9: Systemd’s mount unit generation from /etc/fstab can change boot ordering behavior in ways that surprise people used to older init systems.

One reliability quote you should actually internalize

Paraphrased idea, attributed to John Allspaw: you don’t get reliability by blaming people; you get it by improving the system that made failure possible.

When storage is “not available on node,” resist the urge to hunt for a person. Hunt for the assumption the system allowed to exist.

FAQ

1) Why does storage show up in the GUI if it’s unusable?

Because the GUI is showing cluster configuration objects. The storage ID exists in /etc/pve/storage.cfg. Availability is node-specific and depends on mounts, devices, auth, and health.

2) Is “not available on node” always a real outage?

No. It can be deliberate: the storage is restricted to certain nodes via the nodes option. But if it’s supposed to be shared, treat it as a production incident until proven otherwise.

3) What’s the quickest way to see the real error behind the GUI message?

Check logs on the affected node: journalctl -u pvedaemon -u pve-storage. It often contains the underlying mount/auth/backend error.

4) Can I fix it by restarting Proxmox services?

Sometimes it masks transient issues, but it’s usually the wrong first move. If the OS can’t mount or see the backend, restarting services just replays the failure with more confidence.

5) Why does it happen only after reboot?

Boot ordering and persistence. Network may not be ready when mounts start, ZFS pools may not auto-import due to device timing, iSCSI sessions may not auto-login, or firewall rules change on reboot.

6) I can `ping` the NFS server, so why is storage still unavailable?

Ping proves almost nothing beyond ICMP reachability. NFS needs working RPC services, correct exports, correct authentication, and open ports. Use showmount -e and a verbose mount -v.

7) For HA and live migration, do I need shared storage?

For live migration without storage migration, yes. Otherwise you need a strategy: replication (ZFS replication), storage migration downtime, or a distributed storage backend (Ceph). Pick one intentionally.

8) Why does Proxmox say a storage is active but operations still fail?

“Active” can mean it mounted and basic checks passed. Operations can still fail due to permission issues on subdirectories, full inodes, read-only remounts, stale NFS handles, or content type restrictions.

9) Is it safe to put VM disks on NFS dir storage?

It can be, if engineered correctly (stable network, appropriate mount options, proper server configuration, and realistic expectations). But if you want consistent low latency and fewer edge cases, block storage (Ceph RBD, LVM on SAN) tends to behave better under contention.

10) How do I prevent this class of problem from recurring?

Standardize node commissioning: verify mounts/imports, verify storage activation with pvesm status, and test a read/write operation. Then automate it as a post-reboot check.

Conclusion: next steps that work in production

“Not available on node” is a precision message wearing a vague coat. The storage definition exists; the node can’t activate it—or isn’t allowed to. Your job is to stop guessing and prove which layer is broken: config scoping, OS-level access, or backend health.

Do this next, in order:

Run pvesm status on the affected node and confirm what’s inactive.
Check /etc/pve/storage.cfg for nodes restrictions and correct paths.
Validate the backend from Linux: mounts, pools, VGs, Ceph health, iSCSI sessions.
Use logs to find the real error string and fix the backend, not the UI.
After fixing, validate by listing storage content and doing a small write test.
Institutionalize the boring check: post-reboot storage validation on every node.

If you want fewer 02:00 surprises, treat storage like a first-class production system: explicit node access, consistent paths, deterministic mounts, and health checks that run when nobody is watching.