Backup of live pfSense VM to NAS fails

M

madbrain

New Member
Apr 15, 2026
13
1
3
I have a NAS to which I backup my VMs and containers.
All my containers backup to this NAS fine.
Not so for my two VMs - pfSense and Home assistant OS. Here is a log from the pfSense backup :

INFO: starting new backup job: vzdump 103 --mode snapshot --node proxmox --compress 0 --notes-template '{{guestname}}' --notification-mode notification-system --storage zfs_nas --remove 0
INFO: Starting Backup of VM 103 (qemu)
INFO: Backup started at 2026-08-28 06:54:48
INFO: status = running
INFO: VM Name: pfSense
INFO: include disk 'sata0' 'xfs_storage:103/vm-103-disk-1.qcow2' 61058M
INFO: include disk 'efidisk0' 'xfs_storage:103/vm-103-disk-0.qcow2' 528K
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating vzdump archive '/mnt/backups/dump/vzdump-qemu-103-2026_08_28-06_54_48.vma'
INFO: skipping guest filesystem freeze - disabled in VM options
INFO: starting backup via QMP command
INFO: started backup task 'bcf0ebcb-e9ad-4622-a747-0172a4a3158a'
INFO: resuming VM again
INFO: 11% (6.7 GiB of 59.6 GiB) in 3s, read: 2.2 GiB/s, write: 711.9 MiB/s
INFO: 25% (15.3 GiB of 59.6 GiB) in 6s, read: 2.9 GiB/s, write: 727.9 MiB/s
INFO: 42% (25.3 GiB of 59.6 GiB) in 9s, read: 3.3 GiB/s, write: 446.3 MiB/s
INFO: 52% (31.3 GiB of 59.6 GiB) in 12s, read: 2.0 GiB/s, write: 402.3 MiB/s
INFO: 64% (38.6 GiB of 59.6 GiB) in 15s, read: 2.4 GiB/s, write: 631.7 MiB/s
INFO: 79% (47.2 GiB of 59.6 GiB) in 18s, read: 2.9 GiB/s, write: 272.1 MiB/s
INFO: 88% (52.8 GiB of 59.6 GiB) in 21s, read: 1.9 GiB/s, write: 197.1 MiB/s
INFO: 100% (59.6 GiB of 59.6 GiB) in 45s, read: 290.9 MiB/s, write: 38.3 MiB/s
ERROR: vma_writer_close: close failed - Host is down
INFO: aborting backup job
INFO: resuming VM again
ERROR: Backup of VM 103 failed - vma_writer_close: close failed - Host is down
INFO: Failed at 2026-08-28 06:55:34
INFO: Backup job finished with errors
INFO: notified via target `mail-to-root`
TASK ERROR: job errors

The NAS host is most definitely not down.

If I shut down this pfSense VM, I am able to back it up to the NAS without this error.

Also, I can back them up to local storage without this error, even if they are live.

Same exact symptom with the HAOS VM.

I have other VMs that are not always on, for instance an HAOS development VM. I can back it up to NAS without problem, whether it's running or not.

So, the problem seems to be very specific to the 2 live VMs I have - I can't back up either of them to NAS for some reason.

The NAS is a Ubuntu box. The ZFS volume is mounted over Samba and defined as directory storage. Here is the /etc/fstab entry and GUI config :

//server10g.localdomain/zfs/Backups/proxmox /mnt/backups cifs credentials=/etc/creds,x-systemd.automount,x-systemd.idle-timeout=60,nofail,uid=100000,gid=100000,file_mode=0777,dir_mode=0777,iocharset=utf8,vers=3.0 0 0

The NAS is not always-on - I use WOL to wake it up when needed. I trigger the backup job manually. It is not scheduled.

1787926449108.png
 
An uneducated guess, and one that assumes the 'vma_writer_close: close failed - Host is down' is not what's implied! But, could your live guest backup be failing because you do not have qemu agent installed (VMs) or enabled (PVE guest config)? Since they successfully backup when off/shutdown.
Scratch that. I just reread your post. Live backups are working to local storage.
 
Last edited:
Is your link between Proxmox and the NAS routed through that pfSense VM? I would created a non routed link between Proxmox and the NAS on the same VLAN.
 
louie1961 said:
Is your link between Proxmox and the NAS routed through that pfSense VM? I would created a non routed link between Proxmox and the NAS on the same VLAN.
Click to expand...
No, it is not routed. Proxmox and the NAS are both on the LAN. There are no VLANs at this time, unmanaged switch.

pfSense VM is used for internet routing/DNS/DHCP.
 
I spent many hours tracing this with the help of ChatGPT. This is the summary. It appears to be a bug in the CIFS SMB client. I have not verified the fix yet. Full gory details are at https://chatgpt.com/share/6ad023fd-f24c-83e8-9d17-4e6103d68270 .

Proxmox CIFS Backup Failure — Technical Investigation Summary​

Date: October 14, 2026
System: Proxmox VE 9.2, kernel 7.0.14-17-pve, CIFS client 2.59

Problem Description​

  1. VM 102 (HAOS, 96 GiB) is backed up using vzdump, snapshot mode, uncompressed VMA.
  2. Destination: CIFS share \\server10g.localdomain\BACKUPS, hosted by Samba on ZFS.
  3. Backups transfer at approximately 250–650 MiB/s and intermittently fail at completion.
  4. Failure: vma_writer_close: close failed - Resource temporarily unavailable.
  5. Identical backups sometimes succeed; backups to another SMB server succeed.
  6. No comparable write failures have been observed from other applications accessing the NAS.

Diagnostic Results​

  1. QEMU's close() syscall returns -11 (EAGAIN).
  2. Kernel cifs_flush() also returns -11 (EAGAIN).
  3. filemap_write_and_wait_range() returns -5 (EIO).
  4. CIFS propagates previously recorded asynchronous writeback errors during close.
  5. smb3_write_err confirms failed 4 MiB SMB write operations.
  6. First affected write returns -103 (ECONNABORTED).
  7. Outstanding writes subsequently fail with -11 (EAGAIN).
  8. netfs_failure additionally records -512 (ERESTARTSYS) write failures.
  9. filemap_set_wb_err confirms asynchronous writeback-error recording.
  10. smb3_partial_send_reconnect occurs immediately before the first failed SMB write.
  11. CIFS initiates reconnection and invalidates outstanding writes.
  12. Kernel logs repeatedly report socket sends stuck for 15 seconds.
  13. Corresponding kernel warning: Error -512 sending data on socket to server.
  14. TCP monitoring shows send-buffer pressure and occasional receiver-window restriction.
  15. Increasing tcp_wmem and net.core.wmem_max from 4 MiB to 16 MiB did not prevent failures.
  16. sk_stream_wait_memory() repeatedly returns an interruption during the failing workload.
  17. Earlier ftrace results show return value 4294967292, equivalent to 32-bit -EINTR.
  18. A targeted CO-RE eBPF kretprobe independently confirms rc=-4 (EINTR).
  19. The same probe records thread_info.flags=0x80804.
  20. Matching Proxmox kernel headers define TIF_NOTIFY_SIGNAL as bit 2 (0x4).
  21. Therefore, TIF_NOTIFY_SIGNAL=1 is directly verified during interrupted TCP waits.
  22. At timestamp 84274.852126, TCP wait returns -EINTR with notification flag set.
  23. At 84274.852135, CIFS triggers smb3_partial_send_reconnect — 9 µs later.
  24. At 84274.852140, the SMB write fails with ECONNABORTED — another 5 µs later.

Suspected Root Cause​

  1. QEMU's io_uring task-work notifications appear to interrupt CIFS TCP sends.
  2. CIFS interprets an interrupted partial send as requiring connection recovery.
  3. The reconnection causes asynchronous writeback errors, eventually failing VMA close.
  4. This matches the mechanism targeted by the October 2026 upstream SMB patch.
  5. The triggering condition is verified; patch effectiveness remains unverified.

Proposed Fix and Verification​

  1. Candidate: upstream commit d0ae35565f5d5, “smb: prevent TIF_NOTIFY_SIGNAL from interrupting”.
  2. The patch uses scoped_guard(no_notify_signal) around sock_sendmsg().
  3. It was reported in linux-next on October 9, 2026; released-kernel status is unconfirmed.
  4. Verify the patch and dependencies against Proxmox's exact kernel source, then test a patched CIFS module.
  5. If validated, request a Proxmox kernel backport; NFS is an interim workaround.
References:

 
You must log in or register to reply here.
Top Bottom
Back