Proxmox: why a container and a VM don't come back up (and why the backup wasn't to blame)

My Proxmox homelab has a recurring problem: an LXC container (Jellyfin) and a VM (NethServer) are often found powered off. I had a specific suspect: it happens after the nightly backup. This is the story of how I tested that hypothesis, why it was wrong and what I actually found.

The setup

  • A single Proxmox host, 6 LXC containers and 1 VM, disks on local-lvm (LVM-thin).
  • A NAS on the network serving two shares: a CIFS one with media and an NFS one for backups.
  • Backups run from a script started by cron at 08:00: it calls vzdump for every guest and then archives with Borg on the NAS.
  • No UPS.

First hypothesis: the backup leaves the guests off

It was a reasonable guess: a backup job that fails halfway can leave a lock on a guest or fail to restart it. I checked three things.

1. Locks on the guests. None.

grep -H '^lock:' /etc/pve/qemu-server/*.conf /etc/pve/lxc/*.conf

2. vzdump mode and logs. The containers are backed up live, in snapshot mode, without ever being stopped. The VM was already stopped before the backup started: vzdump powered it on for the dump and turned it off again.

INFO: status = stopped
INFO: backup mode: stop

3. Timing. The backup starts at 08:00. As we’ll see, the host outages don’t line up with that time.

Conclusion: the backup doesn’t shut anything down. I had to look elsewhere.

What put me on the right track

The Proxmox task history

The task history lives in /var/log/pve/tasks/index. It’s a binary file, so you need grep -a, otherwise all you get is “binary file matches”.

grep -a -E "vzstart:101|startall" /var/log/pve/tasks/index | tail -30

The result: in every startall (the automatic guest start when the host boots) container 101 fails with startup for container '101' failed, while the others start. Then I start it by hand and it always comes up.

Host reboots

last -x reboot shutdown | head

Every reboot line ended with crash and there was no shutdown record at all. So the host wasn’t shutting down cleanly: it was being cut off abruptly. I checked the journal too:

for b in $(seq -11 -1); do
  journalctl -b $b --no-pager | grep -q "Journal stopped" \
    && echo "boot $b: clean" || echo "boot $b: INTERRUPTED"
done

Out of eleven boots, only one had ended properly. Before the interruptions the logs showed no errors: no panic, MCE, I/O errors, thermal or watchdog events. And the timestamp of the last line of each boot is never around 08:00.

The NVMe drive

smartctl -a /dev/nvme0n1 | grep -Ei "unsafe|power cycles|critical|media|percentage|temperature"

Power Cycles:                       470
Unsafe Shutdowns:                   46
Media and Data Integrity Errors:    0
Percentage Used:                    11%

The drive is healthy, but the 46 unsafe shutdowns confirm that sudden power cuts are recurring. The counter is cumulative and can’t date the events, but the picture is consistent.

Why container 101 doesn’t start

The task log only says Failed to run lxc.hook.pre-start. The real reason is in the boot journal, filtering around the failure:

journalctl -b 0 --since "2026-11-01 22:40:50" --until "2026-11-01 22:42:30" --no-pager \
  | grep -Ei "101|nas|cifs|automount|mnt-|network-online"

mnt-nas-media.automount: Got automount request for /mnt/nas/media, triggered by (lxc-pve-prestart)
CIFS: Attempting to mount //192.168.0.2/Multimedia
CIFS: VFS: Error connecting to socket. Aborting operation.
CIFS: VFS: cifs_mount failed w/return code = -111
Failed to mount mnt-nas-media.mount - /mnt/nas/media.
pve-guests: startup for container '101' failed

The container has a bind mount to /mnt/nas/media, automounted from the NAS CIFS share. When the host boots, the NAS answers on the network but its SMB service isn’t up yet: the mount fails with -111 (connection refused), the container doesn’t start and Proxmox doesn’t retry.

Why is the NAS slower than the host? Because in a power outage both go down, and when power comes back they boot together. A NAS takes much longer to boot than a mini PC and needs a few extra minutes before its network services are up.

Why the VM doesn’t start

The VM had no onboot: 1. Check:

grep -H onboot /etc/pve/qemu-server/*.conf /etc/pve/lxc/*.conf

Only the containers showed up in the output. Without onboot the VM stays off after any host reboot. One line of config:

qm set 107 --onboot 1

The fixes

1. Make the guests wait until the NAS is ready

A script checks the NAS SMB (445) and NFS (2049) ports and holds back guest startup for at most five minutes. If the NAS is already up, it exits immediately.

cat > /usr/local/bin/wait-nas.sh <<'EOF'
#!/bin/bash
nas=192.168.0.2
for i in $(seq 1 60); do
  if timeout 2 bash -c "</dev/tcp/$nas/445" 2>/dev/null \
     && timeout 2 bash -c "</dev/tcp/$nas/2049" 2>/dev/null; then
    exit 0
  fi
  sleep 5
done
exit 0
EOF
chmod +x /usr/local/bin/wait-nas.sh

I hook it into guest startup with a systemd drop-in:

mkdir -p /etc/systemd/system/pve-guests.service.d
cat > /etc/systemd/system/pve-guests.service.d/wait-nas.conf <<'EOF'
[Service]
ExecStartPre=/usr/local/bin/wait-nas.sh
EOF
systemctl daemon-reload
systemctl cat pve-guests | grep -i timeout   # no timeout that's too short?
time /usr/local/bin/wait-nas.sh              # with the NAS up it must return immediately

The trade-off: if the NAS stays down for a long time, guests that don’t need it (DNS, VPN) also start up to five minutes late. In my case that’s acceptable.

2. Re-enable autostart for the VM

qm set 107 --onboot 1

3. The BIOS

In the host BIOS, the option that controls what happens after a power loss (Restore on AC power loss) should be set to Power On, so the host comes back up on its own without intervention.

4. The UPS, the real fix

The two scripts are a band-aid. The cause is the power supply, and an outage without a UPS isn’t just an annoyance: every abrupt shutdown puts the file system and the LVM thin pool at risk. The plan:

  • A 600–900 VA line-interactive UPS with a USB port, NUT-compatible.
  • Sizing: host, NAS, router and switch draw about 100 W, so 10–20 minutes of runtime.
  • The UPS connects over USB to the NAS, which acts as the network UPS server.
  • The Proxmox host runs nut-client in netclient mode, so during an outage it shuts down the guests and powers off first, and the NAS goes last.

Still to verify

I’m not yet 100% sure the reboots are caused by power: the same picture (no errors in the logs, abrupt shutdowns) would also come from a hardware reset or a complete machine hang. The check is simple: compare the host reboot times with the NAS event log. If the NAS rebooted at the same times, it’s an outage; if it didn’t move, the problem is in the host alone and the next step is logging temperatures.

Other issues found along the way

  • soft NFS mount for backups. For backup writes hard is better: with soft, a slow NAS can return I/O errors halfway through writing the archive.
  • nfsidmap complaining every 10 minutes (root@localdomain doesn’t map to the local domain). Fixed by aligning the idmap domain between host and NAS, or by mounting with vers=3.
  • rsyslog apparmor DENIED inside the container. Log noise every 5 minutes, unrelated to the startup failures.

What I learned

  1. A hypothesis that looks obvious has to be checked against the logs: the backup was innocent.
  2. grep -a on the Proxmox task index. The task history is the most useful source and can only be read with that flag.
  3. last -x reboot shutdown and journalctl --list-boots tell you whether the host shuts down cleanly. If every boot ends with crash, the problem is below Proxmox.
  4. The NVMe Unsafe Shutdowns counter is a free indicator of power cuts.
  5. Anything that depends on a NAS at boot needs a startup order. Proxmox doesn’t wait for network shares on its own.
  6. A UPS isn’t a luxury, even in a homelab.
ProxmoxHomelabLXCBorgNASUPSTroubleshooting