I am getting conflicts every time a file is modified by one user.
I have set up syncs with 3 machines, A(Windows 10) is remote, B(Windows 10) is local with C(Linux Mint). A connects to B. B connects to C.
When the user modifies a file on B it generates a conflict. If I disconnect C this does not happen.
I tried setting the folder on C to receive only. In this case conflicts appear in the folder on C but of course don’t get replicated on B. I originally thought the conflict was generated by B because it is B’s device ID appearing on the file name.
The other thing I noticed is it says “Local Additions” on machine C’s web page (even though there wasn’t any user activity on this machine).
One additional point if relevant - machine C (Linux) is using ntfs as the file system for the partition containing the shared folder.
All I’m doing on C is looking at the folder with a file manager. I’ve read the other conflict topics on this forum but they didn’t seem to help.
How do I find/rectify the cause? If I can’t, unfortunately this is a show stopper for me.
Many thanks for the quick response. Yes I think it is the non-native NTFS driver. I use it because I multi-boot Windows and Linux on this PC and I sometimes want to use Windows on the same files. So far I’ve got away with it. It’s a pity there isn’t a filesystem which is officially supported by both OS’s.
So I’ve moved the Syncthing folders to an Ext4 partition and all is well. I can install Syncthing on the multibooted Windows instance although this means duplicating the files. As it happens I have enough space so it’s not a big problem.
Incidentally I had to do this with Dropbox (which I’m trying to replace) as I used to use NTFS for that, but then a couple of years ago they refused to work with NTFS on Linux so I had to duplicate the Dropbox files on an Ext4 partition. The daily changes aren’t big so I can work with it.
I have another slight issue which I will put on a different post, but this issue is resolved albeit not as I would have ideally preferred.
The takeaway for anyone reading this thread is that using the ntfs driver on Linux causes conflicts.
I have to rely on my memory because the files have been deleted now. I start with a simple text file which is identical on both machines. The one on the Linux box has been synced from the Windows box. Nothing was done to the file on the Linux box.
Then I add a bit of text to the file on the Windows box and save it. The Linux box then shows 2 files. The pre-updated one renamed as a conflict and the new version synced from the Windows machine.
@imsodin I have another Linux box here with ntfs-3g partitions so I installed Syncthing on this and tried to sync from Windows. I had the same conflicts. Definitely some issue with my Linux systems and Syncthing.
The ntfs filesystem might well be a/the factor here, I just wanted to stress that ntfs-3g isn’t generally problematic - it usually just works.
To know what happens we’d need to know about any difference between the created conflict copies and/or debug logs from when the conflicts are created (secondary).
More experiments - edited a file a few more times and a couple of times there was no conflict but mostly there was.
I made a copy of the file which synced ok. Then I edited the file on the Windows machine, which produced a conflict file and diffed the synced copy with the original’s sync conflict file - there was no difference.
Terminal log below (don’t see an option to attach a file). Is there a debug mode which produces a debug log?
> [start] 08:38:08 INFO: syncthing v1.17.0 "Fermium Flea" (go1.16.4 linux-amd64) deb@build.syncthing.net 2021-05-22 19:38:49 UTC [noupgrade]
> [PFVDA] 08:38:08 INFO: My ID: PFVDAN7-RZZGFFP-EW6YWKA-7NOPKO5-UXIDRKA-CQF7SJ7-SGTLSUL-APLLBQR
> [PFVDA] 08:38:09 INFO: Single thread SHA256 performance is 386 MB/s using minio/sha256-simd (385 MB/s using crypto/sha256).
> [PFVDA] 08:38:10 INFO: Hashing performance is 328.12 MB/s
> [PFVDA] 08:38:10 INFO: Overall send rate is unlimited, receive rate is unlimited
> [PFVDA] 08:38:10 INFO: Using discovery mechanism: global discovery server https://discovery.syncthing.net/v2/?noannounce&id=LYXKCHX-VI3NYZR-ALCJBHF-WMZYSPK-QG6QJA3-MPFYMSO-U56GTUK-NA2MIAW
> [PFVDA] 08:38:10 INFO: Using discovery mechanism: global discovery server https://discovery-v4.syncthing.net/v2/?nolookup&id=LYXKCHX-VI3NYZR-ALCJBHF-WMZYSPK-QG6QJA3-MPFYMSO-U56GTUK-NA2MIAW
> [PFVDA] 08:38:10 INFO: Using discovery mechanism: global discovery server https://discovery-v6.syncthing.net/v2/?nolookup&id=LYXKCHX-VI3NYZR-ALCJBHF-WMZYSPK-QG6QJA3-MPFYMSO-U56GTUK-NA2MIAW
> [PFVDA] 08:38:10 INFO: Using discovery mechanism: IPv4 local broadcast discovery on port 21027
> [PFVDA] 08:38:10 INFO: Using discovery mechanism: IPv6 local multicast discovery on address [ff12::8384]:21027
> [PFVDA] 08:38:10 INFO: TCP listener ([::]:22000) starting
> [PFVDA] 08:38:10 INFO: Relay listener (dynamic+https://relays.syncthing.net/endpoint) starting
> [PFVDA] 08:38:10 INFO: QUIC listener ([::]:22000) starting
> [PFVDA] 08:38:10 INFO: Ready to synchronize "IT-Tech-TrPC" (kgejc-s9ilm) (sendreceive)
> [PFVDA] 08:38:10 INFO: GUI and API listening on 127.0.0.1:8384
> [PFVDA] 08:38:10 INFO: Access the GUI via the following URL: http://127.0.0.1:8384/
> [PFVDA] 08:38:10 INFO: My name is "orac"
> [PFVDA] 08:38:10 INFO: Device VBA7INK-W3CNG45-MCYR5YX-QKRZUZH-PEAEVGA-6ZFBRLR-V57EXL5-IIS26AL is "zeta" at [dynamic]
> [PFVDA] 08:38:10 INFO: Completed initial scan of sendreceive folder "IT-Tech-TrPC" (kgejc-s9ilm)
> [PFVDA] 08:38:11 INFO: Established secure connection to VBA7INK-W3CNG45-MCYR5YX-QKRZUZH-PEAEVGA-6ZFBRLR-V57EXL5-IIS26AL at 192.168.1.34:22000-192.168.1.12:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
> [PFVDA] 08:38:11 INFO: Device VBA7INK-W3CNG45-MCYR5YX-QKRZUZH-PEAEVGA-6ZFBRLR-V57EXL5-IIS26AL client is "syncthing v1.17.0" named "zeta" at 192.168.1.34:22000-192.168.1.12:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
> [PFVDA] 08:38:20 INFO: Detected 0 NAT services
> [PFVDA] 08:38:29 INFO: quic://0.0.0.0:22000 detected NAT type: Port restricted NAT
> [PFVDA] 08:38:29 INFO: quic://0.0.0.0:22000 resolved external address quic://81.97.108.32:59120 (via stun.syncthing.net:3478)
> [PFVDA] 08:38:44 INFO: Joined relay relay://185.181.160.45:22067
> [PFVDA] 08:40:59 INFO: Puller (folder "IT-Tech-TrPC" (kgejc-s9ilm), item "temp/test1.txt"): syncing: file modified but not rescanned; will try again later
> [PFVDA] 08:40:59 INFO: "IT-Tech-TrPC" (kgejc-s9ilm): Failed to sync 1 items
> [PFVDA] 08:40:59 INFO: Folder "IT-Tech-TrPC" (kgejc-s9ilm) isn't making sync progress - retrying in 1m0s.
> [PFVDA] 08:44:00 INFO: Puller (folder "IT-Tech-TrPC" (kgejc-s9ilm), item "temp/test1.txt"): syncing: file modified but not rescanned; will try again later
> [PFVDA] 08:44:00 INFO: "IT-Tech-TrPC" (kgejc-s9ilm): Failed to sync 1 items
> [PFVDA] 08:44:00 INFO: Folder "IT-Tech-TrPC" (kgejc-s9ilm) isn't making sync progress - retrying in 1m0s.
> [PFVDA] 08:46:56 INFO: Puller (folder "IT-Tech-TrPC" (kgejc-s9ilm), item "temp/test1.txt"): syncing: file modified but not rescanned; will try again later
> [PFVDA] 08:46:56 INFO: "IT-Tech-TrPC" (kgejc-s9ilm): Failed to sync 1 items
> [PFVDA] 08:46:56 INFO: Folder "IT-Tech-TrPC" (kgejc-s9ilm) isn't making sync progress - retrying in 1m0s.
> [PFVDA] 08:51:14 INFO: Puller (folder "IT-Tech-TrPC" (kgejc-s9ilm), item "temp/test1.txt"): syncing: file modified but not rescanned; will try again later
> [PFVDA] 08:51:14 INFO: "IT-Tech-TrPC" (kgejc-s9ilm): Failed to sync 1 items
> [PFVDA] 08:51:14 INFO: Folder "IT-Tech-TrPC" (kgejc-s9ilm) isn't making sync progress - retrying in 1m0s.
Suggest you try ntfs-3g, as it seems like the ntfs in fstab actually refers to an ancient kernel module which supposedly should be read only: https://serverfault.com/a/304357
Effectively, I feel it’s down to the file system to misbehaving here, and potentially not preserving some attributes we care about (or lying saying that it did preserve them), leading to conflicts.
What’s in the kernel now is indeed ancient and afaik read-only (but apparently not). NTFS-3G is the defacto standard right now and works well. There is a new patch for ntfs kernel support in the works, but a quick search showed that it hasn’t landed yet (but is still in active review/development).
And on ntfs, I always ignore permissions in Syncthing. Though both changes in permission and modification time only shouldn’t ever create a sync conflict file.
This is getting into realms beyond my experience. I suggest leaving this now and waiting to see if anyone else has the same problem. I have worked around by using syncthing with the ext4 file system, so I am happy to continue this way. But if you want any more info I can give please ask.