Hey mates, I know this isn’t the first time this issue has arisen as I’ve been searching for a solution for the past few days. After testing everything I can possibly think of, I’ve just decided to post here and hope for the best.
A few days ago Syncthing stopped syncing on one of my devices, or would stop for long periods of time with the error shown below, then sometimes start back up with I’m guessing certain files, but not others. My setup is I have 1 Master/Parent Folder “Sync”, than is then shared with 2 devices/nodes/children. One device wasn’t having the syncing problem, but the other was. I’ve rebuilt the index’s on both machines a multitude of times, but never-the-less it would resurface. Today I decided to do a fresh install on all machines, and immediatly I’m run into the issue again.
I haven’t made any major changes so, not sure how this surfaced. Hope all can help. Here’s the log.
[UCBYU] 22:45:16 INFO: syncthing v0.14.15 “Dysprosium Dragonfly” (go1.7.4 windows-amd64) jenkins@build.syncthing.net 2016-12-17 11:39:22 UTC
[UCBYU] 22:45:16 INFO: My ID: UCBYUNC
[UCBYU] 22:45:17 INFO: Single thread hash performance is 101 MB/s using minio/sha256-simd (69 MB/s using crypto/sha256).
[UCBYU] 22:45:17 INFO: Ready to synchronize default (readwrite)
[UCBYU] 22:45:17 INFO: Using discovery server https://discovery-v4-2.syncthing.net/v2/?id=DVU36WY
[UCBYU] 22:45:17 INFO: Using discovery server https://discovery-v4-3.syncthing.net/v2/?id=VK6HNJ3
[UCBYU] 22:45:17 INFO: Using discovery server https://discovery-v4-4.syncthing.net/v2/?id=LYXKCHX
[UCBYU] 22:45:17 INFO: Using discovery server https://discovery-v6-2.syncthing.net/v2/?id=DVU36WY
[UCBYU] 22:45:17 INFO: TCP listener ([::]:22000) starting
[UCBYU] 22:45:17 INFO: Using discovery server https://discovery-v6-3.syncthing.net/v2/?id=VK6HNJ3
[UCBYU] 22:45:17 INFO: Using discovery server https://discovery-v6-4.syncthing.net/v2/?id=LYXKCHX
[UCBYU] 22:45:17 INFO: Completed initial scan (rw) of folder default
[UCBYU] 22:45:17 INFO: Device UCBYUNC is “TEHSEANO-PLEX” at [dynamic]
[UCBYU] 22:45:17 INFO: GUI and API listening on 127.0.0.1:8384
[UCBYU] 22:45:17 INFO: Access the GUI via the following URL: ht*tp://localhost:8384/
[UCBYU] 22:47:13 INFO: Connection from LFJUWAJ at 192.131.44.99:59726 (tcp-server) rejected: unknown device
[UCBYU] 22:48:13 INFO: Established secure connection to LFJUWAJ at 192.168.0.169:22000-192.131.44.99:47070 (tcp-server)
[UCBYU] 22:48:13 INFO: Device LFJUWAJ client is “syncthing v0.14.15” named “ulysses.whatbox.ca”
[UCBYU] 22:48:13 INFO: Unexpected folder “Sync” (mpu76-sabec) sent from device “LFJUWAJ”; ensure that the folder exists and that this device is selected under “Share With” in the folder configuration.
[UCBYU] 22:48:47 INFO: Ready to synchronize mpu76-sabec (readwrite)
[UCBYU] 22:48:47 INFO: Connection to LFJUWAJ closed: reading length: read tcp 192.168.0.169:22000->192.131.44.99:47070: use of closed network connection
[UCBYU] 22:49:13 INFO: Established secure connection to LFJUWAJ at 192.168.0.169:22000-192.131.44.99:35210 (tcp-server)
[UCBYU] 22:49:13 INFO: Device LFJUWAJ client is “syncthing v0.14.15” named “ulysses.whatbox.ca”
[UCBYU] 22:49:13 INFO: Device LFJUWAJ folder “Sync” (mpu76-sabec) has a new index ID (0xE8D03C68493EF1F2)
[UCBYU] 22:49:54 INFO: Completed initial scan (rw) of folder mpu76-sabec
[UCBYU] 22:55:18 INFO: Resurrecting directory \?\X:\Downloads\2.Broke.Girls.S06E11.HDTV.x264-LOL
[UCBYU] 22:55:49 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 22:55:49 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 22:56:49 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 22:57:49 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 22:58:49 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 22:59:49 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 23:00:49 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 23:01:50 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 23:02:50 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 23:03:41 INFO: Restarted folder mpu76-sabec (readwrite)
[UCBYU] 23:03:41 INFO: Connection to LFJUWAJ closed: reading length: read tcp 192.168.0.169:22000->192.131.44.99:35210: use of closed network connection
[UCBYU] 23:03:42 INFO: Completed initial scan (rw) of folder mpu76-sabec
[UCBYU] 23:04:15 INFO: Established secure connection to LFJUWAJ at 192.168.0.169:22000-192.131.44.99:34230 (tcp-server)
[UCBYU] 23:04:15 INFO: Device LFJUWAJ client is “syncthing v0.14.15” named “ulysses.whatbox.ca”
[UCBYU] 23:04:15 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 23:05:15 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 23:06:15 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 23:07:15 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
[UCBYU] 23:08:16 INFO: Folder “mpu76-sabec” isn’t making progress. Pausing puller for 1m0s.
I’ve been running the most up-to-date version of Syncthing. I only recently began using SyncTrayzor as a means to hopefully fix this problem (which it did not, obviously). Thanks for any and all help!
My two child/nodes are running Windows, my master is linux to my knowledge? It’s a seedbox which I setup via SSH. I’m a bit of a novice when it comes to linux/ssh etc so my apologies if I’m uninformed on anything regarding it.
Sure, here it is. Right now its only small files that aren’t syncing (I manually did them all at the moment, however the issue is still the same as seen above, just the out of sync items is normally higher.
If you could click on the “4 items” link to the right of “Failed Items”, and hover over one of the entries, it may also be helpful. And/or give you some insight yourself.
No problem, here’s one. Doesn’t really help me, I know what isn’t syncing, I just don’t understand why. It’s reason is “parent is not a dir” which, it is? No idea whats going on. It’s been working flawlessly for 2+ years, then this.
I also had this issue. Fixed it by recreating the folder path for the files shown in the failed items list, allowing it to sync for a few minutes to propagate to the other nodes, then deleting that path again. Hope that helps.
Since you say it’s happened before, and Scott has had it, might be worth diagnosing rather than just fixing it with his method.
You say you’ve tried wiping the indexes - I assume you’ve tried shutting down both Syncthings, wiping both indexes and starting them back up, so that neither Syncthing ever “sees” an old index?
Just to clarify what Syncthing should be doing here - do the root parent Wahlburgers…, and Screens exist on the Win box? What about the files?
I see you’ve got “Ignore permissions” set, but have you checked the ulysses box to see if any of the subdirectories/files involved have odd permissions or other flags set (jut in case)? What OS is ulysses?
Can you open the files in question, at both ends? Tried checking the file systems? What happens if you copy the Wahlburgers… directory at the remote end - does that sync OK?
You could try using Sysinternals’ Process Monitor to watch what the Syncthing binary is trying to do. Stop Syncthing, set Procmon to: Filter->Drop Filtered Events, de-select all of the right-most toolbar buttons except Files (yellow filing cabinet) and set a filter of say “Path->Contains->Wahlburgers”.
Start up Syncthing and see what events pop up.
This is caused by the new security checks by @calmh. It seems that somehow syncthing managed to scan files which are behind a symlink. Either reset the database or check each path component for being a symlink for the files listed as failed.
Well every single file syncthing downloads is a symlink in my setup. I have a hardlink created after the completion of each download, that way I can periodically clean up my sync folder so in the event I add a new device, or need to force an override, every single file i’ve ever downloaded doesn’t get re-downloaded. So every file is a symlink. I forgot to mention in my initial post but after having such an issue, all my copies of syncthing are running on fresh installs and databases no more than a week old at this point (I reset everything a day before posting this). So this problem occurred just a few hours again after resetting every facet of this setup. So I mean I can delete the database again, but at no benefit. It will be my um-teenth time doing so.
The files are absolutely in the position it says they’re not in. Random files are the ones that get chosen not to downloaded. For instance out of the 8 movies I grabbed last night, 6 downloaded successfully, the other 2 are sitting in the failed items now. Nothing special or unique about them. I definitely don’t have any permission problems, just I read on a previous thread that that had helped out someone else having a similar issue. I generally kept it off until this happened.
I’m also not entirely sure what you’ve managed to do, but Syncthing was unfortunately quite lax and easily fooled by things changing from being real files to symlinks and back. It is somewhat more careful around symlinks now. The error you show in the screenshot indicates that some part of the path leading up to a file that Syncthing was going to handle was a symlink. This is absolutely forbidden. If your setup somehow depends on or requires this, it is not possible to accomplish with current Syncthing. Or if it is, we should fix it…
It’s also entirely possible that I fucked up the checks somehow and you’re seeing this error without there being a symlink anywhere. If so it would be awesome if you could show, explain or reproduce the issue so we can fix that.
Well technically I have a hardlink made, not a symlink. Sorry if that makes it completely different. My download process is:
rTorrent downloads to ~/Files
rTorrent creates Hard Link on finish to ~/Files/Sync
Syncthing master folder is setup to monitor ~/Files/Sync
Generally speaking I have 2 syncthing children downloading from the master
I periodically delete the hard links from ~/Files/Sync
I’ve been running my setup like this for almost 2 years now, so I really hope what I’ve been doing isn’t a bug and something to be patched. Would hate to have to have copies made to my Sync folder and double the storage used for each file that resides there.
Syncthing doesn’t know or care about hard links, your setup should be fine. But that doesn’t explain the errors above, which imply that either the “Wahlburgers…” or the “Screens” path components are not directories.
I also had the ‘parent is not a directory’ error for several items. Right around the time I upgraded to 0.14.15 In that case the parent directory had been deleted on another node. Even after manually deleting the directory on this node the error persisted. I waited several days and the problem never resolved even with multiple rescans, restarts of syncthing and reboots of the OS.
I deleted the configs and index’s and started with a fresh syncthing that resolved it. Sorry I can’t reproduce or help diagnose more.
I have the same problem but in my case I do I neither have symlinks nor any ignore patterns in the share.
The folders that ST is companining about were moved up one folder couple weeks ago. None of the nodes had any issues at all. Suddenly one of the node started complaining that “parent is not a directory”. When I hover over the listed issues, it mentions the folders that do not exists, well they do not exist because They werem oved to another folder.
The node that complains about the issue already has the perfect copy of the folder, so it is basically complaining about folders that do not exists at all.
I did not do anything in that folder for a while since moving the folders up and when I did that the moving was recognized across fine.
I feel like this is a bug since it came up with this by itself suddenly and has nothing to do with me messing up ST.
I am experiencing this issue as well. Originally, I started receiving the “parent is not a directory” error for files 1) that existed in the specified path; 2) where the parent was indeed a directory; and 3) that did not relate to any symlink or ignore pattern.
After all my troubleshooting efforts were frustrated, I ended up completely dismantling and rebuilding my ST network, only to have the error reappear for different files.
Now, the error message appears for files that have been deleted (the parent folder no longer exists). I believe this scenario is similar to @totoba.
I have five ST folders running on four devices, all running 0.14.17:
Ubuntu Desktop 16.10
Unbuntu Server 16.04 on Raspberry Pi 3
Windows 10 Desktop
Win 7 Virtual Machine
This issue has consumed an enormous amount of time, not only to troubleshoot and rebuild syncs, but to retrieve backups and run diff analysis on complicated file sets.
I’m really hoping for some insight and/or reliable workarounds soon.
I also was having this issue after browsing the insides of a zip file on android, the file browser probably did some symlinking.
Then all other machines started complaining about “parent is not a directory”.
I tried to fix it by making one of the “other machines” master and force it’s state on others, but without any success.
I ended up fixing it by removing the folder from all machines and readding it back.
