I’m running Jellyfin on a Debian-server in my home, and I have the associated media folders set up as samba shares so that I can transfer any new media from my laptop to the server through Dolphin (KDE file manager).
This has for the most part worked very well (except slow speeds), but I’ve had an issue recently where the files are not copied over properly. This resulted in glitches in for example music files that would stop playback. I checked the checksums of some of these files, and they were different from source. Seems like the glitchy files are missing some data, but at no point were I notified about this. It works fine after I removed the files and transferred again, and now the checksums match.
Is this a common issue with samba, or could it be a sign that my HDD is acting up?
If you’re transferring Linux to Linux then I really wouldn’t recommend samba. Why not SFTP/Rsync? Compression, and error checking built in.
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?
The only thing Samba is really great for is interop with Windows. If that’s not an issue, Dolphin can browse SFTP directly by adding it as a network share (you may need to setup a password-less key pair to avoid having to login). SSHFS is a similar option and works even if the client is totally naive (it just looks like any other mounted FS).
I don’t know if samba has any error checking built in, so it may be even down to wonky network.
I would try doing a copy using rsync or ssh (sftp - you can use dolphin for that too), and see if that helps.
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.
Apart from copying the files again after comparing the checksums what else have you done to troubleshoot the issue? Have you looked at logs, run fsck or anything?
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.
It is not common at all no. Is your network between the 2 machines wired ethernet or wifi?
rysnc might be a faster and more reliable option. It can compress the files for transfer and does checksums after the transfer is complete
I used something like this to transfer 12 TB from offsite to onsite with zero failures
rsync -arvzip --progress /path/to/host /path/to/destination
You can set up a screen and let this run in the background all the time
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.
Thanks for sharing! I’m a pure headless Linux user, so I don’t know much about desktop environments
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.
Depending on your file structure, you could probably keep this running all the time so you don’t have to manually intervene in the future
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.
