Blank WebUI and SSH issues after update to 8.4.5

X

xbluethunderx

New Member
Jul 28, 2025
18
0
1
Hi everyone,

I recently did my monthly updates on all my homelab devices, as well as my 2-node proxmox cluster.
Everything looked well and was up and running afterwards.
A few days later i tried to log into the WebUI again, but only got a black screen (took quite a while until loading the (black) site was finished).
All the containers and VMs are still running normally, even after rebooting the host.

I then tried to login to ssh, but after successfully login, i cannot type anything anymore and get a connection error after a few seconds.
Screenshot 2025-07-28 134739.png
Access over a local console works normal.


What i tried:

In another thread i saw the black screen problem related to an apt-hook to remove the subscription message (coming from the community helper scripts)
I also did use that a few months ago (yes i know now, will not do that again), so this might be related to that in some way, but there was nothing about ssh problems in the other thread.
This is the script i used back then: https://community-scripts.github.io/ProxmoxVE/scripts?id=post-pve-install

I did some steps to fix the WebUI problem, which seemed to help at first, but after another reboot the problem is back.
Bash: 
#Remove modified files and the apt hook itself
rm -f /etc/apt/apt.conf.d/no-nag-script
rm -f /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
rm -f /usr/share/pve-manager/js/pvemanagerlib.js
#Reinstall affected packages to recreate the deleted files
apt update
apt install --reinstall pve-manager proxmox-widget-toolkit
#reboot
Right now i can't get the web UI to work at all anymore. The SSH problem stays the same


Additional information:

Output of "ls -l /etc/apt/apt.conf.d/"
IMG_3867.jpg

Output of "debsums -as"
IMG_3868.jpg


UPDATE:
This looks like a proxmox related network issue right now.
My hosts are on a different VLAN than my client. If i switch to the same vlan, everything works.
But any webUI or SSH of every other device in any vlan works fine. So this has to be proxmox-specific.
Any help in this direction would be nice.

UPDATE2:
I did a complete reinstall of my proxmox hosts without using any scripts this time.
The problem is back as soon as i add a NFS or SMB storage and reboot the host.
Web and SSH access work fine from clients on the same vlan, but clients in diffenrent vlans get timeouts.
If i remove the NFS storage and reboot the host, everything works fine again.
 
Last edited:
Hi @xbluethunderx ,

I would concentrate on troubleshooting the SSH connection. A few common culprits are: 100% full root disk and duplicate IP.
If both check out ok, you can run SSHD in monitoring mode (-D) to see if it logs anything when the client is disconnected.

Cheers

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Last edited:
bbgeek17 said:
A few common culprits are: 100% full root disk and duplicate IP.
Click to expand...
If i checked the right thing, no disk seems to be near any limit:
IMG_3869.jpg

There should also not be any duplicate IPs.
I checked in my Unifi console, and also did a ping test without the nodes connected. Looks fine.


bbgeek17 said:
If both check out ok, you can run SSHD in monitoring mode (-D) to see if it logs anything when the client is disconnected.
Click to expand...
For sshd, i tried this way: "/usr/sbin/sshd -ddd -D -p 2222"
i tried to connect to Port 2222, it asked me for credentials but lost connection right after entering the password. So it doesn't "look" like properly connected as it does on the default port 22 (see picture in the original post).
The output on the console looks like this:
IMG_3870.jpg
There is nothing more at the end. The client disconnects, but i don't see anything of it on the host.

Sorry for posting all this with pictures, but i can't copy the plain text in any way atm.
 
Last edited:
Ok so i just thought about what if this is not a proxmox but a network related issue:
My client is on a different vlan than my proxmox nodes.
So i just switched it to the same vlan and ... Now it seems to work just fine. WebUI and SSH work as they should.
Switched it back to the client vlan and ... it's gone again.

This worked fine before and the network is the only thing i did not change anything at in the last weeks.
And it is also strange because the first few tries reinstalling the two proxmox packages actually did bring it back to life for some time.
So it look s like it has something to do with proxmox, but maybe something network related inside the OS.
 
Last edited:
I tried another NIC that i added to the bridge, same result.
I can also reach any other WebUI or SSH into any other device on any VLAN without problems.
So this must be something proxmox related.

bbgeek17 said:
It possibly a VLAN/MTU issue, where the VLAN header over-subscribes the MTU size. Or perhaps some other unique combination of VLAN/Router/NIC/etc.
Click to expand...
Dou have any hint where to look for such errors? I did not change the MTU in my network.
 
At the SSH level connectivity disruption - PVE is a Linux host, specifically Debian with Ubuntu derived Kernel.

You said everything works when the hosts are collocated on the same VLAN - is tagging involved? is it native VLAN?
Have you tried without the bridge? Perhaps if you post your exact network configuration here (as text encoded with <CODE> tags) someone might be able to spot something.

The ultimate step is to do a network capture on both sides of the conversation.

Cheers

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
bbgeek17 said:
You said everything works when the hosts are collocated on the same VLAN - is tagging involved? is it native VLAN?
Click to expand...
Yes, when i put the client in the same vlan as the pve host, it works fine.
The management VLAN for the pve host is the native VLAN, but tagging is involved for the VMs, so the bridge is vlan aware.

bbgeek17 said:
Have you tried without the bridge? Perhaps if you post your exact network configuration here (as text encoded with <CODE> tags) someone might be able to spot something.
Click to expand...
I don't want to reconfigure the bridge atm, but i try to move my VMs to have a free host for testing.
If this takes too long, i might just reinstall the hosts completely :D
This is my current network config:
Code: 
auto lo
iface lo inet loopback

iface enp2s0 inet manual

iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.42.30.32/24
        gateway 10.42.30.1
        bridge-ports enp1s0 enp2s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-255

source /etc/network/interfaces.d/*
 
bbgeek17 said:
What was your expectation when you added two ports into the bridge? I'd recommend removing one.
Click to expand...
One of them is a 2.5GBit NIC, the other one is the onboard 1GBit NIC. This is just in case the 2.5G does not work properly (drivers and stuff), so i could always switch back to the onboard one. They are never connected at the same time. This worked perfectly the whole time.

But i managed to remove the bridge completely and configured one of the NICs directly.
The problem is still the same, no matter which NIC i try. This is the new config:

Code: 
auto lo
iface lo inet loopback

auto enp2s0
iface enp2s0 inet static
        address 10.42.30.32/24
        gateway 10.42.30.1

iface enp1s0 inet manual

source /etc/network/interfaces.d/*
 
bbgeek17 said:
And what is the actual running configuration? "ip a"
Click to expand...
I switched to the enp1s0, but same result
Code: 
root@sv-pve-node02:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:4e:01:ac:3a:81 brd ff:ff:ff:ff:ff:ff
    inet 10.42.30.32/24 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::24e:1ff:feac:3a81/64 scope link
       valid_lft forever preferred_lft forever
3: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:e0:4c:68:0b:96 brd ff:ff:ff:ff:ff:ff

bbgeek17 said:
Have you tested full ICMP packet: ping -c 4 -M do -s 1472 <destination>
in all directions from all hosts (pve<>gw,pve<>client, within the vlan, across vlans).
Click to expand...
This works fine in all directions, within vlan and across vlans
 
Last edited:
Yeah might be unifi doing strange things, and it might have updated automatically without me noticing.
I will try a fresh proxmox install anyway and report back if the problem is gone or if it stays even with a fresh install.
This is faster than further debugging at this point.
 
UPDATE:
I reinstalled both hosts completely now, and can kind of reproduce the error.
After a fresh install, everything works fine. Steps i did:
- Change to no-subscription repos and install the latest updates, then reboot - OK
- Added the second (unused/backup) NIC to the bridge and changed to vlan-aware, then reboot - OK
- Add second ssd as storage for my machines, then reboot - OK
- Add my NAS as NFS storage (did no reboot here, whyever) - OK
- restored some of my containers and VMs without starting them, then reboot - NOT OK - PROBLEM BACK
- removed the NFS storage, then reboot - OK - PROBLEM GONE
- added NFS storage, then reboot - OK - NO PROBLEM this time?
- removed the NFS storage, then reboot - OK
- added NFS storage, then reboot - NOT OK - PROBLEM BACK
- removed the NFS storage, then reboot - OK

On the second host (no cluster configured yet), it was almost the same.
After removing the NFS storage and having a working condition again, i added the same NAS as SMB storage, and the problem was back even without rebooting.
So i removed the SMB storage and rebooted (had to reboot twice), problem gone again.
Client access on same vlan works still fine all the time for both hosts, so this is the exact same problem as originally.

So there definetely is something related to network storage together with client access across a different vlan.
 
You must log in or register to reply here.
Top Bottom