Proxmox Backup to NAS: NFS vs SMB Setup and Restore Checklist

Preparation date: September 17, 2026. Scope: This is a documentation-based implementation and verification guide, not a claim about a completed customer incident. It covers ordinary Proxmox VE VZDump backups written to NAS storage. A Proxmox Backup Server datastore is a different architecture and is called out separately. The short answer is: choose NFS when Proxmox is the main consumer and your NAS can restrict the export to the Proxmox node addresses. Choose SMB/CIFS when the same share must also fit a Windows-oriented operating model or your NAS administration is already built around named users and SMB permissions. The protocol choice matters, but the restore test matters more. A green backup task proves that an archive was written; it does not prove that you can recover a VM on replacement storage. Proxmox backup to NAS verification flow A Proxmox node writes a VZDump backup over NFS or SMB to a NAS, then a separate restore test validates recovery. ...
Post a Comment

Horizon Login Loops After Maintenance: Reconstruct the UAG Access Chain

Documentation-based investigation guide. Revised September 12, 2026. The original narrative did not include an attributable maintenance record or logs. Its topology and recovery story are not presented here as verified firsthand events.

A login loop after maintenance needs a timeline, not another full-stack reboot. The question is which part of the access transaction first stops behaving as expected. Restarting a gateway may restore availability while leaving that question unanswered.

Build one transaction record

For one approved test account, record the timezone, client build, entry FQDN, last successful screen, selected UAG, selected Connection Server, and whether a desktop was allocated. Correlate the test with gateway, authentication, broker, and load-balancer records. Remove account identifiers, tokens, OTP values, and shared secrets before circulating evidence.

Do not assume every deployment uses the same order of disclaimer, RADIUS, and AD authentication. Describe the configured sequence and identify the first failed transition. An accepted OTP is not proof that desktop brokering or the display connection succeeded.

Separate three investigations

  • Authentication did not finish: compare authentication responses and timeouts for the chosen path. Avoid repeated failed attempts that could lock the account. Do not bypass MFA to manufacture a successful test.
  • Authentication finished but no resource launched: correlate entitlement and broker events with the gateway request. Check actual readiness after maintenance rather than relying on uptime alone.
  • A resource was assigned but the display failed: trace the advertised display endpoint and selected UAG. Omnissa documents the requirement for primary and secondary connections to reach the same UAG in the applicable architecture.

Compare nodes without changing the trust model

Ask the load-balancer owner to route an approved pilot to one member while preserving the intended hostname, certificates, authentication, and display routing. Record existing sessions and spare capacity before draining a node. A raw-IP connection that triggers a certificate warning is not an equivalent test; do not disable validation to proceed.

Repeat with the other member using the same client and resource. If the problem follows one member, compare that member's settings and logs. If it follows neither reliably, retain the selection records and investigate shared dependencies. A healthy probe alone does not demonstrate that the entire user transaction works.

Recovery and post-maintenance acceptance

Preserve diagnostic bundles before an approved service restart or appliance restart. Verify session impact, recovery access, and the previous configuration. Change one component at a time; document when access recovered without naming an unproven mechanism.

Before closing maintenance, test fresh login, resource launch, reconnect, and normal member distribution. Set the observation window from the previous recurrence pattern and expected usage—not an invented universal duration. If failures return, restore the last safe routing configuration and escalate with the correlated transaction record. This guide does not establish a mandatory boot order or a universal reboot fix.

References

Related troubleshooting guides

Comments

Post a Comment

Popular posts from this blog

Horizon vdpConnect_Failure: Connection-Stage Triage Before Reinstalling

vdpConnect_Failure is a starting symptom, not a root-cause diagnosis. Before reinstalling Horizon Agent or opening firewall ports, establish whether the failure occurs during authentication, desktop launch, or an established session. This documentation-based triage guide does not report a reproduced incident or a universal fix. Corrected September 12, 2026: The earlier guide suggested restarting the Windows RPC service and treated a local netstat listing as a test for blocked ports. Those instructions have been removed. A socket listing does not demonstrate end-to-end reachability. Classify the failure before making changes Observation First evidence to collect Avoid assuming Authentication never completes Exact login error, identity provider or broker event, timestamp That the display protocol is the failing component. Desktop selection succeeds, launch fails Assigned desktop, chosen protocol, Client/Agent and gateway logs That a successful HTTPS login proves the session path ...
Read more

Horizon Agent Unreachable: Registration and Desktop-Health Triage

Start an “Agent Unreachable” investigation by separating desktop health, Agent registration, and session traffic. Do not begin with a pool rebuild. This documentation-based triage guide helps decide which team should act and what evidence to preserve. Correction, September 12, 2026: The earlier guide mixed display ports with Agent communication, tested Blast against the Connection Server, and offered generic service restarts and image rebuilds. Those instructions have been replaced with path-specific investigation. First-response decision table Check Evidence Investigation owner Is the guest responsive? Approved console access, OS health, resource and disk observations Desktop/virtualization team if the OS is unavailable. Is this one desktop or a whole image family? Affected pool, image revision, Agent version, start time Image owner if failures align with a deployment. Does registration fail? Agent and Connection Server events for the same desktop and time Horizon team, then netw...
Read more

Horizon Protocol Error: Trace the Display-Session Handoff

A desktop can authenticate successfully and still fail to establish its display session. This guide investigates that handoff. Use it after identifying the actual console/client error, not as a claim that every “Protocol Error” means a firewall failure. Correction, September 12, 2026: The previous version combined a general checklist with an unverified incident narrative, conflated gateway and desktop port directions, and recommended blanket endpoint-security exclusions. Those instructions have been removed. This is a documentation-based diagnostic plan. Draw the attempted connection Record the selected protocol, assigned desktop, Client and Agent versions, gateway route, and attempt time. Distinguish a direct internal connection from an external UAG connection or a Connection Server tunnel. Use Omnissa's connection guide to identify where the failed handoff occurs. Stage Question Useful comparison Authentication Did the user receive desktop entitlement? Failed login versus ...
Read more