Its not like first time I have noticed, that huge file copying over network can result in errors.

From what I have seen during file copy sometimes, speed goes to zero, and then it comes to software can it handle it and wait to retry, or fail.

Here example case.

Local Windows 10 machine file backup to network share, via MacriumReflect.

Apr  2 20:12:41 SHAPXUB smbd[7525]: [2026/04/02 20:12:41.202711,  0] ../../source3/smbd/durable.c:928(vfs_default_durable_reconnect)
Apr  2 20:12:41 SHAPXUB smbd[7525]:   vfs_default_durable_reconnect: default_durable_reconnect_fn [GAMES--2026-04-02T18.33.49--00-00.mrbak.tmp] failed: NT_STATUS_OBJECT_NAME_NOT_FOUND

durable reconnect code is shown here https://github.com/avati/samba/blob/e24fe5705e3c4d33705ebb584ea2009bb4a1a82c/source3/modules/vfs_default.c#L2429

I'm here more for advice, where to start investigation. Which kind of settings to check.

---

And it fails in Macrium when task processes these files. https://forums.unraid.net/topic/198087-smb-drops-connections-on-long-file-transfers-and-on-certain-zip-files/#findComment-1624535

diagnostics-20260402-2054.zip

Edited May 24May 24 by apx

Literally just now.

I'm suspecting that my NIC in NAS goes down and re-appears.

Like there are ton of write event, and whoops network interface appeared.

New diagnostics added. After event occurred.

diagnostics-20260402-2229.zip

Edited April 2Apr 2 by apx

Please disable Samba extended log, it causes a lot of spam and is missing the last lines, then reboot and post new diags after a fialed trsnafger, if the issue is on the Unraid side, normal log will do.

3 hours ago, JorgeB said:

Please disable Samba extended log, it causes a lot of spam and is missing the last lines, then reboot and post new diags after a fialed trsnafger, if the issue is on the Unraid side, normal log will do.

Here are logs just after event.

I start to see pattern, with 1 hour and 10 minutes.

shapxub-diagnostics-20260403-1334.zip

I'm afraid there's nothing logged on the Unraid side, suggesting it's an issue with the client or the network.

1 minute ago, JorgeB said:

I'm afraid there's nothing logged on the Unraid side, suggesting it's an issue with the client or the network.

I had SAMBA logs enabled previously, and monitored whole transfer.

And those adding interface messages lead me to think, could this be interface bonding/bridging issue?

I guess if interface were dropping, this would be obvious in logs.

Probably will try to crank power mode to Best Performance, and see if it's better compared to Balanced.

Could be also a thing when one SMB transfer is going, and some app tries to check network location, maybe in certain conditions it may have some impact.

From few more tests, it seems Macrium Reflect doesn't handle those long file transfers straight to network disk.

While VEEAM Agent handles this better.

Also have seen posts where Macrium users mentioned that they do backups usually firstly disk to disk, and later move those images with more robust and reliable copy methods.

Strange discovery, when backing up files with Macrium from W10 machine to Unraid, noticed that tasks fail on certain files/folders.

And those even fail if I move files/rename long path to smaller one/rename end ZIPs to simple numbers.

More confusion adds fact that 1000+ zips - FAILS, and 1000 is fine. Like literally those 100 are bad apples. (Okay 1000+1000 also fails)

Even if I ZIP all those 1100 into single one, copying this to NAS fails as well.

Zipped 1000 into one piece also goes smooth.

Whaaaa.

Could this be an issue because NAS runs with 4GB of RAM?

While dashboard reports its barely utilized, otherwise I cannot come with anything why this strange scenarios may happens.

Edited May 17May 17 by apx

Here is uncertain thing.

I managed to narrow it down to particular ZIP files. (like similar was mentioned also for TrueNas - https://www.truenas.com/community/threads/copying-odd-zip-or-msi-file-causing-smb-service-to-freeze.87066/ )

(if those are repacked to 7Z it's all good and smooth)

Like if such files is copied to NAS, transfer hangs a bit and becomes unresponsive.

What would be proper way to pinpoint why system hangs during such file process? SMB log level, or there are other ways which may help?

That suggests to me an antivirus or similar is interfering with the files on the source

Heard this opinion too, tried to disable it, but same story.

It's just 2 ZIP files from thousands similar. One had whitespaces in archive content filenames, but doubt it had something to do with it.

With expanded SMB logs, process has these events. Those 65536 values doesn't look right, like it could be some kind of limit.

May 24 13:10:14 SHAPXUB smbd[12701]: [2026/05/24 13:10:14.900685,  3] ../../source3/smbd/smb2_write.c:214(smb2_write_complete_internal)
May 24 13:10:14 SHAPXUB smbd[12701]:   smb2: fnum 902811720, file New Folder/2 - fail.zip, length=65536 offset=11534336 wrote=65536
May 24 13:10:14 SHAPXUB smbd[12701]: [2026/05/24 13:10:14.900927,  3] ../../source3/smbd/smb2_write.c:214(smb2_write_complete_internal)
May 24 13:10:14 SHAPXUB smbd[12701]:   smb2: fnum 902811720, file New Folder/2 - fail.zip, length=65536 offset=10027008 wrote=65536
May 24 13:10:14 SHAPXUB smbd[12701]: [2026/05/24 13:10:14.901193,  3] ../../source3/smbd/smb2_write.c:214(smb2_write_complete_internal)
May 24 13:10:14 SHAPXUB smbd[12701]:   smb2: fnum 902811720, file New Folder/2 - fail.zip, length=65536 offset=11599872 wrote=65536
May 24 13:10:14 SHAPXUB smbd[12701]: [2026/05/24 13:10:14.901430,  3] ../../source3/smbd/smb2_write.c:214(smb2_write_complete_internal)
May 24 13:10:14 SHAPXUB smbd[12701]:   smb2: fnum 902811720, file New Folder/2 - fail.zip, length=65536 offset=10485760 wrote=65536
May 24 13:10:14 SHAPXUB smbd[12701]: [2026/05/24 13:10:14.901713,  3] ../../source3/smbd/smb2_write.c:214(smb2_write_complete_internal)
May 24 13:10:14 SHAPXUB smbd[12701]:   smb2: fnum 902811720, file New Folder/2 - fail.zip, length=65536 offset=10092544 wrote=65536
May 24 13:10:14 SHAPXUB smbd[12701]: [2026/05/24 13:10:14.901926,  3] ../../source3/smbd/smb2_write.c:214(smb2_write_complete_internal)
May 24 13:10:14 SHAPXUB smbd[12701]:   smb2: fnum 902811720, file New Folder/2 - fail.zip, length=65536 offset=11665408 wrote=65536
May 24 13:10:14 SHAPXUB smbd[12701]: [2026/05/24 13:10:14.902185,  3] ../../source3/smbd/smb2_write.c:214(smb2_write_complete_internal)
May 24 13:10:14 SHAPXUB smbd[12701]:   smb2: fnum 902811720, file New Folder/2 - fail.zip, length=65536 offset=10551296 wrote=65536

Edited May 24May 24 by apx

Here are samples (https://gofile.io/d/ynZJ8m). Maybe someone else can reproduce it on their end, and see what's wrong with the files.

TLDR

- original files FAIL to copy. (rarely it goes through) (Store method)

- repacked files FAIL if STORE compression method is used.

- repacked file PASSes if DEFLATE method is used.

Edited May 24May 24 by apx

65536 bytes = 64 KiB, this is a standard SMB2/SMB3 write chunk size, not a limit being hit.

Try adding this to SMB Extras:

veto oplock files = /*.zip/*.MSI/*.msi/*.ZIP/

7 minutes ago, JorgeB said:

veto oplock files = /*.zip/*.MSI/*.msi/*.ZIP/

Unfortunately - same story.

I think you will just need to try and get those files in a different format

Just now, JorgeB said:

I think you will just need to try and get those files in a different format

True, but would be great to figure out the reason.

Because such files bork also network backups as mentioned in initial post. So you run backup, and it fails due to certain files.

Had encountered same issue when made Game folder backup.

Still would try to gather more evidence.

Maybe more samples can help.

FWIW, I can copy all the sample files from my Windows desktop to an Unraid share

root@Tower7:~# ls -l /mnt/user/Temp/test

total 154496

-rwxrw-rw- 1 user users 28673056 May 17 21:56 1\ -\ fail\ (ORIGINAL\ FILE).zip*

-rwxrw-rw- 1 user users 28673056 May 24 10:24 1\ -\ fail\ (ZIP\ repacked\ -\ Store\ method).zip*

-rwxrw-rw- 1 user users 28364023 May 24 10:26 1\ -\ pass\ (ZIP\ repacked\ -\ Deflate\ method).zip*

-rwxrw-rw- 1 user users 28381062 May 17 20:48 1\ -\ pass\ (ZIP\ repacked\ to\ 7Z).7z*

-rwxrw-rw- 1 user users 13269448 Mar 15 2024 2\ -\ fail\ (ORIGINAL\ FILE).zip*

-rwxrw-rw- 1 user users 13269448 May 24 10:30 2\ -\ fail\ (ZIP\ repacked\ -\ Store).zip*

-rwxrw-rw- 1 user users 13046221 May 24 10:29 2\ -\ pass\ (ZIP\ repacked\ -\ Deflate).zip*

Funny, i did run into this issue as well. With a encrypted fully compressed multi part (50gb chunks) rar archive

May 24 14:15:44 Magnon-Box smbd[1894656]: [2026/05/24 14:15:44.407591, 0] ../../source3/smbd/durable.c:951(vfs_default_durable_reconnect) May 24 14:15:44 Magnon-Box smbd[1894656]: vfs_default_durable_reconnect: default_durable_reconnect_fn [Archive/rar/Archive.part16.rar] failed: NT_STATUS_OBJECT_NAME_NOT_FOUND

The file was absolutely present in the time of that error.
Now, i think the original file in that particular archive, also gave me that error. although that was a massive 300gb single zip. Ive no clue what upsets it, i just loaded the files onto a usb external drive and dumped it that way unto unraid. Hella annoying tho.

On my end, if these bad apple file are inside another archive or other file this also breaks transfers.

In this long ongoing topic, people report that bonding network cards may help.

When I tried to tinker with network adapter settings, I only managed to bork entire config, and had to reset)

Plus it's already sounds strange, why 2 network adapters would affect certain file transfer.

https://forums.unraid.net/topic/79454-file-transfer-results-in-error-0x8007003b/

@JorgeB Whats your environment, Windows 11 ?

Edited May 25May 25 by apx

The test was made from Windows 10 Pro

9 minutes ago, JorgeB said:

The test was made from Windows 10 Pro

Could you drop what's your SMB config in OS. (powershell - Get-SmbServerConfiguration)

Mine:

AnnounceComment :

AnnounceServer : False

AsynchronousCredits : 64

AuditSmb1Access : False

AutoDisconnectTimeout : 15

AutoShareServer : True

AutoShareWorkstation : True

CachedOpenLimit : 10

DurableHandleV2TimeoutInSeconds : 180

EnableAuthenticateUserSharing : False

EnableDownlevelTimewarp : False

EnableForcedLogoff : True

EnableLeasing : True

EnableMultiChannel : True

EnableOplocks : True

EnableSecuritySignature : False

EnableSMB1Protocol : False

EnableSMB2Protocol : True

EnableStrictNameChecking : True

EncryptData : False

IrpStackSize : 15

KeepAliveTime : 2

MaxChannelPerSession : 32

MaxMpxCount : 50

MaxSessionPerConnection : 16384

MaxThreadsPerQueue : 20

MaxWorkItems : 1

NullSessionPipes :

NullSessionShares :

OplockBreakWait : 35

PendingClientTimeoutInSeconds : 120

RejectUnencryptedAccess : True

RequireSecuritySignature : False

ServerHidden : True

Smb2CreditsMax : 2048

Smb2CreditsMin : 128

SmbServerNameHardeningLevel : 0

TreatHostAsStableStorage : False

ValidateAliasNotCircular : True

ValidateShareScope : True

ValidateShareScopeNotAliased : True

ValidateTargetName : True

Edited May 25May 25 by apx

PS C:\WINDOWS\system32> Get-SmbServerConfiguration

AnnounceComment :

AnnounceServer : False

AsynchronousCredits : 64

AuditSmb1Access : False

AutoDisconnectTimeout : 15

AutoShareServer : True

AutoShareWorkstation : True

CachedOpenLimit : 10

DurableHandleV2TimeoutInSeconds : 180

EnableAuthenticateUserSharing : False

EnableDownlevelTimewarp : False

EnableForcedLogoff : True

EnableLeasing : True

EnableMultiChannel : True

EnableOplocks : True

EnableSecuritySignature : False

EnableSMB1Protocol : False

EnableSMB2Protocol : True

EnableStrictNameChecking : True

EncryptData : False

IrpStackSize : 15

KeepAliveTime : 2

MaxChannelPerSession : 32

MaxMpxCount : 50

MaxSessionPerConnection : 16384

MaxThreadsPerQueue : 20

MaxWorkItems : 1

NullSessionPipes :

NullSessionShares :

OplockBreakWait : 35

PendingClientTimeoutInSeconds : 120

RejectUnencryptedAccess : True

RequireSecuritySignature : False

ServerHidden : True

Smb2CreditsMax : 2048

Smb2CreditsMin : 128

SmbServerNameHardeningLevel : 0

TreatHostAsStableStorage : False

ValidateAliasNotCircular : True

ValidateShareScope : True

ValidateShareScopeNotAliased : True

ValidateTargetName : True

2 hours ago, apx said:

On my end, if these bad apple file are inside another archive or other file this also breaks transfers.

In this long ongoing topic, people report that bonding network cards may help.

When I tried to tinker with network adapter settings, I only managed to bork entire config, and had to reset)

Plus it's already sounds strange, why 2 network adapters would affect certain file transfer.

https://forums.unraid.net/topic/79454-file-transfer-results-in-error-0x8007003b/

@JorgeB Whats your environment, Windows 11 ?

The windows machine had in this case 2 Nics, didnt change anything

May 6 10:26:25 Magnon-Box smbd[2168712]: [2026/05/06 10:26:25.696302, 0] ../../source3/smbd/smb2_read.c:265(smb2_sendfile_send_data)

May 6 10:26:25 Magnon-Box smbd[2168712]: smb2_sendfile_send_data: sendfile failed for file Archive/Archive.part20.rar (Connection reset by peer) for client PID=2168712,CLIENT=REDACTED,channel=2,remote=ipv6:fd0>

May 6 10:26:25 Magnon-Box smbd[965126]: [2026/05/06 10:26:25.804240, 0] ../../source3/smbd/durable.c:951(vfs_default_durable_reconnect)

May 6 10:26:25 Magnon-Box smbd[965126]: vfs_default_durable_reconnect: default_durable_reconnect_fn [Archive/Archive.part20.rar] failed: NT_STATUS_OBJECT_NAME_NOT_FOUND

May 6 23:59:26 Magnon-Box smbd[1542941]: [2026/05/06 23:59:26.039488, 0] ../../source3/smbd/smb2_read.c:265(smb2_sendfile_send_data)

May 6 23:59:26 Magnon-Box smbd[1542941]: smb2_sendfile_send_data: sendfile failed for file Archive/Archive.part20.rar (Connection reset by peer) for client PID=1542941,CLIENT=REDACTED,channel=2,remote=ipv6:fd0>

May 6 23:59:26 Magnon-Box smbd[144767]: [2026/05/06 23:59:26.101105, 0] ../../source3/smbd/durable.c:951(vfs_default_durable_reconnect)

May 6 23:59:26 Magnon-Box smbd[144767]: vfs_default_durable_reconnect: default_durable_reconnect_fn [Archive/Archive.part20.rar] failed: NT_STATUS_OBJECT_NAME_NOT_FOUND

This error came from another a whole different platform as the 2 above

4 hours ago, Mainfrezzer said:

May 24 14:15:44 Magnon-Box smbd[1894656]: [2026/05/24 14:15:44.407591, 0] ../../source3/smbd/durable.c:951(vfs_default_durable_reconnect) May 24 14:15:44 Magnon-Box smbd[1894656]: vfs_default_durable_reconnect: default_durable_reconnect_fn [Archive/rar/Archive.part16.rar] failed: NT_STATUS_OBJECT_NAME_NOT_FOUND

Edit:

i did test around. It seems like the issue appears only when you write to the array and my best guess is extrem IO wait that screws it over. Now, why it happens to specific file types, thats the question

Edited May 26May 26 by Mainfrezzer