@FreeBSD_Lover wrote:

So using “netstat” commands I noticed an ESTABLISHED connection to my Syncthing server. The IP address is a machine on the Internet is not mine. Syncthing had been running for days, but I just noticed this connection. So why would I see a established connection to my Syncthing for a machine that has nothing to do with me.

tcp4 0 0 192.168.10.10.29874 x.x.x.x.22067 ESTABLISHED

When I shutdown Syncthing it was immediately gone. When I restarted Syncthing I saw a boatload of connections to all sort of machines on the Internet. Why? And when I say why what I really mean I guess is why is mine and these machines ‘contacting’ each other when these machines have nothing to do with one another. Shouldn’t the discovery process only cause my machine to contact other machines for which there is a valid syncing instance define?

$ netstat -S
Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp4       0      0 192.168.10.10.52216   5.44.44.149.22067      SYN_SENT
tcp4       0      0 192.168.10.10.52215   45.30.95.62.22067      FIN_WAIT_2
tcp4       0      0 192.168.10.10.52214   194.26.175.24.58368    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52213   64.228.3.113.22067     FIN_WAIT_2
tcp4       0      0 192.168.10.10.52212   93.92.204.228.22067    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52211   81.7.16.188.22067      FIN_WAIT_2
tcp4       0      0 192.168.10.10.52210   164.132.151.235.22067  FIN_WAIT_2
tcp4       0      0 192.168.10.10.52209   146.185.78.43.22067    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52208   213.183.53.178.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52207   109.230.199.119.22067  TIME_WAIT
tcp4       0      0 192.168.10.10.52206   88.190.49.73.22067     TIME_WAIT
tcp4       0      0 192.168.10.10.52205   194.87.109.249.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52204   128.173.88.78.22067    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52203   51.38.114.196.22067    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52202   77.55.210.110.22067    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52201   159.69.201.90.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52200   108.56.199.251.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52199   213.148.214.22.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52198   5.9.16.38.22067        FIN_WAIT_2
tcp4       0      0 192.168.10.10.52197   46.23.92.148.22067     FIN_WAIT_2
tcp4       0      0 192.168.10.10.52196   70.44.221.142.22067    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52195   212.47.253.154.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52194   23.94.46.24.22067      FIN_WAIT_2
tcp4       0      0 192.168.10.10.52193   67.213.141.6.10922     TIME_WAIT
tcp4       0      0 192.168.10.10.52192   92.202.22.130.22067    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52191   72.23.147.207.34074    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52190   104.193.225.93.https   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52189   93.180.156.234.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52188   139.162.117.43.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52187   46.105.55.153.53603    TIME_WAIT
tcp4       0      0 192.168.10.10.52186   94.222.185.152.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52185   195.201.9.37.22067     FIN_WAIT_2
tcp4       0      0 192.168.10.10.52184   47.94.220.232.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52183   163.172.181.231.22067  FIN_WAIT_2
tcp4       0      0 192.168.10.10.52182   37.122.210.202.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52181   104.245.38.195.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52180   213.148.212.114.https  FIN_WAIT_2
tcp4       0      0 192.168.10.10.52179   94.16.114.88.22067     FIN_WAIT_2
tcp4       0      0 192.168.10.10.52178   51.154.12.240.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52177   90.112.54.163.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52176   220.135.237.201.38707  TIME_WAIT
tcp4       0      0 192.168.10.10.52175   209.141.60.170.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52174   185.251.39.48.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52173   167.86.85.229.https    TIME_WAIT
tcp4       0      0 192.168.10.10.52172   148.251.237.21.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52171   192.99.59.139.https    TIME_WAIT
tcp4       0      0 192.168.10.10.52170   157.230.224.44.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52169   31.220.7.158.22067     TIME_WAIT
tcp4       0      0 192.168.10.10.52168   103.1.186.157.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52167   147.253.74.150.40803   TIME_WAIT
tcp4       0      0 192.168.10.10.52166   185.58.194.48.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52165   88.99.86.72.22067      TIME_WAIT
tcp4       0      0 192.168.10.10.52164   79.137.32.223.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52163   10.128.128.102.22000   ESTABLISHED
tcp4       0      0 192.168.10.10.52162   47.222.103.234.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52161   104.131.145.187.22067  TIME_WAIT
tcp4       0      0 192.168.10.10.52160   5.28.62.176.22067      TIME_WAIT
tcp4       0      0 192.168.10.10.52159   94.198.98.21.22067     TIME_WAIT
tcp4       0      0 192.168.10.10.52158   10.128.128.173.22000   ESTABLISHED
tcp4       0      0 192.168.10.10.52157   149.202.52.153.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52156   45.83.151.156.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52155   82.34.44.237.55553     FIN_WAIT_2
tcp4       0      0 192.168.10.10.52154   150.249.0.147.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52153   116.202.11.126.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52152   76.72.171.41.22067     ESTABLISHED
tcp4       0      0 192.168.10.10.52151   128.199.52.39.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52150   217.25.228.203.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52149   206.190.135.76.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52147   158.69.220.91.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52146   62.210.140.119.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52145   51.15.241.123.22067    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52144   194.59.206.11.22067    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52143   162.246.157.114.22067  TIME_WAIT
tcp4       0      0 192.168.10.10.52142   178.238.227.132.22067  TIME_WAIT
tcp4       0      0 192.168.10.10.52141   195.182.4.237.https    TIME_WAIT
tcp4       0      0 192.168.10.10.52140   59.72.154.20.22067     FIN_WAIT_2
tcp4       0      0 192.168.10.10.52139   95.232.57.22.22067     FIN_WAIT_2
tcp4       0      0 192.168.10.10.52138   198.100.147.150.22067  TIME_WAIT
tcp4       0      0 192.168.10.10.52137   94.66.226.6.22067      FIN_WAIT_2
tcp4       0      0 192.168.10.10.52136   94.26.59.27.22067      FIN_WAIT_2
tcp4       0      0 192.168.10.10.52134   185.159.248.35.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52133   185.181.160.45.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52132   141.14.27.100.https    TIME_WAIT
tcp4       0      0 192.168.10.10.52131   78.83.16.225.22067     TIME_WAIT
tcp4       0      0 192.168.10.10.52130   136.243.66.99.22067    FIN_WAIT_2
tcp4       0      0 192.168.10.10.52129   83.240.5.132.22067     TIME_WAIT
tcp4       0      0 192.168.10.10.52128   118.167.15.75.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52127   160.119.250.33.https   TIME_WAIT
tcp4       0      0 192.168.10.10.52126   94.16.122.162.https    TIME_WAIT
tcp4       0      0 192.168.10.10.52125   184.105.151.164.22067  TIME_WAIT
tcp4       0      0 192.168.10.10.52124   212.51.136.75.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52123   212.51.129.49.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52122   195.201.94.137.https   TIME_WAIT
tcp4       0      0 192.168.10.10.52121   199.195.251.28.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52120   95.103.188.229.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52119   64.86.134.22.22067     FIN_WAIT_2
tcp4       0      0 192.168.10.10.52118   199.181.238.100.22067  TIME_WAIT
tcp4       0      0 192.168.10.10.52117   132.145.49.47.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52116   45.32.190.137.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52115   96.231.199.101.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52114   140.121.80.170.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52113   164.15.134.217.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52112   193.239.58.220.https   TIME_WAIT
tcp4       0      0 192.168.10.10.52111   195.201.118.83.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52110   51.15.105.255.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52109   91.121.50.14.52419     TIME_WAIT
tcp4       0      0 192.168.10.10.52108   47.95.224.92.22067     TIME_WAIT
tcp4       0      0 192.168.10.10.52107   213.108.105.162.22067  TIME_WAIT
tcp4       0      0 192.168.10.10.52106   78.46.177.74.22067     TIME_WAIT
tcp4       0      0 192.168.10.10.52105   92.62.63.75.22067      TIME_WAIT
tcp4       0      0 192.168.10.10.52104   188.68.32.45.22067     FIN_WAIT_2
tcp4       0      0 192.168.10.10.52103   212.12.25.30.27040     TIME_WAIT
tcp4       0      0 192.168.10.10.52102   178.32.51.52.22067     TIME_WAIT
tcp4       0      0 192.168.10.10.52101   158.58.170.183.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52100   185.67.190.92.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52099   185.222.202.32.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52098   79.136.5.160.22067     TIME_WAIT
tcp4       0      0 192.168.10.10.52097   45.33.68.78.22067      TIME_WAIT
tcp4       0      0 192.168.10.10.52096   221.118.74.152.22067   FIN_WAIT_2
tcp4       0      0 192.168.10.10.52095   88.99.163.110.50332    TIME_WAIT
tcp4       0      0 192.168.10.10.52094   85.143.216.244.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52093   142.93.102.4.22067     TIME_WAIT
tcp4       0      0 192.168.10.10.52092   104.218.63.101.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52091   220.133.98.227.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52090   185.207.107.69.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52089   209.141.59.16.22067    TIME_WAIT
tcp4       0      0 192.168.10.10.52088   167.86.107.184.22067   TIME_WAIT
tcp4       0      0 192.168.10.10.52087   107.170.56.60.https    TIME_WAIT

Posts: 14

Participants: 3

Read full topic

@rahrah wrote:

Hi,

I wonder if in the GUI Advanced Options Dialogue, you could change:

Debugging -> GUI Debugging
Enabled -> GUI Enabled

I know it’s redundant, given where these options are placed, but it just makes the options more obvious and readable, a sort of cognitive nudge.

Thanks,

===Rich

Posts: 2

Participants: 2

Read full topic

@marlar wrote:

I would like to share only a few folders from my home directory. Everything within folder ABC and DEF should be shared, but nothing else. Not any other folders and not any files in the home directory.

These patterns works in the sense that only ABC and DEF get synced to the destination:

!ABC/**
!DEF/**
*
*/**

But Syncthing shows a Filesystem Watcher Error:

Error while traversing /home/marlar/.gvfs: permission denied

It’s true that the permission is denied but why does it scan that folder when it should be ignored?

It also takes very long time to scan even though the two folders are small. This also suggests that SC is scanning it all.

Posts: 8

Participants: 3

Read full topic

@terry wrote:

st log.txt (118.5 KB)

I use synctrazor and it’s just had a crash. Seems to be shortly after the new version. The log suggests a missing folder, but it’s there, I can see it.

Just trying Syncthing outside of synctrazor.

Posts: 7

Participants: 3

Read full topic

@TechupBusiness wrote:

Hi there,

I just more or less finished my contribution by implementation the reflection of stignore patterns for nautilus file manager (https://github.com/syncthing/syncthing-gtk/pull/538), and realized that the logic of stignore files is very confusing.

As a developer I’m used to a hierarchical structure, and I do like the gitignore logic. The last applicable pattern wins.

In stignore, it seems to be mixed or reversed.

If I have a structure:

- Client Specific Documents
   - Client1
      - Data
      - Projects
   - Client2
   - Client3

My goal is to sync only the Client1 Folder but not the Data folder within this folder. The correct stignore content is(?):

/Client Specific Documents/Client1/Data
!/Client Specific Documents/Client1
/Client Specific Documents

Means: I need to write the deepest level ignore first, then the exclude of ignore on a parent level and then the ignore for all files on the highest level. If I reverse the order oder write the ignore of Data after the exclude pattern (!), it would sync the data against my intention. And if I write the /Client Specific Documents as first line, it would sync also Client2 + 3. This makes pattern way more difficult to understand as they need to be.

A gitignore pattern would be very simple and logically easier:

/Client Specific Documents -> first exclude main folder and all sub-items
!/Client Specific Documents/Client1 -> Include Client1
/Client Specific Documents/Client1/Data -> Exclude the data of Client1

stignore seems to reverse the logic and requires to go from the most deep tree level to the top. Instead from top to a deeper level. Anyone else the same opinion that “overview first” and then “deeper level” is normally the right approach :)? Was this maybe already discussed in the past?

Posts: 2

Participants: 2

Read full topic

@ch4pz wrote:

Not sure whether this belongs here or in a linux forum but Im just in the process of upgrading my server from win 8.1 to Fedora 31 but upon syncing the first folder (as a test) my 256GB SSD is full!! I still have another 30TB volume to sync, not to mention all these volumes where synced on Windows and the SSD was barely half full. Not sure why consuming so much space? there seems to be an extra 60GB in what looks like root directory, but again, not sure if this is standard? the SSD is also encrypted so dunno if thats hogging space? Pretty new to everything linux, so please go easy on the technical stuff The other end is a FreeNAS plugin

Posts: 5

Participants: 2

Read full topic

@dey9999 wrote:

syncthing fails to start on dietpi. Log shows error: [start] 2019/11/14 04:09:23 INFO: syncthing v1.3.1 “Fermium Flea” (go1.13.3 linux-arm) teamcity@build.syncthing.net 2019-10-07 11:30:25 UTC [start] 2019/11/14 04:09:23 INFO: Generating ECDSA key and certificate for syncthing… [start] 2019/11/14 04:09:24 WARNING: Failed to load/generate certificate: save cert: open /mnt/dietpi_userdata/syncthing/cert.pem: permission denied

The very first dietpi build worked great on my pi. I decided to scrap it and rebuild. Ever since I have been getting this error when I try to start syncthing. I loaded it using dietpi management.

Posts: 2

Participants: 2

Read full topic

@HalfNote5 wrote:

What happens if you delete files from .stversions? Does Syncthing merrily just generate new ones up to the specified number of previous versions or does it bork the database somehow?

Reason I ask is we’ve got a lot more 5-12GB .pst files than I expected along with everyone’s documents and I’d like to write a script to trim that down to ONE backup of their PST, on the regular. But maintain the 5 previous versions of, say, documents.

Posts: 3

Participants: 2

Read full topic

@gbr wrote:

It would be great if Syncthing could send an email if there is an issue during sync. Something like one email a day would work just fine.

Posts: 1

Participants: 1

Read full topic

@ferdinand wrote:

Hi,

I try to get Syncthing running in LXC on Debian Buster, but get a “Failed to set up mount namespacing: Permission denied” error.

On the LXC container (Debian 10 (Buster)):

$ dpkg -l ‘syncthing’ | grep ^ii

ii syncthing 1.3.1 amd64 Open Source Continuous File Synchronization

# journalctl -u syncthing@xxx.service

...
Nov 15 19:28:57 xxx systemd[1]: Started Syncthing - Open Source Continuous File Synchronization for xxx.
Nov 15 19:28:57 xxx systemd[336]: syncthing@xxx.service: Failed to set up mount namespacing: Permission denied
Nov 15 19:28:57 xxx systemd[336]: syncthing@xxx.service: Failed at step NAMESPACE spawning /usr/bin/syncthing: Permission denied
Nov 15 19:28:57 xxx systemd[1]: syncthing@xxx.service: Main process exited, code=exited, status=226/NAMESPACE
Nov 15 19:28:57 xxx systemd[1]: syncthing@xxx.service: Failed with result 'exit-code'.
Nov 15 19:28:58 xxx systemd[1]: syncthing@xxx.service: Service RestartSec=100ms expired, scheduling restart.
Nov 15 19:28:58 xxx systemd[1]: syncthing@xxx.service: Scheduled restart job, restart counter is at 1.
Nov 15 19:28:58 xxx systemd[1]: Stopped Syncthing - Open Source Continuous File Synchronization for xxx.
...

On the host (Debian 10 (Buster)):

$ dpkg -l ‘lxc’ | grep ^ii

ii lxc 1:3.1.0+really3.0.3-8 amd64 Linux Containers userspace tools

# dmesg

...
[4519490.489894] audit: type=1400 audit(1573841522.996:785): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-container-default-cgns" name="/" pid=4016 comm="(yncthing)" flags="rw, rslave"
...

Any idea how to fix this? Or did i do something else wrong?

Regards, Ferdinand

Posts: 3

Participants: 2

Read full topic

@se45tr6yftyhb wrote:

The syncthing URL keeps rejecting my - correct - credentials. Might this be a file permissions problem? Can anyone advise? Thanks. (I am on the same computer I was on before, but a different user account. I reinstalled syncthing on the computer but so doing made no difference, though I did retain my user settings, i.e. I did apt install syncthing --reinstall, not apt purge syncthing).

Posts: 2

Participants: 2

Read full topic

@heinrich-k wrote:

So, I have my own little relay server running and i use “Let’s Encrypt” certificates to secure it. These are invalid after some time, so they are automatically renewed and the relayserver restarted.

But, this changes the id, and since it have to provide the ID on all nodes, that is kind of frustrating. So, is there a way to mage my syncthing nodes connect with the relaysrv with some other method, than providing the ID?

Posts: 4

Participants: 2

Read full topic

@kkleinfelter wrote:

I’ve got a machine which syncs with multiple other machines. Some files sync to one machine; some files sync to another machine; some files sync to both machines.

When inotify tells Syncthing that a file which is synced with both machines changed, will that one notification result in the file syncing to both targets?

Posts: 2

Participants: 2

Read full topic

@Martin_Azka wrote:

Hi, I use syncthing on multiple devices. It’s ok for everyone, but I have a problem with one. It’s a Linux laptop.

LOG log (57.2 KB)

Syncthing always disconnects and connects to the daemon. Still and again after a few seconds. Do you have a solution?

Posts: 2

Participants: 2

Read full topic

@LOSTMYPICTURES wrote:

I synced pictures from my Android phone to my Windows computer. It finished and then I deleted the pictures off my phone. Now I see the pictures on my computer are gone too. I need to get my pictures back. How do I get them back?

Posts: 3

Participants: 3

Read full topic

@Nicolas wrote:

Hello, I’ve had a problem for a while with only one syncthing node, two shares are out of sync.

At first, the local state was good but not the global state… On 2 other nodes, everything was good (and are still good).

Following the consultation of the page Incorrect global state on ONE node (other nodes agreeing with its local state).

I started syncthing with the command “syncthing -reset-deltas”. Since the global status is good but the folders are still out of sync.

For information, Syncthing is in version 1.3.1, Windows 10 (64 bit) on the computer that is causing the problem.

Can you help me fix the problem?

Sincerely,

Nicolas BRIN

Posts: 2

Participants: 2

Read full topic

@i0x915 wrote:

Just wanted to say thanks for writing such a great tool! This is one of those quality tools that you rarely find and really hope that it never seizes to exist. Keep up the good work!

Posts: 1

Participants: 1

Read full topic

@remaster wrote:

I wanted to preserve battery on my Windows laptop, and decided that I don’t need Syncthing to sync while I’m on battery.

The service is run using Scheduled Tasks, which has an option to shut down while not connected to AC power. When I connect AC power, the service starts automatically.

I’m quite happy with this solution.

Posts: 1

Participants: 1

Read full topic

@kkleinfelter wrote:

I’m looking to sync two sometimes-on machines. I’m concerned about delays in sync when they don’t both happen to be on at the same time for an extended period of time. (Days or weeks, not months.)

I have a third machine which is (almost) always on. I don’t particularly have a need to have these files on that machine. I could:

• Set up the two sometimes-on machines and live with extended-delay sync.
• Set up each of the two sometimes-on machines to sync to a ‘relay’ directory on the 3rd machine.
• Set up all of the 3 machines to sync with the other 2.

Which design is likely to make me happiest over the long term?

Are there any particularly high areas of risk?

(I’m not concerned over simultaneous updates – just sync hazards.)

Posts: 4

Participants: 2

Read full topic

@i0x915 wrote:

Hi, I have 2 linux machines running the v1.3.1 for about a week and syncing files without any issues, if i shutdown node A through the web gui by clicking “Shutdown”, node B sees its peer as Disconnected, however the last_seen flag says “Never”, as soon as i bring the node A back online, status changes back to Up To Date and continues working properly.

Is it normal for the last seen flag to be set to Never even though the node just went down, this looks like a possible bug to me.

May be similar issue to this post:

Posts: 3

Participants: 2

Read full topic