Looking for some advice on where to start looking for this one, especially as it doesn't always happen and can't manually repeat it.

At time, when I have a larger file transfer (some of my VM backups in Proxmox are 60+ gigs) will cause Unraid to be inaccessible during that transfer, or at least mostly. For instance, my Plex LXC continues to work, but my Immich VM loses connection to the SMB share and needs to be rebooted. These happen during the night, so I'm not on it to see anything while it's happening.

Today though, I was copying a folder from Unraid that was about 100gb, and it happened during that. The normal things lost connection, though admittedly I forgot to check Plex, but also the Unraid web interface was inaccessible and I had to SSH to it to reboot it. The transfer continued while it was inaccessible and finished. I tried to recreate that after the reboot, but it worked fine.

I downloaded logs, but really not sure where to start here.

Thank you!

EDIT: I mention Proxmox, but Unraid in not in a VM, it runs on it's own machine. That machine is an i7-7700, some Asus board, 16gb mem. Disks are connected by an LSI 9207 in IT mode in an EMC disk shelf.

Edited June 7Jun 7 by Thestillman

You mention Proxmox. Are you running Unraid as a VM?

6 minutes ago, trurl said:

You mention Proxmox. Are you running Unraid as a VM?

Sorry, should've mentioned that! No, Unriad is on it's own machine, an i7-7700 if that matters.

Attach Diagnostics ZIP to your NEXT post in this thread.

next time you run a transfer open an ssh session and type in top and look for the wa: stat in the middle, if this number goes above 30.0 you have IO Wait issues.

1 hour ago, trurl said:

Attach Diagnostics ZIP to your NEXT post in this thread.

That is attached.

1 hour ago, MowMdown said:

next time you run a transfer open an ssh session and type in top and look for the wa: stat in the middle, if this number goes above 30.0 you have IO Wait issues.

I did this with a transfer from Unraid and one to it. Both bounced round mid to upper 20s, the from transfer hit 30.x a couple times and 32, the to transfer hit low 30s and 37 once.

neith-diagnostics-20260607-1529.zip

Unrelated, your appdata and system shares are on the array, and configured to be moved to the array. Better if docker/VM related shares - appdata, domains, system - are on cache or other pool with nothing on the array, so docker/VM will perform better, and so array disks can spin down since these files are always open. Nothing can move open files, so you will have to disable Docker and VM Manager in Settings before these shares can be moved

6 hours ago, Thestillman said:

mid to upper 20s, the from transfer hit 30.x a couple times and 32, the to transfer hit low 30s and 37

Assuming you mean MB/s, a little slow but not unexpected for writes to the array. Are you writing to a cached user share? Have you tried turbo (reconstruct write)?

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/overview/#array-write-modes

16 hours ago, Thestillman said:

That is attached.

I did this with a transfer from Unraid and one to it. Both bounced round mid to upper 20s, the from transfer hit 30.x a couple times and 32, the to transfer hit low 30s and 37 once.

neith-diagnostics-20260607-1529.zip

You seem to also have a docker container bootlooping, this could be causing issues too. And there also seems to have been issues with SMB in the previous-syslog.

Jun  6 04:45:02 Neith smbd[1668657]: [2026/06/06 04:45:02.036713,  0] ../../lib/util/util.c:580(dump_data)
Jun  6 04:45:02 Neith smbd[1668657]:   [0000] 6E EE 66 D2 7F 73 B2 1E   D0 7D 62 71 43 6F B6 EC   n.f..s.. .}bqCo..
Jun  6 04:45:02 Neith smbd[1668657]: [2026/06/06 04:45:02.036729,  0] ../../lib/util/util.c:580(dump_data)
Jun  6 04:45:02 Neith smbd[1668657]:   [0000] FF E3 00 E9 2E 5D C7 BC   90 D4 67 32 D9 01 9D 03   .....].. ..g2....
Jun  6 04:45:02 Neith smbd[1668657]: [2026/06/06 04:45:02.036930,  0] ../../libcli/smb/smb2_signing.c:646(smb2_signing_check_pdu)
Jun  6 04:45:02 Neith smbd[1668657]:   Bad SMB2 (sign_algo_id=1) signature for message

Im not sure what this means, but it's basically the entire log which might explain the poor performance?

11 hours ago, trurl said:

Assuming you mean MB/s, a little slow but not unexpected for writes to the array. Are you writing to a cached user share? Have you tried turbo (reconstruct write)?

This was referring to monitoring the wa value in top that MowMdown suggested.

11 hours ago, trurl said:

Unrelated, your appdata and system shares are on the array, and configured to be moved to the array. Better if docker/VM related shares - appdata, domains, system - are on cache or other pool with nothing on the array, so docker/VM will perform better, and so array disks can spin down since these files are always open. Nothing can move open files, so you will have to disable Docker and VM Manager in Settings before these shares can be moved

Went ahead and changed this since that's quick to do.

52 minutes ago, MowMdown said:

You seem to also have a docker container bootlooping, this could be causing issues too. And there also seems to have been issues with SMB in the previous-syslog.

I'll look at this tonight and see if I can find what is doing that.

Thank you both! I'll be checking around tonight and monitoring this week.