Linux

Samba shuffles rather a lot of data, quite happily. You have not given us an exhaustive description of the shoddy wiring, dodgy switches and wonky configuration that makes up your network. If it was perfect, you would not be posting here.

The network is by no means ideal. I am transferring from a laptop on WiFi to a server on WiFi located some distance from the WAP. If I owned the place I would do a rewire, but for now it's the best I can do. I think I assumed that there would be error-checking involved when copying. Since following the advice here of using rsync i stead, I have found that files tend to fail in bunches and I need to rerun several times for it to actually complete. Am I right to assume that comes down to packet loss due to poor signal?

Your issue is probably hardware related. Test your network with say iperf3. Have a look at network stats. Don’t rely on cargo cult bollocks - do some investigations. Nowadays we have nearly all the tools as open source to do the entire job - we did not have that 30 years ago. Grab wireshark, nmap, mtr and the rest and get nerdy (or hire me to do it - don’t do that please!)

This is above my skill level for now, but I'm adding it to my notes to go back to. I have some ambition of upping my network knowledge in the coming year, and being able to do use such tools to troubleshoot would be great.

I think I will go with rsync for future transfers, but I would like for it to be browsable through the file browser still. Is there a better way than samba I should consider? I guess it is not an issue just keeping them as samba shares for that purpose?

rsync was written by one of the original Samba developers. I wonder if Tridge and co have any idea about how to shuffle data from A to B safely?

CIFS/SMB will only indicate received and not received and written. This is unlikely to be an issue.

I would start by proving that my network works properly, especially that dodgy cable with only wires 1,2,3,7 connected - because that's all 100Mb/s needs, or the solid core cable that runs for 150m with plugs at each end instead of sockets and drop leads.

and since op is using kde, they can use a konsole with dolphin to drag and drop /path/to/host and /path/to/destination as well.

I tried to resync now, and had to pass the -c flag to make sure it checked the cheksums to see if they should be updated. Then it worked. Looks like that does not affect the after-transfer checksum check though, so that's good (from documentation):

Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer lqDoes this file need to be updated?rq check. 

Thanks! Glad to know rsync includes check after transfer, as I've just recently used it to backup everything on these drives to another hard drive that will not always be spinning. But I did not consider using it to transfer new media onto these hard drives.

I'll try to use it to resync the files that were acting up.

Both machines are WiFi-connected.

Yes, I should have specified that.

I am unsure what logs to look at for this and have not done any filesystem check on the harddrive as I am unfamiliar with these tools. It's an external Seagate HDD with an ext4 filesystem.