@rex wrote:
I am aware that Syncthing can be deployed to any server and made available via the Global discovery feature. However, I have not had any successes throughout my trials. I simply cannot find my server
Is there a tutorial for this? Like firewall and network configuration?
I apologise if this question has been asked before.
Posts: 2
Participants: 2
@IngwiePhoenix wrote:
I currently run an ownCloud server on my Debian server sitting in a DC. I use this is the second step in my backup setup - it holds about 1TB of my most important files. System backups are done on harddrives, since this only contains applications and related files, while ownCloud handles my personal stuff like pictures and what have you.
Now, I have had a lot of issues lately with the ownCloud client, as it is having massive HTTP/2 issues caused by a Qt library…since months. I dont want to say that I am infuriated or anything - but I am not very happy about this either.
So, I was starting to look for alternatives, and I would like to keep my “centralized aproach” if possible and maybe expand on it just a little in the future, as to having a connected harddrive sitting at my parents’ place to automatically hold a copy of this as well in the case that I need an urgent copy of my files in reach without having to wait for all the downloads to be done. Also, it will hold a second copy of my system backups. But - this is not the topic of the question I have.
Is it possible to setup SyncThing to sit on my dedicated server and act as a “cloud” to the other devices, to the point where no matter where I am, I can always sync things back and forth to this server? And is there a WebUI that I can use in order to access it through my phone? I liked the ownCloud app for iOS, but I realized that I barely ever used it so…its not really neccessary.
My list of systems is quite diverse; from macOS, to Windows to Linux in the DC…its all over the place
… so I need a cross-platform approach, obviously.
Hope to ditch ownCloud soon, because not actually being able to sync my stuff is starting to bother the F…frustration out of me ^^;
Kind regards, Ingwie!
Posts: 3
Participants: 3
@IngwiePhoenix wrote:
Okay, this will be pretty much out of nowhere but…I am very curios.
So, when using a device like the PS Vita to play ROMs and using the built-in PSP emulator, there are a lot of savefiles generated already - and getting them over to my Windows or macOS maschines usually involves manually copying things over before picking up the games I was playing. While RetroArch can manage files quite nicely locally, this is rendered a bit weirdly on the PSVita due to there being two instead of a single, monolithic emulator. And bringing all the saves over is usually a pain in the…back.
So, I was thinking of implementing a kernel module that would basically bring something like a WebDAV or similiar syncing client over to the Vita and possibly other consoles (like a CFW’d PS3 or Switch or…). SyncThing does not exactly require a server sitting in a DC or a PC running day and night to act as one to function - which is great. At least that is what I have understood from this so far. And that is why I was curios if porting a basic SyncThing client to the PSVita would be possible?
What I would need for this is:
- A possibly existing C/C++ library that implements the SyncThing protocol
- A set of features required for SyncThing to work
With this, I could write a plugin that would sync individual folders with individual folders on the other node. In my case, I would “link” my
uma0:/pspemu/PSP/SAVEDATAfolder to.../RetroArch/save/PSP/SAVEDATAon my SyncThing server (or main node) and do something similiar with the rest of the save files. This would be pretty great to have that synced. But this would require individual folder syncing to be possible - or configurable with the library.So yeah, what’s out there in terms of existing SyncThing implementations in C/C++ and what are their dependencies?
Thanks!
Posts: 3
Participants: 3
@nikto wrote:
I am trying to deploy Syncthing in docker and realise that the configurations files and sync files will stored in separate places.
How ca i realise that? may be some one has the example of docker command or docker-compose file?
For example: The configuration files will be stored under /srv/AppData/Syncthing An the Sync Data in folder /srv/Transfer/Syncthing
I hope that anybody will have some advices.
Posts: 5
Participants: 3
@petrzhebin wrote:
I have a question. Is it possible to configure the program to upload files (photos, videos) back to your smartphone? At the moment the only thing configured is downloading from the phone android with no deletion from PC.
Posts: 4
Participants: 2
@JRodko wrote:
This is something that plagues me every year when it comes time to setup Syncthing. I have a remote work-site so I absolutely love the program as a tool to sync all our data without plaguing our satellite internet with constant traffic. For much of the year we do not use Syncthing but another cloud based folder syncing service. When it comes time to get Syncthing running on several devices I am always in for many hours of headache dealing with conflicts due to mixed upper and lower cased file names. My other folder sync service never has these issues.
Anyone have any clever tricks for this other than forcing everyone to use a file/folder naming convention (ie only ever lower case)? It’s the only reason I still sometimes shop around for other features. It would be easy for me to justify paying for Syncthing if there was away around this issue. Thanks!
Posts: 1
Participants: 1
@se45tr6yftyhb wrote:
Apparently I need the syncthing-cli tool (which for Windows, right? It is Windows I’m asking about; I’ve found a way to check the status using Bash, so my Linux machines are catered for). But, where can I get syncthing-cli? I can’t find the file on my system and neither can I find somewhere to download the file.
Thanks.
Posts: 5
Participants: 3
@Danny wrote:
When will Asustor get an Update for this App. It is from 2016 and barely working. Syncthing maintain a bunch of Linux versions, but the NAS versions are not updated over years.
Your competitor update their Apps.
Posts: 4
Participants: 2
@adamralph wrote:
Some Android distros, e.g. those on Huawei phones, aggressively clean up empty folders.
This means that the
.stfolderis short lived, and it doesn’t take long before Syncthing can no longer sync on the phone due toError (folder marker missing).I can recreate the folder, using any number of cumbersome solutions, but before long, it is deleted again, and I have to go through the whole dance again to recreate the folder.
Would it be possible to add something to Syncthing to get around this problem?
Posts: 4
Participants: 3
@calmh wrote:
There is now a “supported” packaging of Syncthing for Synology. Instructions and package source here: https://docs.kastelo.net/synology/. I welcome testing and reports of success or otherwise, as well as requests for clarification of the documentation.
For issues with the package or it’s documentation, please open issues at the kastelo/syncthing-synology repository, or let me know in this thread.
Note that that this is not an “official” package in the sense that the Syncthing foundation or open source community is behind it. It’s a third party packaging much like any other, it just so happens that I work with/at the third party in question. It could conceivably become an official packaging at some point, but that would require a community around it first and I’m not going to foist responsibility of this thing on the Syncthing community at this point – while Kastelo currently has commercial interests in maintaining it.
Posts: 2
Participants: 2
@clambert wrote:
So I am running Syncthing in Docker on Unraid. My app data is backed up every night. Every morning my Recent Changes in the WebUI is empty, which kinda sucks because I like monitoring the sync of my parents machine to my server. Is there some way I can get this to persist over a restart of the Docker container?
Posts: 2
Participants: 2
@gvalkov wrote:
I have lots of cases where sync-conflicts files appear all over my documents, despite of using Symple File Versioning. They should be placed under .stversions, so that I can see them.
I just synced the documents on my MacBook Pro 2018 with my desktop PC and from there I synced only my source code folders to an Ubuntu virtual machine. For some reason it decided to throw away a new Makefile, replace it with an old version and then propagate that to my PC and then to my MacBook. How do I tell Syncthing to always keep the new version and stop doing stupid things?
Very ofter I see two devices not having their databases in sync, so device A thinks B is Up to date, while B thinks A is syncing. Sometimes -reset-deltas helps, but sometimes I have to -reset-database which has to rescan over 300 GB of data and is not fun. Especially when things break that often.
It’s very disappointing to see that despite of the great potential of Syncthing, it has such obvious bugs making me loose hours every time I need to sync my devices. And I always have to worry if the new changes are propagated or reverted because of a bug.
Posts: 5
Participants: 3
@Lymnos wrote:
I’ve been using Syncthing for about 2 years fairly successfully to one-way-sync one Windows 10 desktop to a Synology NAS, which I then backup to Backblaze. I check the setup every few months to make sure everything is working. When I checked today I found that both the Windows machine and the NAS show “Disconnected” for the other device. I’m a little beyond my pay grade here and am hoping I can get some help figuring this out.
Both devices are on the LAN, same subnet, can ping each other and there is no firewall on the devices or the network. Both are running Syncthing 1.3.3. I also rebooted both. I don’t understand the logging options very well, but did my best and this seems to be relevant. This is from Syncthing on the Synology NAS:
2020-01-25 14:34:36 discover: Received local announcement from x.x.x.29:60247 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5AN 2020-01-25 14:34:36 discover: Received local announcement from z.z.z.6:60247 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5ANx.x.x.29:60247 is the NAS static IP on the LAN z.z.z.6:60247 is the IP address of my VPN connection on the NAS 63DC5KJ is the NAS device ID
Seems like that could cause problems if the NAS is sending two announcements for different IPs? I will say that the NAS has been configured this way from the beginning, with it’s own LAN IP and the VPN IP, so I don’t know if anything changed with how Syncthing handles this.
The NAS log seems to loop through the following:
2020-01-25 14:33:24 sleep until next dial 1m0s 2020-01-25 14:33:36 addresses: [x.x.x.255 x.x.x.6] 2020-01-25 14:33:36 sent 91 bytes to x.x.x.255:21027 2020-01-25 14:33:36 sent 91 bytes to x.x.x.6:21027 2020-01-25 14:33:36 write udp [::]:39677->[ff12::8384]:21027: sendmsg: network is unreachable on write to [ff12::8384]:21027 lo 2020-01-25 14:33:36 sent 91 bytes to [ff12::8384]:21027 on eth0 2020-01-25 14:33:36 write udp [::]:39677->[ff12::8384]:21027: sendmsg: network is unreachable on write to [ff12::8384]:21027 sit0 2020-01-25 14:33:36 write udp [::]:39677->[ff12::8384]:21027: sendmsg: network is unreachable on write to [ff12::8384]:21027 tun0 2020-01-25 14:33:36 recv 91 bytes from [x::x::x:x:aa23%eth0]:39677 2020-01-25 14:33:36 discover: Received local announcement from [x::x::x:x:aa23%eth0]:39677 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5AN 2020-01-25 14:33:36 recv 91 bytes from x.x.x.29:60247 2020-01-25 14:33:36 recv 91 bytes from x.x.x.6:60247 2020-01-25 14:33:36 discover: Received local announcement from x.x.x.29:60247 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5AN 2020-01-25 14:33:36 discover: Received local announcement from 10.42.11.6:60247 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5AN 2020-01-25 14:33:46 recv 91 bytes from 192.168.1.11:61225 2020-01-25 14:33:46 discover: Received local announcement from 192.168.1.11:61225 for CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE 2020-01-25 14:33:46 discover: Registering addresses for CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE 2020-01-25 14:33:46 discover: Reconstructed URL is &url.URL{Scheme:"tcp", Opaque:"", User:(*url.Userinfo)(nil), Host:"192.168.1.11:22000", Path:"", RawPath:"", ForceQuery:false, RawQuery:"", Fragment:""} 2020-01-25 14:33:46 discover: Replaced address 0.0.0.0 in tcp://0.0.0.0:22000 to get tcp://192.168.1.11:22000 2020-01-25 14:33:46 discover: Reconstructed URL is &url.URL{Scheme:"quic", Opaque:"", User:(*url.Userinfo)(nil), Host:"192.168.1.11:22000", Path:"", RawPath:"", ForceQuery:false, RawQuery:"", Fragment:""} 2020-01-25 14:33:46 discover: Replaced address 0.0.0.0 in quic://0.0.0.0:22000 to get quic://192.168.1.11:22000 2020-01-25 14:34:06 addresses: [192.168.1.255 10.42.11.6] 2020-01-25 14:34:06 sent 91 bytes to 192.168.1.255:21027 2020-01-25 14:34:06 sent 91 bytes to 10.42.11.6:21027 2020-01-25 14:34:06 write udp [::]:39677->[ff12::8384]:21027: sendmsg: network is unreachable on write to [ff12::8384]:21027 lo 2020-01-25 14:34:06 sent 91 bytes to [ff12::8384]:21027 on eth0 2020-01-25 14:34:06 write udp [::]:39677->[ff12::8384]:21027: sendmsg: network is unreachable on write to [ff12::8384]:21027 sit0 2020-01-25 14:34:06 write udp [::]:39677->[ff12::8384]:21027: sendmsg: network is unreachable on write to [ff12::8384]:21027 tun0 2020-01-25 14:34:06 recv 91 bytes from 192.168.1.29:60247 2020-01-25 14:34:06 recv 91 bytes from 10.42.11.6:60247 2020-01-25 14:34:06 discover: Received local announcement from 192.168.1.29:60247 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5AN 2020-01-25 14:34:06 discover: Received local announcement from 10.42.11.6:60247 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5AN 2020-01-25 14:34:06 recv 91 bytes from [fe80::211:32ff:fe12:aa23%eth0]:39677 2020-01-25 14:34:06 discover: Received local announcement from [fe80::211:32ff:fe12:aa23%eth0]:39677 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5AN 2020-01-25 14:34:16 recv 91 bytes from 192.168.1.11:61225 2020-01-25 14:34:16 discover: Received local announcement from 192.168.1.11:61225 for CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE 2020-01-25 14:34:16 discover: Registering addresses for CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE 2020-01-25 14:34:16 discover: Reconstructed URL is &url.URL{Scheme:"tcp", Opaque:"", User:(*url.Userinfo)(nil), Host:"192.168.1.11:22000", Path:"", RawPath:"", ForceQuery:false, RawQuery:"", Fragment:""} 2020-01-25 14:34:16 discover: Replaced address 0.0.0.0 in tcp://0.0.0.0:22000 to get tcp://192.168.1.11:22000 2020-01-25 14:34:16 discover: Reconstructed URL is &url.URL{Scheme:"quic", Opaque:"", User:(*url.Userinfo)(nil), Host:"192.168.1.11:22000", Path:"", RawPath:"", ForceQuery:false, RawQuery:"", Fragment:""} 2020-01-25 14:34:16 discover: Replaced address 0.0.0.0 in quic://0.0.0.0:22000 to get quic://192.168.1.11:22000 2020-01-25 14:34:24 Reconnect loop 2020-01-25 14:34:24 lookup for CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE at IPv4 local 2020-01-25 14:34:24 addresses: [tcp://192.168.1.11:22000 quic://192.168.1.11:22000] 2020-01-25 14:34:24 lookup for CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE at IPv6 local 2020-01-25 14:34:24 addresses: [] 2020-01-25 14:34:24 lookup results for CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE 2020-01-25 14:34:24 addresses: [quic://192.168.1.11:22000 tcp://192.168.1.11:22000] 2020-01-25 14:34:24 Reconnect loop for CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE [quic://192.168.1.11:22000 tcp://192.168.1.11:22000] 2020-01-25 14:34:24 dialing CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE tcp://192.168.1.11:22000 prio 9 2020-01-25 14:34:34 dialing CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE tcp://192.168.1.11:22000 error: dial tcp 192.168.1.11:22000: i/o timeout 2020-01-25 14:34:34 failed to connect to CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE 9 2020-01-25 14:34:34 dialing CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE quic://192.168.1.11:22000 prio 99 2020-01-25 14:34:36 write udp [::]:39677->[ff12::8384]:21027: sendmsg: network is unreachable on write to [ff12::8384]:21027 lo 2020-01-25 14:34:36 sent 91 bytes to [ff12::8384]:21027 on eth0 2020-01-25 14:34:36 write udp [::]:39677->[ff12::8384]:21027: sendmsg: network is unreachable on write to [ff12::8384]:21027 sit0 2020-01-25 14:34:36 write udp [::]:39677->[ff12::8384]:21027: sendmsg: network is unreachable on write to [ff12::8384]:21027 tun0 2020-01-25 14:34:36 addresses: [192.168.1.255 10.42.11.6] 2020-01-25 14:34:36 sent 91 bytes to 192.168.1.255:21027 2020-01-25 14:34:36 sent 91 bytes to 10.42.11.6:21027 2020-01-25 14:34:36 recv 91 bytes from [fe80::211:32ff:fe12:aa23%eth0]:39677 2020-01-25 14:34:36 discover: Received local announcement from [fe80::211:32ff:fe12:aa23%eth0]:39677 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5AN 2020-01-25 14:34:36 recv 91 bytes from 192.168.1.29:60247 2020-01-25 14:34:36 recv 91 bytes from 10.42.11.6:60247 2020-01-25 14:34:36 discover: Received local announcement from 192.168.1.29:60247 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5AN 2020-01-25 14:34:36 discover: Received local announcement from 10.42.11.6:60247 for 63DC5KJ-PEQVRPA-R6OAKVE-OHVKXOW-H45235O-TLMXZCU-QX44ORY-YBTC5AN 2020-01-25 14:34:44 dialing CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE quic://192.168.1.11:22000 error: dial: NO_ERROR: Handshake did not complete in time 2020-01-25 14:34:44 failed to connect to CORYQAA-WI4GCCW-5S42YE3-TZCIEUK-ZHPEFFZ-JYZCQ2A-WT4F52O-ICDTHAE 99 2020-01-25 14:34:44 sleep until next dial 1m0sHere is what seems to be the looping part from the Windows machine logs:
[CORYQ] 2020/01/25 14:55:21.882449 service.go:485: DEBUG: sleep until next dial 1m0s [CORYQ] 2020/01/25 14:55:48.316776 broadcast.go:66: DEBUG: addresses: [x.x.x.255] [CORYQ] 2020/01/25 14:55:48.317776 multicast.go:80: DEBUG: sent 91 bytes to [ff12::8384]:21027 on Ethernet [CORYQ] 2020/01/25 14:55:48.317776 multicast.go:151: DEBUG: recv 91 bytes from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 [CORYQ] 2020/01/25 14:55:48.317776 local.go:199: DEBUG: discover: Received local announcement from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 for CORYQAA [CORYQ] 2020/01/25 14:55:48.317776 broadcast.go:89: DEBUG: sent 91 bytes to x.x.x.255:21027 [CORYQ] 2020/01/25 14:55:48.317776 broadcast.go:122: DEBUG: recv 91 bytes from x.x.x.11:61225 [CORYQ] 2020/01/25 14:55:48.317776 multicast.go:151: DEBUG: recv 91 bytes from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 [CORYQ] 2020/01/25 14:55:48.317776 local.go:199: DEBUG: discover: Received local announcement from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 for CORYQAA [CORYQ] 2020/01/25 14:55:48.317776 local.go:199: DEBUG: discover: Received local announcement from x.x.x.11:61225 for CORYQAA [CORYQ] 2020/01/25 14:55:48.317776 multicast.go:80: DEBUG: sent 91 bytes to [ff12::8384]:21027 on Ethernet 3 [CORYQ] 2020/01/25 14:55:48.317776 multicast.go:151: DEBUG: recv 91 bytes from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 [CORYQ] 2020/01/25 14:55:48.317776 multicast.go:80: DEBUG: sent 91 bytes to [ff12::8384]:21027 on Ethernet 2 [CORYQ] 2020/01/25 14:55:48.317776 local.go:199: DEBUG: discover: Received local announcement from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 for CORYQAA [CORYQ] 2020/01/25 14:55:48.317776 multicast.go:80: DEBUG: sent 91 bytes to [ff12::8384]:21027 on Loopback Pseudo-Interface 1 [CORYQ] 2020/01/25 14:55:48.317776 multicast.go:151: DEBUG: recv 91 bytes from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 [CORYQ] 2020/01/25 14:55:48.317776 local.go:199: DEBUG: discover: Received local announcement from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 for CORYQAA [CORYQ] 2020/01/25 14:56:18.323711 broadcast.go:66: DEBUG: addresses: [x.x.x.255] [CORYQ] 2020/01/25 14:56:18.324709 broadcast.go:89: DEBUG: sent 91 bytes to x.x.x.255:21027 [CORYQ] 2020/01/25 14:56:18.324709 multicast.go:151: DEBUG: recv 91 bytes from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 [CORYQ] 2020/01/25 14:56:18.324709 multicast.go:80: DEBUG: sent 91 bytes to [ff12::8384]:21027 on Ethernet [CORYQ] 2020/01/25 14:56:18.324709 broadcast.go:122: DEBUG: recv 91 bytes from x.x.x.11:61225 [CORYQ] 2020/01/25 14:56:18.324709 local.go:199: DEBUG: discover: Received local announcement from x.x.x.11:61225 for CORYQAA [CORYQ] 2020/01/25 14:56:18.324709 local.go:199: DEBUG: discover: Received local announcement from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 for CORYQAA [CORYQ] 2020/01/25 14:56:18.324709 multicast.go:151: DEBUG: recv 91 bytes from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 [CORYQ] 2020/01/25 14:56:18.324709 multicast.go:80: DEBUG: sent 91 bytes to [ff12::8384]:21027 on Ethernet 3 [CORYQ] 2020/01/25 14:56:18.324709 local.go:199: DEBUG: discover: Received local announcement from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 for CORYQAA [CORYQ] 2020/01/25 14:56:18.324709 multicast.go:151: DEBUG: recv 91 bytes from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 [CORYQ] 2020/01/25 14:56:18.324709 multicast.go:80: DEBUG: sent 91 bytes to [ff12::8384]:21027 on Ethernet 2 [CORYQ] 2020/01/25 14:56:18.324709 local.go:199: DEBUG: discover: Received local announcement from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 for CORYQAA [CORYQ] 2020/01/25 14:56:18.324709 multicast.go:151: DEBUG: recv 91 bytes from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 [CORYQ] 2020/01/25 14:56:18.324709 local.go:199: DEBUG: discover: Received local announcement from [fe80::180b:fb15:ee2e:fe25%Ethernet 2]:61226 for CORYQAA [CORYQ] 2020/01/25 14:56:18.324709 multicast.go:80: DEBUG: sent 91 bytes to [ff12::8384]:21027 on Loopback Pseudo-Interface 1 [CORYQ] 2020/01/25 14:56:21.882991 service.go:357: DEBUG: Reconnect loop [CORYQ] 2020/01/25 14:56:21.882991 cache.go:103: DEBUG: lookup for 63DC5KJ at IPv4 local [CORYQ] 2020/01/25 14:56:21.882991 cache.go:104: DEBUG: addresses: [] [CORYQ] 2020/01/25 14:56:21.882991 cache.go:103: DEBUG: lookup for 63DC5KJ at IPv6 local [CORYQ] 2020/01/25 14:56:21.882991 cache.go:104: DEBUG: addresses: [] [CORYQ] 2020/01/25 14:56:21.882991 cache.go:128: DEBUG: lookup results for 63DC5KJ [CORYQ] 2020/01/25 14:56:21.882991 cache.go:129: DEBUG: addresses: [] [CORYQ] 2020/01/25 14:56:21.882991 service.go:394: DEBUG: Reconnect loop for 63DC5KJ [] [CORYQ] 2020/01/25 14:56:21.882991 service.go:485: DEBUG: sleep until next dial 1m0sx.x.x.255:21027 - not sure what this is, as it’s not a physical device, but it’s in the LAN subnet. x.x.x.11:61225 is the Windows machine’s static IP
CORYQAA is the Windows machine device ID
I appreciate any help that can be offered.
Posts: 10
Participants: 3
@gvalkov wrote:
I and syncing various Linux scripts from my Windows PC to an Ubuntu virtual machine. The files have specific permissions set in Linux, yet every time I change a file on Windows and it gets synced, the permissions are reset to non-executable. How do I tell Syncthing to respect the target permissions?
I also have some folders with symbolic links on Linux. No matter how I set the Windows side, Syncthing always deletes them or complains. I tried having nothing; copy of the target file; or a sim-link on Windows.
Posts: 6
Participants: 4
@DuffMan wrote:
I am right now in the process of syncing many large files to and from an off-site server.
The download of files from the off-site server is progressing slowly even though my internet connection would support at least 5x faster transfer speeds.
When doing some tests I found out that the download rate of syncthing is very inconsistent. It reaches the maximum supported data rate for short amounts of time only to drop back to zero for a while. Compared to that, the upload rate stays constant all the time.
I have not set a puller pause or anything that would justify this behavior. All settings are pretty much at default, Syncthing is on the newest available version (v1.3.3), it’s not using a relay.
What could be reasons for this behavior?
Posts: 2
Participants: 2
@Josu wrote:
Hello, i have a small question. Is it any option to sync only files let say created last 24hrs from host to your storage. My host is small storage, but my destination folder is very big and scanning taking ages, even if i need to pull just a few GB of data
Posts: 10
Participants: 3
@Chris.Karst wrote:
I want to sync the pictures folder across multiple windows machines. I have 5 devices connected so far, all with the pictures folder set to share to every other.
I don’t want multiple pictures folders created with each pc name. I currently only show one folder on the left side, set to share with everyone. It appears to not be syncing.
should it have a folder entry on the left for each of the devices on every device? As in have 5 folder entries, all mapped to the same folder?
Posts: 2
Participants: 2
@David.P wrote:
Hi forum,
when Synctrayzor is closed via the tray icon, does Syncthing continue to run in the background then, or is it also closed?
Posts: 2
Participants: 2
@FernandoCabral wrote:
Last Friday, sync was OK. During the week-end I worked a little at home. Back to my desk today, Syncthing will never start syncing again. No error message. All the folders are given as UPDATE (which they aren’t). The machine this machine should connect to Disconnected and so stays no matter what I do (reboot, rescan, pause and resume…)
Yes, network is working alright, the remote machine is working alright. Is is sync’ing regularly with other machines. So, only this one is sleeping forever (almost 4 hours).
Image bellow depicts what Syncthing tells me about the remote machine:
Is there anything I can do to find why the system is comatose? Anything I can do to force it to connect again? (date and time on the lower right corner informs us last time the systems talked on last Friday).
Best regards
-fernando
Posts: 8
Participants: 3
@tjohnston wrote:
I have a server that syncs down to several computers, one way. The server died the other day so I moved the drive from the server (with my master files) to a new server, setup Syncthing and reconnected the remote computers. But Syncthing is now saying out of sync and trying to replace the files (that are already there) on the remote computers…many TB worth…at this rate it will take weeks to sync. If the files on the remote are the same as the server why is ST trying to overwrite them? Thanks for any advice.
Posts: 3
Participants: 2
… so I need a cross-platform approach, obviously.
