I have troubles backing up an LXC container on PROXMOX VE 9.
I do it as a backup job that saves shapshot images on a NAS.
Strange thing is that it happens sometimes, not always.

Traced error is:
2026-01-10 01:05:02 INFO: zstd: error 70 : Write error : cannot write block : Bad address

Backup NAS is a Synology RS422+ (OS DSM 7.3.2)
Images are saved on a mounted folder shared by the NAS as an SMB volume
Diagnostics on the NAS did not reveal any problem.

More detailed infos are attached.

Can you please help to understand?

Hello,

I encounter the same issue when I backup VM on synology.

Hi,
not entirely sure if noserverino also helps in your cause, but I'd give it a try:

Hello,

I encounter the same issue when I backup VM on synology.

Hi Inglebard,
the problem rises really sparsely. Now it's 10 days since last happening.
I will investigate fl0moto's advice but I think that's not the case.

Hi,
not entirely sure if noserverino also helps in your cause, but I'd give it a try:

Hi all,

i have a SMB/CIFS MP bound into proxmox and used in the vms/lxc.
In the past week the mount seems to went bad as it return stale file when used on the lxc and even in proxmox itself when i try to cp a file for example.

I unmounted by umount --lazy and removed the dir from /mnt/pve/<share> and set it up again. Error still exists. So i removed the mp from all vm and LXC and removed again from proxmox and set it up again (using cli pvesm add cifs... and webinterface).

if i check with command df i see it succesfully mounted on the path.

Any ideas will be appreciated.
Thanks.

Hi fl0moto. I will investigate it but think is not the same problem.
mount's man page says noserverino option has to do with how to treat hardlinks, which are not present among the files I backup.
Thank you anyway.

Hi,
maybe you can try a

for a backup via cli to investigate further which ressource the zstd fails to access.
BR, Lucas

Hi,
maybe you can try a

for a backup via cli to investigate further which ressource the zstd fails to access.
BR, Lucas

Every time I launched it manually didn't fail.
Maybe is possible the let the backup procedure use strace?

Mirco

Hi Mirco,
the backup jobs are executed by the pvescheduler (usually run as systemd service).

So for debugging you can try to stop the systemd service and start the scheduler with a strace (and maybe in debug mode). This will generate a lot of output, depending on the others scheduling jobs.

BR, Lucas

Hello,
I'm still having the same problem. Has anyone found a solution ?

Hi,

same problem here on 9.2.2 and a cluster of two RS3621xs+ with DSM 7.3.2 Update 3.

I tried to strace the problem, but in compliance to Murphys Law, the backup went smooth.

Anyone of you has news on this topic?

Best
Arne

Just to let you know: no news about it.
The problem arises erratically, like @awiesel noted, and I still haven't found a way to catch it.

Mirco

Good morning. I managed to capture a 2,7 Gb strace of the show. The relevant part:

3024886 07:10:42 write(1, "lotsofdata1234"..., 131072 <unfinished ...>
3024887 07:10:42 read(0,  <unfinished ...>
3024886 07:10:42 <... write resumed>)   = -1 EFAULT (Bad address)
3024886 07:10:42 write(2, "zstd: ", 6 <unfinished ...>
3024887 07:10:42 <... read resumed>"lotsofdata1234"..., 126976) = 65536
3024887 07:10:42 read(0,  <unfinished ...>
3024886 07:10:42 <... write resumed>)   = 6
3024857 07:10:42 <... pselect6 resumed>) = 1 (in [5], left {tv_sec=0, tv_nsec=480942946})
3024886 07:10:42 write(2, "error 70 : ", 11) = 11
3024857 07:10:42 read(5,  <unfinished ...>
3024886 07:10:42 write(2, "Write error : cannot write block : Bad address", 46 <unfinished ...>

Can anybody help me out how to proceed from here? What I learned with the help of claude is that piping data back to the parent process failed because the pointer is bad?