Initial Experience Using Syncthing - CIFS/Samba Issues

User Stories
#1

TL;DR - If shared folder has to be on a network mount use NFS over CIFS to avoid issues.

So inititally, when I first fired up Syncthing I added 3 nodes (laptop, desktop, and NAS). However, my NAS kept on throwing out errors like in the link above. All it said was “Drive readdirent no such file or directory” and pretty much nothing else. Other issues included:

  • Rescan kept on failling
  • Files were randomly being deleted from the NAS
  • Files would sometime would reappear hours later

No issues with only the desktop and laptop online. Just the NAS causing all the issues. The initial sync goes without a hitch, and about a few hours later that’s when the issues start to come up. After reading through some old threads, it seems like the location of my shared folder was the issue. It sat on a CIFS mount. The fix turned out to be, to turn it into an NFS mount instead. Not sure if this is expected behaviour because it’s not mentioned in the documentation. Is CIFS just bad?

I was reading in other threads where it said that SAMBA/CIFS shouldn’t be an issue. If I’m doing something wrong though it would be great to hear suggestions. I’ll explain my setup the best I can below. I thought I’d share in case anyone else runs into this situation.

  1. Using Openmediavault with Docker.
  2. Using the linuxserver/syncthing image (1.12.0).
  3. NAS (1) mounted a shared folder of another NAS (2) for syncthing.
  4. Syncthing config files stayed on NAS (1).

After switching the mount from CIFS to NFS, all seems to be working fine now.

#2

Best solution, but I assume that’s not possible: Run Syncthing on NAS (2), i.e. on local storage, not a network drive of any kind.

For the specific issue here my post from the thread you linked should still be accurate:

2 Likes
#3

Oh, that makes a lot more sense now. Re-read your posts. So it’s a Golang issue and not at all Syncthing. If I have it correct, I guess in my scenario I would have to wait for the linuxserver/syncthing maintainer to update the build using go 1.16 when it comes out?

#4

I have never before heard of a case where deploying NFS reduced the number of problems. I’d suggest to keep on the lookout - SMB needs fairly constant attention to keep working, but NFS usually needs it in order not to blow up in your face.

1 Like
#5

If you use our builds, we usually upgrade on the first Syncthing release after it has come out (barring problems, which usually don’t happen).

Just want to give a counter-experience: I am running both samba and nfs on my debian homeserver since years without any attention and both work flawlessly (I do however also run Syncthing on the homeserver, not on a client pointing at a network share).

1 Like
#6

This is might be your experience with some specific device, but generally this is false advice.

There are barely any sensible cifs implementations outside of Windows, where as NFS has quality implementations on all platforms I am aware.

2 Likes
#7

Can I throw in iSCSI and DRBD into the mix? While we’re talking about unreliable crap that will blow up in your face? :bomb:

2 Likes
#8

My argument wasn’t that SMB was better, it was simply that both are prone to failure, and that when they fail NFS tends to do so much, much more spectacularly. (Let’s just say there’s a reason root squash is a thing.)

2 Likes