vzdump hookscript not triggered on one specific node (LXC), works fine on other nodes with identical config

[beta-louis]

Hi,

I'm running a 3-node PVE cluster (all on version 9.1.1, except one node on 9.1.4) and I'm facing an issue where the hookscript for vzdump is not being triggered at all on one specific node, while the exact same setup works perfectly on the other two.

Cluster setup:

• Node A (proxmox): pve-manager/9.1.4
• Node B (pve2): pve-manager/9.1.1 ← affected node
• Node C (pve3): pve-manager/9.1.1

Working case (Node A and Node C):
A hookscript is attached to CTs and VMs via:

pct set <VMID> --hookscript local:snippets/notify-discord.sh

or

qm set <VMID> --hookscript local:snippets/notify-discord.sh

Running vzdump <VMID> --storage PBS --mode snapshot (or suspend) triggers the hookscript correctly at every phase (job-init,job-start, backup-start, backup-end, job-end, etc.), confirmed via a debug line writing to a log file at the very top of the script.

Non-working case (Node B, pve2):
Identical hookscript, identical pct set --hookscript command, identical storage config (local storage has snippets in its content list, confirmed via cat /etc/pve/storage.cfg). Running vzdump 106 --storage PBS --mode snapshot completes the backup successfully, but the hookscript is never invoked — not even the job-init phase, which should fire before any guest-specific logic.

What I've already verified/tried on the non-working node:

• Script exists, is executable (-rwxr-xr-x), correct permissions
• pct config 106 | grep hookscript shows the correct path
• snippets is enabled in the local storage content list
• Tested both --mode snapshot and --mode suspend
• Manually running the script directly (/var/lib/vz/snippets/notify-discord.sh backup-end suspend 106) works perfectly and logs correctly
• Removed and re-added the hookscript via pct set 106 --delete hookscript then pct set 106 --hookscript ...
• Restarted pvedaemon, pvestatd, pveproxy on the affected node
• Confirmed pve-container package version is identical (6.0.18) across all three nodes
• Checked dmesg for AppArmor denials — nothing relevant
• Checked journalctl -p err around the time of the backup — nothing relevant
• /etc/vzdump.conf has no conflicting global script: override (all commented out, defaults)

Container config (/etc/pve/lxc/106.conf):

arch: amd64
cores: 1
features: nesting=1
hookscript: local:snippets/notify-discord.sh
hostname: c-kuma
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.254,hwaddr=BC:24:11:7B:B3:3C,ip=192.168.1.23/24,type=veth
ostype: debian
rootfs: local-lvm:vm-106-disk-0,size=8G
swap: 512tags: docker;monitoring
unprivileged: 1

pveversion -v (affected node):

proxmox-ve: 9.1.0 (running kernel: 6.17.2-1-pve)
pve-manager: 9.1.1 (running version: 9.1.1/42db4a6cf33dac83)
proxmox-kernel-helper: 9.0.4
proxmox-kernel-6.17.2-1-pve-signed: 6.17.2-1
proxmox-kernel-6.17: 6.17.2-1
ceph-fuse: 19.2.3-pve2
corosync: 3.1.9-pve2
criu: 4.1.1-1
frr-pythontools: 10.3.1-1+pve4
ifupdown2: 3.3.0-1+pmx11
intel-microcode: 3.20250812.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.0
libproxmox-backup-qemu0: 2.0.1
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.0.4
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.0.7
libpve-cluster-perl: 9.0.7
libpve-common-perl: 9.0.15
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.2.3
libpve-rs-perl: 0.11.3
libpve-storage-perl: 9.0.18
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 6.0.5-3
lxcfs: 6.0.4-pve1
novnc-pve: 1.6.0-3
proxmox-backup-client: 4.0.20-1
proxmox-backup-file-restore: 4.0.20-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.1
proxmox-mail-forward: 1.0.2
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.3
proxmox-widget-toolkit: 5.1.2
pve-cluster: 9.0.7
pve-container: 6.0.18
pve-docs: 9.1.0
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.17-2
pve-ha-manager: 5.0.8
pve-i18n: 3.6.2
pve-qemu-kvm: 10.1.2-3
pve-xtermjs: 5.5.0-3
qemu-server: 9.0.30
smartmontools: 7.4-pve1
spiceterm: 3.4.1
swtpm: 0.8.0+pve3
vncterm: 1.9.1
zfsutils-linux: 2.3.4-pve1

Question:
Has anyone encountered a similar situation where vzdump silently ignores the hookscript config on a specific node despite an otherwise identical setup? Is there a way to get more verbose logging from vzdump specifically around hookscript invocation, to understand why it's being skipped on this node?

Any pointers appreciated, happy to provide more info if useful.
Thanks!

 

[dcsapak]

i think you're conflating two hookscripts here:

there are the vm hookscripts (which you can set with qm/pct): these are for vm start/stop/etc.

and there is a vzdump hookscript which is intended for job start, backup start, etc. -> this can be set in the /etc/vzdump.conf on the specific host.

my guess is that you set that once on one host, but not the other?

 

[beta-louis]

Solved!

You were absolutely right, thank you for pointing me in the right direction.

The root cause was exactly what you suspected: /etc/vzdump.conf had the script: line properly set on the two working nodes (proxmox and pve3), but not on the affected node (pve2). I had mistakenly assumed the per-guest hookscript (set via pct set --hookscript) was sufficient on its own to trigger the job-level phases (job-init, job-start, job-end), but it turns out the node-level script: directive in vzdump.conf is also required for that.

Fix applied:

nano /etc/vzdump.conf

Added:

script: /var/lib/vz/snippets/notify-discord.sh

After that, re-running vzdump 106 --storage PBS --mode snapshot correctly triggered every phase:

job-init
job-start
backup-start snapshot 106
pre-stop snapshot 106
pre-restart snapshot 106
post-restart snapshot 106
backup-end snapshot 106
log-end snapshot 106
job-end

For anyone hitting a similar issue: if your hookscript is set at the guest level (via pct/qm) but the job-level phases never fire, double-check /etc/vzdump.conf on that specific node — it needs its own script: line, and this config isn't automatically synced across cluster nodes.

Thanks again for the quick and accurate answer, this can be closed.