Search results

Local time: Tue 2025-11-25 04:37:56 EST Universal time: Tue 2025-11-25 09:37:56 UTC RTC time: Tue 2025-11-25 09:37:57 Time zone: America/New_York (EST, -0500) System clock synchronized: no NTP service: active RTC in local TZ: no This says that your time zone is EST (America/New_York). Is that...

What is the output of "chrony sources"? Please use the </> code tags.

Did you try "systemctl restart chrony"?

When it first boots the system will set the time from the BIOS clock (aka CMOS). That clock should be set to UTC, NOT to your local time. That would explain the 5 hours as you are in GMT-5. The other systems probably have the same error in their BIOS but you don't notice because NTP corrects it...

It would seem that: Your CMOS clock is way off (that's where the system gets its initial time). You have no servers or pools listed in /etc/chrony/chrony.conf, or else your DNS is not able to resolve them.

What is the output of "chronyc sources", "timedatectl", "ip a" and "ip route"? Do you have the CMOS clock set to local time or UTC (preferred)?

This is why it is generally not a good idea to have multiple interfaces on the same subnet. The kernel considers them to be "the same" in the sense that both are equally good to reach destinations on that network or gatewayed through it. Which means it will just pick one, usually the first one...

If you look at the hardware requirements in the PVE documentation, you will see that Chrome 109 and Firefox 115 are WAY too old. I mean, maybe you could try Internet Explorer while you're at it. ETA: https://www.proxmox.com/en/products/proxmox-virtual-environment/requirements

Maybe before going to that trouble you could try a private browsing tab to make sure it isn't some extension that's causing the issue.

I can confirm it works with Firefox 140.5 on Debian 13.

IOW, if the box is checked, you pass.

Windows is a largest virus platform. Therefore it is also the largest anti-virus platform. Even Linux anti-virus products mostly check for Windows viruses. Which makes sense if you're serving files to Windows users. On a Linux-based hypervisor it is just useless overhead. Yes, I am aware that...

Linux is an inferior antivirus platform. If you want to run your antivirus really well, the best bet is to install Windows.

Nov 14 17:31:59 pve kernel: Generic FE-GE Realtek PHY r8169-0-200:00: attached PHY driver (mii_bus:phy_addr=r8169-0-200:00, irq=MAC) Nov 14 17:31:59 pve kernel: r8169 0000:02:00.0 enp2s0: Link is Down Nov 14 17:31:59 pve kernel: vmbr0: port 1(enp2s0) entered blocking state Nov 14 17:31:59 pve...

Possibilities that come to mind: You installed NUT from somewhere besides the Debian repository and the driver needs to be rebuilt. You installed NUT from Debian repositories but something changed in the config file between v12 and v13 (you would have got a warning about that during the upgrade...

Nov 14 15:30:06 pve systemd[1]: nut-driver@apc.service: Control process exited, code=exited, status=1/FAILURE Nov 14 15:30:06 pve systemd[1]: nut-driver@apc.service: Failed with result 'exit-code'. Nov 14 15:30:06 pve systemd[1]: Failed to start nut-driver@apc.service - Network UPS Tools -...

Never used it, but it is in the Debian repository. Which means that if it does break anything it should be easy to remove.

Why do you care about source IP? I'm talking just blocking all inbound to port 8006 on the host IP and leaving 22 open. It will then work like you want without hacking around on PVE. It might break stuff, but so might your way. I've seen comments here before from Proxmox staff that it isn't...

You could just enable the firewall.

I guess I should have put <sarcasm> tags on that. No, I don't think it makes any sense. It is a lot of effort for basically no return. It is a silly idea in the vast majority of cases. I'm not saying no one should ever do this, but it is ridiculous to think it should be the default or on the GUI.