Error copying some files

[Didier]

Hello,
I’m getting an error copying some files. Some .ts files from TV recordings via a digital terrestrial tuner copy almost to completion, but at the last few percent, an error appears: error 0x80070299, and the copy fails. On all my other devices (NAS or otherwise), these files copy and save without any problem. Does anyone have any ideas?
Windows and its system files have been checked, using DISM and sfc /scannow
It’s not a size issue; other .TS files located elsewhere don’t fail. Zimas OS is installed for testing with four small 1TB hard drives in RAID 5, an i7 3000 series processor, and 16GB of RAM.
ZimaOS v1.5.3 Community Edition

Thanks in advance.
you can speak in french if you want

[gelbuilding]

Error 0x80070299 on Windows during a network copy usually points to an I/O timeout / connection drop during the final “write + close” stage. The fact it fails at the last few % strongly suggests SMB (Samba) or the underlying RAID/disk doing retries, not Windows itself.

What I suggest checking on ZimaOS (SSH)

1. Is RAID rebuilding / degraded?

cat /proc/mdstat

2. Look for disk I/O errors

dmesg -T | tail -200

Search for: I/O error, reset, ata, blk_update_request, mdadm.

3. Check SMART health on each disk

smartctl -a /dev/sdX | tail -80

(especially Pending_Sector, Reallocated_Sector)

Quick Windows workaround test

Try copying with Robocopy (more reliable than Explorer):

robocopy "C:\source" "\\ZIMA-IP\share" "file.ts" /Z /R:3 /W:3

If Robocopy succeeds > this is likely SMB/Windows Explorer session handling.
If RAID/dmesg shows errors > it’s likely a failing disk or RAID retries causing the timeout.

[Didier]

thank you very much, i’m going to try all that points, sincerly yours

[Didier]

Hello and thank you.
Here are the results I obtained. Understanding and executing the commands with the AZERTY keyboard isn’t easy…
I’ll try to attach the results as images.

test2 couldn’t interpret it

Note that for Robocopy, even with a fairly long time, the result is the same: failure.

[Didier]

and the smart test seems good?

[gelbuilding]

Thanks for the extra screenshots.
Your RAID looks healthy ([UUUU]) and SMART is clean (0 reallocated / 0 pending / 0 uncorrectable + no SMART errors), so I don’t believe this is a failing disk.

Since Robocopy fails at 99.9% with ERROR 665 / 0x80070299, I suggest this is more likely an SMB/Samba timeout during the final flush/close stage.

Can you run these right after the failure and paste the output?

dmesg -T | tail -200
logread | tail -200

Also try this Windows test (often helps large media files):

robocopy "C:\test" "\\192.168.1.65\stockage_principal" "film.ts" /Z /R:1 /W:1 /J

[Didier]

Thanks for these new, narrowed-down leads. For your information, I’ve set up a new RAID array with four 3TB disks, still in RAID 5, and the problem remains the same.
I could also copy these same files from another PC to see

[gelbuilding]

Thanks for confirming that, that’s actually a very strong test.

If you rebuilt a completely new RAID5 array with different disks and the same problem still happens, I believe we can reasonably exclude “failing drive” or “RAID rebuild/degraded array” as the root cause.

At this point I suggest focusing on SMB/Samba + network stability during the final file flush/close step, which matches the “fails at the last few %” symptom.

What I suggest testing next

1) Copy the exact same .TS file from a different PC

• If it succeeds from PC#2 > this points to a Windows SMB/client issue on PC#1
• If it fails from PC#2 as well > this points to ZimaOS SMB (Samba) behaviour / network layer

2) Try forcing SMB3 only (quick Windows-side test)
On Windows, temporarily disable SMB1 (if enabled) and ensure SMB3 is used (Windows 10/11 normally does this automatically).
Also try this Robocopy variant (unbuffered I/O):

robocopy "C:\test" "\\192.168.1.65\stockage_principal" "film.ts" /Z /R:1 /W:1 /J

3) Check if MTU / jumbo frames is involved
If any device (router/switch/NIC) is using jumbo frames, I suggest temporarily setting everything back to MTU 1500 and retesting.

4) Capture Samba/kernel logs immediately after a failed copy

dmesg -T | tail -200
logread | tail -200

If you paste those outputs after a failure, we can usually see whether it’s Samba timing out, a network reset, or a write-close stall.

[Didier]

It is ok with another PC, i try command line later, thanks a lot

[Didier]

point 1

ok on all other pc

point 2

smb1 is already disabled

robocopy not good

point 3

all mtu are on 1500

point 4

i don’t know whre i can do that…

[gelbuilding]

Thanks, that helps clarify things.

Point 1
Works on all other PCs > confirms the files themselves are fine and the ZimaOS storage can accept them.

Point 2
SMB1 already disabled > correct, nothing to change there.

Point 3
MTU set to 1500 everywhere > correct and rules out jumbo frame issues.

Robocopy result
The Robocopy error you posted (ERROR 665 / 0x80000299 at ~99.9%) shows the same behaviour as Explorer: the transfer completes but the final write / close fails.
This rules out a simple copy-tool problem.

Point 4 (where to do this)
These checks are run on the ZimaOS system, not on Windows.

• Open the ZimaOS Terminal (or connect via SSH)
• Add the following commands in the terminal, one after the other:

dmesg -T | tail -200
journalctl -n 200 --no-pager

• Paste the output here (text or screenshots are fine)

Both commands are read-only and safe.

At this stage, all evidence points to a Windows SMB client issue on that specific PC, not a disk, RAID, or ZimaOS data-integrity problem.
The logs will confirm whether the server reports a timeout or connection reset at file close.

No signs so far indicate data loss or failing drives.