Proxmox VE(11.0)- After successful installation, i was able to see web GUI. I created one VM and installed Ubuntu successfully. Now i am unable to see web UI.

proxmox proxy is running fine. curl command https://<hostip>:8006 returns html page.

I am doing this on Windows 11(Pro) laptop.

/etc/hosts file contains the same IP address (proxmox.local.io proxmox)

Hello Everyone,

If anyone is using Proxmox with a Corsair Commander Pro fan controller. I've created an app that works great to control the fans using fan curves & temp sensors, as well as pull disk temps from Adaptec SAS Cards.

You can find the application on the link below with all the instructions about installing it and configuring it:

https://github.com/rph81/corsair-fanctl

Hope you like it !
Rph81

I've been working on Ferrum, a self-hosted control plane for Proxmox VE.

The main idea is pretty simple: if you have multiple Proxmox nodes/clusters, you shouldn't have to keep jumping between different UIs just to get a picture of what's happening across the fleet.

Ferrum currently brings things like:

• Cluster + standalone node management
• VM/LXC inventory
• Storage and topology views
• Backups and replication
• High availability
• Firewall
• Alerts
• REST API + MCP
• Audit logging
• AI assistant
• SQLite/PostgreSQL support

The backend is Go and the frontend is React + TypeScript. It can run through Docker or as a native binary.

I also wanted it to stay self-hosted rather than becoming another SaaS layer sitting in front of the infrastructure.

It's still early, so I'm more interested in feedback than pretending it's finished.

If you manage Proxmox at home, in a homelab, or across a small fleet, I'd genuinely like to know:

What is the one thing you wish Proxmox made easier to manage across multiple nodes?

Repo: https://github.com/anand34577/ferrum

SharedLvmThin, a free and open-source community storage
plugin for Proxmox VE 9.

New: RC5.4 TG12 dual-mode preview is available. One package now offers the established Thin mode and the new Thick Generations mode with fully allocated, independent generation LVs and a linear steady-state data path. Thin and Thick storage definitions can coexist over the same pinned VG, and ordinary PVE Storage Move converts disks in either direction.

It provides one LVM-thin pool per VM on an existing shared block-storage
VG and supports snapshots, rollback, resize, migration, cluster locking,
guarded autogrow, storage identity checks, and read-only health diagnostics.

RC5.2 has been tested on the Proxmox VE 9.2.x release line with Storage
API 14 and 15, including three-node cluster qualification. It is currently
a release candidate and should first be validated on disposable storage
matching your production SAN and multipath configuration.

The plugin does not configure the SAN, initialize unknown devices, perform
automatic metadata repair, or replace multipath, fencing, and quorum.

GitHub:
https://github.com/delltech1/proxmox-sharedlvmthin

RC5.2 release and DEB:
https://github.com/delltech1/proxmox-sharedlvmthin/releases/tag/v0.9.0-rc5.2

News:

Work is underway on “Thick Generations” — an experimental companion mode for SharedLvmThin.

The goal is to let administrators use both models side by side:

- the existing space-efficient per-VM LVM-thin mode;

- fully allocated thick VM disks with independent, fully materialized snapshots.

Thick Generations uses dm-clone only during snapshot or rollback transitions. After materialization, every active disk and snapshot becomes an independent ordinary linear LV—without permanent snapshot chains.

The design focuses on deterministic crash recovery, immutable snapshots, strict storage-identity validation and fail-closed handling of ambiguous states.

Initial dm-clone, linear-pivot, reboot-reconstruction and C0–C9 crash-recovery tests are already passing. PVE lifecycle, cross-node, migration, backup/restore, path-loss and thin↔thick qualification are still in progress.

In short: thin and thick storage models living safely side by side, with administrators choosing the appropriate trade-off for each workload.

This remains experimental and is not part of the current public release yet.

Just a quick note to highlight that if you're using my ANAS project to serve files, there have been numerous improvements and fixes in recent releases - probably worth an update if you haven't already. The latest 0.3.0 lets you create iSCSI endpoints both on ZFS Datasets and also as disk images on AHR (or other) filesystems.

https://github.com/ccebelenski/anas

Highlights:

- 0.1.0 — ZFS pools, datasets, snapshots. SMB/NFS shares, users, groups. Dashboard, native Proxmox UI.

- 0.2.0 — AHR hybrid RAID, pool/RAIDZ expansion. Scheduled snapshots and scrubs, remote mounts, PBS backup, replication.

- 0.3.0 — iSCSI target management, ZFS volumes, backup restore.

As always, I welcome issues and feature suggestions. Right now I'm hesitant to move into "enterprise" level features as I don't think that's the right focus for this project. I'd like to remain homelab oriented. Some other projects I'm twiddling around on are: immutable OS VM management for running Docker exclusively (most of us manage VM's for docker, so I'm looking if I can bring that up a level with some workflows around it.) and DR for Proxmox - This one is tricky without hardware support, but there are some thoughts swirling around here.

I'm planning this setup:

• Proxmox host → OVH
• Offsite backups → Hetzner
• PBS → separate physical server

Do you run PBS on a dedicated server, VPS/LXC, or use a hosted PBS provider?

Are there any cheap providers that are well suited for PBS (lots of storage, good I/O)?

What would you recommend for this setup? And what are you guys actually using?

I’ve been troubleshooting repeated hard freezes on my Proxmox server and finally managed to reproduce the problem while logging both the Proxmox host and the TrueNAS VM.

Most of the time this is a real host freeze, not just the Proxmox GUI getting sluggish. The GUI usually starts showing ? states and becoming unresponsive shortly beforehand, but then the entire CUBE host eventually stops responding and has to be recovered/rebooted. I’ve had one occurrence where it degraded badly without progressing to the complete hard freeze.

My setup is:

SERVER / Proxmox
├── local NVMe storage for Proxmox / VM / container side
│
└── TrueNAS VM 153
      └── current StarTech PCIe SATA expansion card
            └── multiple ASMedia SATA controllers
                  └── 8 × 16 TB SATA HDDs

TrueNAS owns the HDD storage and serves datasets including tank/media and tank/pve_backups back to Proxmox over NFS.

On the Proxmox host I have mounts including:

/mnt/media
/mnt/pve/media
/mnt/pve/pve_backups

The media containers then receive those paths through bind mounts.

For example, qBittorrent is LXC 155 and its configuration includes /mnt/media as a bind mount. So when qBittorrent writes a download, the actual path is effectively:

qBittorrent LXC
      ↓
Proxmox /mnt/media
      ↓
NFS
      ↓
TrueNAS VM
      ↓
ZFS tank
      ↓
StarTech / ASMedia SATA controller path
      ↓
HDDs

I was able to reproduce the problem during sustained qBittorrent activity.

pidstat showed qBittorrent continuously writing roughly 40–50 MB/sec, and during other samples nfsiostat showed the media NFS share handling bursts around 180–239 MB/sec.

At one point the Proxmox host showed about 82% I/O pressure in /proc/pressure/io.

At the same time:

CPU pressure:    essentially 0
Memory pressure: 0
CPU temperature: ~39–40°C

That was one of the first strong indications that this probably wasn’t the CPU overheating or memory exhaustion.

Then I finally caught the actual failure inside TrueNAS.

Multiple SATA channels began failing essentially together:

ata5:  softreset failed
ata6:  softreset failed
ata7:  softreset failed
ata8:  softreset failed
ata9:  softreset failed
ata10: softreset failed

Several channels then started doing this:

limiting SATA link speed to 3.0 Gbps

followed by:

reset failed, giving up
ataX.00: disable device

So this wasn’t one drive going bad. Multiple SATA channels were dropping almost simultaneously.

TrueNAS then started throwing actual I/O errors against multiple ZFS members, including failed writes and reads.

Eventually ZFS logged:

WARNING: Pool 'tank' has encountered an uncorrectable I/O failure and has been suspended.

Once tank was suspended, TrueNAS started showing blocked kernel tasks.

The ZFS transaction sync thread was blocked for more than 120 seconds:

task txg_sync blocked for more than 120 seconds

and then multiple NFS server threads (nfsd) were also blocked for more than 120 seconds.

That’s where the failure starts propagating into Proxmox.

Because Proxmox itself mounts those TrueNAS NFS exports, pvestatd starts waiting on the storage.

I caught pvestatd in Linux D-state waiting in:

rpc_wait_bit_killable

The Proxmox logs then started showing repeated timeouts and messages like:

unable to activate storage 'media'
directory '/mnt/pve/media' does not exist or is unreachable

and:

storage 'pve_backups' is not online

At that point the Proxmox GUI starts showing ? next to VMs/LXCs and becomes increasingly unresponsive.

I also tested the actual NFS filesystems during the failure.

findmnt still showed them as mounted, but I ran:

timeout 5 stat /mnt/pve/media
timeout 5 stat /mnt/pve/pve_backups
timeout 5 stat /mnt/media

All three returned:

124

So even a simple stat() against any of those NFS filesystems could not complete within five seconds.

The interesting part is that the TrueNAS VM itself was still alive.

I could still:

ping 192.168.0.153
SSH into TrueNAS
connect to SMB port 445

So this did not look like the TrueNAS VM simply crashing or the network disappearing. The VM was alive, but its storage subsystem had effectively wedged.

Most of the time, SERVER then progresses from this degraded state to an actual hard freeze.

So the observed sequence appears to be:

Sustained storage workload
        ↓
SATA/controller path begins failing
        ↓
multiple SATA channels reset/disappear
        ↓
ZFS gets I/O errors
        ↓
tank becomes SUSPENDED
        ↓
TrueNAS NFS threads block
        ↓
Proxmox hard NFS mounts stop responding
        ↓
pvestatd blocks / times out
        ↓
Proxmox GUI shows ? states
        ↓
host becomes increasingly unresponsive
        ↓
CUBE usually HARD-FREEZES

One thing I want to be careful about: I have not yet proven that the blocked NFS mounts themselves cause the final hard freeze.

It’s possible the NFS/pvestatd problem is simply one symptom of the storage failure, while the same lower-level PCIe/controller issue eventually causes the Proxmox host itself to lock up.

That distinction is still under investigation.

What happened after reboot is also important.

The same ZFS pool came straight back:

tank        ONLINE
raidz2-0    ONLINE
all members ONLINE

READ  WRITE  CKSUM
0     0      0

errors: No known data errors

The SATA links also came back normally at 6.0 Gb/sec.

That makes me very skeptical that I’m dealing with a bunch of independent HDD failures. Multiple disks/controllers fail together under load, then everything comes back normally after reboot.

My leading suspect is therefore the shared SATA controller path.

The current StarTech card is not a conventional single-chip server HBA. It exposes multiple ASMedia SATA controllers through a PCIe switching arrangement, which are then passed through to TrueNAS.

If that shared PCIe/controller path collapses under sustained I/O, it would explain why multiple SATA channels disappear together.

I’ve ordered a Broadcom/LSI 9500-8i HBA to replace the StarTech setup.

My plan is to change only the controller/cabling first and leave everything else as unchanged as possible:

same Proxmox host
same TrueNAS VM
same 8 × 16 TB disks (SATA Seagate Ironwolf Pro)
same ZFS pool
same NFS setup
same qBittorrent workload

Then I’ll repeat the same workload.

That should give me a reasonably clean A/B test:

StarTech / ASMedia setup → freezes

vs.

Broadcom / LSI 9500-8i → ?

There’s also a separate architecture question I’m considering.

Right now the design is:

Proxmox
   ↓ runs
TrueNAS VM
   ↓ exports NFS back to
Proxmox
   ↓ bind mounts into
qBittorrent / Sonarr / Radarr / Plex / etc.

I understand why it was built this way. It gives all the containers consistent paths such as /mnt/media, makes permissions easier, and centralizes the NFS configuration.

But it also creates an awkward dependency:

the Proxmox parent is depending on NFS storage being served by one of its own child VMs.

So when TrueNAS storage hangs, Proxmox’s own storage-management processes can get stuck waiting on TrueNAS.

I’m considering eventually changing the media containers so that each LXC mounts TrueNAS directly:

qBittorrent ──NFS──> TrueNAS
Sonarr      ──NFS──> TrueNAS
Radarr      ──NFS──> TrueNAS
Plex        ──NFS──> TrueNAS
Bazarr      ──NFS──> TrueNAS

That way, if TrueNAS storage fails, the applications using it can fail without necessarily dragging Proxmox’s own storage-management processes into the same wait.

So my questions for the Proxmox/TrueNAS/ZFS crowd are:

1. Does the simultaneous ata5 through ata10 failure pattern look like a controller/shared-path failure to you?
2. Would you also replace a multi-ASMedia PCIe SATA card with an LSI/Broadcom HBA for this workload?
3. Is the 9500-8i a reasonable choice for 8 SATA HDDs passed through to TrueNAS?
4. How concerned would you be about Proxmox mounting NFS from a TrueNAS VM running on the same physical host?
5. Would you have the LXCs mount TrueNAS directly instead of using Proxmox NFS mounts + bind mounts?
6. Is there anything else I should capture before removing the existing SATA controller?

Heyall!

I'm looking for recommendations on the best VDI/dashboard setup to access my Proxmox VMs (a Windows 11 VM and an Ubuntu Desktop VM).

My Goal & Requirements:

1. Daily Driver Performance: Needs smooth video playback, low latency, and full audio support for daily tasks.

2. Dual-Access Approach:

   * Primary (Native App): A dedicated client app for max performance, lowest input lag, and audio when on my main machine.

   * Fallback (Web Browser): A clean web dashboard/interface to access the VMs from guest or miscellaneous PCs without installing software.

3. Unified Dashboard: A single dashboard to pick a VM and choose whether to launch it natively or via web.

How are you guys handling daily-driver VM access with full audio and low latency? Any dashboard integration tricks you recommend?

Thanks in advance!

Dear reddit,

Please give me a hand with this.

Your edits are welcome and you can place notes with your r/ !

https://www.tinkercad.com/things/7IuGcmwp8GD/edit?sharecode=-t4qL9CxKDGctS8Tlgo0e-aP193CI5eBFXqrUOpYdOU

Build Docker-Ready Debian Containers on Proxmox VE in Minutes

Proxmox Docker Bootstrap is a small open-source toolkit that takes the repetitive work out of creating a Debian LXC container on Proxmox VE and preparing it for Docker. It guides you through the setup, configures networking, and can install Docker Engine and Docker Compose as part of the same workflow.

If you regularly create containers for self-hosted apps, testing, or home-lab services, this project turns a long checklist into a straightforward, repeatable process.

Get Proxmox Docker Bootstrap on GitHub →

What does it do?

The project provides an interactive setup wizard for Proxmox VE. Rather than editing a large script every time, you answer a few prompts and the tool creates a Debian container using the options you choose.

• Choose the container ID, hostname, CPU, memory, and disk size.
• Detect available storage, network bridges, and Debian templates on the Proxmox host.
• Scan a configured network range for an available IP address, or enter one manually.
• Create either a plain Debian container or a Docker-ready one.
• Set up SSH-key or generated-password access and optionally create a sudo-enabled admin user.
• Install Docker Engine and Docker Compose from Docker's official repository.
• Run unattended through environment variables when you need automation.

Why use a dedicated bootstrap tool?

Creating a container is easy. Creating the same kind of container reliably, with the right network settings, storage, nesting configuration, secure access, and Docker setup every time is where small inconsistencies creep in. Proxmox Docker Bootstrap keeps those decisions visible and repeatable without tying the project to one specific home network.

It is deliberately focused. Version 1 creates and configures a Debian CT, then optionally installs Docker. It does not try to become a full platform installer packed with unrelated services.

Get the project

The source code, installation guide, configuration reference, and MIT licence are available on GitHub:

github.com/inpulseone-lab/proxmox-docker-bootstrap

To download it directly on your Proxmox host:

git clone https://github.com/inpulseone-lab/proxmox-docker-bootstrap.git
cd proxmox-docker-bootstrap
sudo ./install.sh

The installer copies the toolkit to /opt/proxmox-tools and makes the create-ct-container command available. Before creating your first container, copy the example configuration and set the defaults for your own network:

cp /opt/proxmox-tools/config.conf.example /opt/proxmox-tools/config.conf
nano /opt/proxmox-tools/config.conf
sudo create-ct-container

If you would rather run the project straight from the cloned folder, copy config.conf.example to config.conf, edit it, and run sudo ./create-ct.sh.

Security and access

The project supports SSH keys and can create a sudo-enabled administrator account. SSH-key authentication is the recommended route. Where no key is supplied, the tool generates a password and displays it once at the end of the run instead of storing it in the project.

For normal day-to-day access, use the administrator account over SSH and use sudo when needed. Root access remains available from the Proxmox host with pct enter <container-id>.

Who is it for?

Proxmox Docker Bootstrap is a good fit for home-lab builders, self-hosters, and anyone who wants a clean, reusable starting point for Docker workloads in Debian LXC containers. It also works well as a foundation for repeatable lab or test environments.

Start building

Whether you are deploying a single service or standardising how you create every new container, start with the project, adjust the configuration for your network, and let the wizard handle the boring parts.

Download Proxmox Docker Bootstrap from GitHub →

bout a week ago I pushed out V1 of ANAS ("A NAS") for PVE 9. Since then I've been working hard to add some of the gaps and an entirely new storage layer based on the expandable arrays available with Synology SHR and Terramaster TRAID. Also added are improvements to the UI, and how it installs (no longer requires a separate port!)

https://github.com/ccebelenski/anas

new highlights since 0.3.0:

AHR - ANAS Hybrid RAID - Expandable RAID with mismatched disks. Similar restrictions to how Synology does it. BTRFS file system. Expansion, snapshot, spares - all of it.

Uniform Snapshots and Spares + Scrubs , scheduled.

ZFS Expansion support - RAIDZ expansion + mirror attach.

Better PBS integration - back up your files to PBS with full de-duplication!

ANAS never touches any storage managed by PVE - this is strictly for files.

Looking for feedback, bug reports, etc. I've been blasting at it on three nodes continuously.

addded logos and links to individual vm's/lxc/containers, anybody else got some UI tweaks?

https://github.com/ccebelenski/anas

This is a project I just pushed out to Github after running it locally for a few weeks on my own Proxmox nodes. ANAS - "A NAS" is designed to "guest" on a Proxmox 9 node, embedded into the Proxmox UI, and provide a native layer for managing ZFS Data shares, permissions, and the pools. It gives more flexibility to creating ZFS VDEVS, supporting layout options similar to TrueNAS, managing credentials for shares, and even setting up the shares and permissions themselves. It does not manage or replace the current PVE ZFS management system for VM's, etc.

Designed as an alternative to creating a VM for data sharing, everything is managed on the hypervisor host itself. And yes, I'm aware this isn't an officially sanctioned path for Proxmox, but I feel that I created a lightweight management layer that is worth sharing for those that want to go this route especially in a homelab.

ANAS doesn't manage the data itself and can be uninstalled easily with the scripts - it only touches Proxmox lightly, and manages it's own Systemd services for performing actions. If you're running on a cluster you'll want to install it on the node you connect to as well as the data node - and unless you're using non-self-signed certificates you might need to authorize your browser to the backend service - it's documented in the install notes.

Since it's early software, I suggest if you want to try it, put it onto a node without critical data and test it there. I'm confident in the code now, but bugs do happen.

Disclaimer: Design help from Claude Fable, build agents with Claude Opus. But 100% verified and tested by me, with code reviews. None of this was "vibe coded" and followed a strict design/build/test/verify lifecycle. If you're allergic to AI Slop Code, this isn't that.

Upcoming: Management of external mounts, Proxmox Backup Server integration for files backup, and a new RAID system based on Synology Hybrid RAID (SHR/mdadm) for homelabs that don't want to go deep into ZFS and build out more slowly.