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?

  • SquiffSquiff@lemmy.world
    4·
    11 days ago

    If you’re transferring Linux to Linux then I really wouldn’t recommend samba. Why not SFTP/Rsync? Compression, and error checking built in.

    • cyberwolfie@lemmy.mlOP
      1·
      11 days ago

      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?

  • eldavi@lemmy.ml
    2·
    11 days ago

    Is the “Dolphin” that you’re using the same dolphin that KDE uses as a gui file manager?

  • Bldck@beehaw.orgEnglish
    2·
    11 days ago

    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

    • cyberwolfie@lemmy.mlOP
      2·
      11 days ago

      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.

      • Bldck@beehaw.orgEnglish
        1·
        11 days ago

        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

          • Bldck@beehaw.orgEnglish
            2·
            11 days ago
            1. Open a screen
            2. Start an rsync job to maintain parity between source and destination
            3. Exit the screen, but keep it running
            4. Now rsync will be running in the background until you kill it

            You can reattach the screen whenever you want to check on status, change parameters or kill it

    • cyberwolfie@lemmy.mlOP
      2·
      11 days ago

      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.
    • eldavi@lemmy.ml
      2·
      11 days ago

      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.

      • Bldck@beehaw.orgEnglish
        2·
        11 days ago

        Thanks for sharing! I’m a pure headless Linux user, so I don’t know much about desktop environments

        • eldavi@lemmy.ml
          2·
          11 days ago

          i’m headless for servers too; but i’m foolish enough to use the x server as my daily driver. lol

  • gerdesj@lemmy.mlEnglish
    2·
    11 days ago

    “Is this a common issue with samba” - no.

    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.

    There is one snag with CIFS (Samba follows MS’s standards and ironically, I think that CIFS is now renamed back to SMB) that I am aware of, so SMB … snag: SMB will indicate that a chunk of data has been received successfully but not that it has been written to disc successfully. NFS will notify that a chunk of data has been written to disc.

    The difference is subtle but if there is not a battery backed RAID involved then SMB/CIFS can lose data if the system restarts part way through a write.

    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!)

    • cyberwolfie@lemmy.mlOP
      1·
      6 days ago

      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.

  • atimehoodie@lemmy.ml
    2·
    11 days ago

    Check if you get big memory spikes when transferring, or OOM entries in dmesg.

    Had some trouble with a new samba install on Debian causing OOM issues recently (this was admittedly in LXC). Resulted in files apparently transfered but were not. This was due to optimistic locks, which are apparently poorly implemented (according to the 2-year old open bug) but on by default. I haven’t done due diligence to say what’s the best solution, I just turned oplocks off.

    https://bugzilla.samba.org/show_bug.cgi?id=15261