Syncthing on NAS - ARM V5 - ALMOST SOLVED

Hi to all! I installed Syncthing on my NAS Zyxel NSA320S, and it runs well, as it seems, but it doesn’t connect over the internet with my two PC in my office (no UPNP??). With 0.8.2 I’ve had some trouble with connection even with the PC in the office (had to set manually IP and port), no trouble with 0.8.3. So tried to build 0.8.3 from source (form ARM V5) as did with 0.8.2, but no luck! With GO 1.2 long stop on “mc [no test files]” and then, after more than 1550 lines, “eax     0xf0 ebx     0x82d3c34 ecx     0x0 edx     0x0 edi     0x0 esi     0x0 ebp     0x0 esp     0xbf925494 eip     0xb7705422 eflags  0x286 cs      0x73 fs      0x0 gs      0x3f *** Test killed with quit: ran too long (10m0s). FAIL    _/home/alessandro/Downloads/syncthing-0.8.3/protocol    600.088s ok      _/home/alessandro/Downloads/syncthing-0.8.3/scanner     0.019s ?       _/home/alessandro/Downloads/syncthing-0.8.3/upnp        [no test files] ok      _/home/alessandro/Downloads/syncthing-0.8.3/xdr 0.102s ?       _/home/alessandro/Downloads/syncthing-0.8.3/xdr/cmd/coder       [no test files] godep: go exit status 1”

With GO 1.2.1 _/home/alessandro/Downloads/syncthing-0.8.3/cmd/syncthing cmd/syncthing/model.go:575: assignment count mismatch: 2 = 3 FAIL    _/home/alessandro/Downloads/syncthing-0.8.3/cmd/syncthing [build failed]

and then long stop on “mc [no test files]”. …long long long time… godep: go exit status 2

With GO 1.2 was possibile build only the i386 executable. With 1.2.1 nothing.

Would be possible to have prebuild tars also for ARM V5? That’s only a few lines more in the build.sh and it can avoid a lot of headache to users. Most of NAS even now use ARM V5 CPU.

Congratulations for the excellent work, Syncthing is a great software, with a little development could be the new UbuntuOne! Thank You. Bye!

Successfully built 0.8.4 ARMV5 binary!! I’ll test it! (only with GO 1.2, 1.2.1 version still goes with assignment count mismatch: 2 = 3) Just a question: what is stcli executable in the main directory?

Weird with the build errors; I’ve added armv5 to the standard build script so there will be binaries for it in the future releases.

The stcli thing is just a (very user unfriendly) debug utility. It can connect to a syncthing node and print the index it receives etc. You can safely ignore it.

Thank you! Great! Installed 0.8.4 on NSA320s all functional (GUI, directory scan ecc.), but no connection over internet. Two office PC say “Disconnected”! BTSync connects in 2/3 seconds. Seems to be a port problem. On startup Syncthing says “no UPnP IGD device found” even if UPnP si set to open in the router… forwarded the UDP port, but every restart it changes… What can I do to connect??

That’s weird, the UPnP forwarding should work. What you can do is set the “Sync Protocol Listen Address” in the settings to a random (but static) port, like “:34567”. Then port forward the same port in your router, i.e. port 34567 external -> port 34567 on the internal IP. If global discovery is enabled on both nodes, they should be able to connect.

Some progress here… forwarded static port in the home router and now office PC see NAS, but no connection! Terminal says: "[MGAZA] 2014/05/07 10:21:11 WARNING: Connection to -------------------------------------------------------------------------- closed: remote has extra repository “Amministrazione” [MGAZA] 2014/05/07 10:21:11 WARNING: Connection to -------------------------------------------------------------------------- closed: read tcp —.–.—.---:34567: use of closed network connection" In infinite loop. What means with “closed network connection”? Can I open something?

Update: NAS terminal says: "Acer-7730G: remote is missing repository "Amministrazione" 14:46:07: Connection to Acer-7730G closed: remote is missing repository "Amministrazione" 14:46:07: Connection to Acer-7730G closed: unexpected EOF 14:47:04:Amilo-PI-1536: remote is missing repository "Amministrazione" 14:47:04: Connection to Amilo-PI-1536 closed: remote is missing repository “Amministrazione" 14:47:04: Connection to Amilo-PI-1536 closed: unexpected EOF”

Other update: forwarded port 22000 and reconfigurated Syncthing to port 22000 in NAS. Gui of office PC now says: "17:34:06: Connection to Zyxel NSA320S closed: remote has extra repository “Amministrazione" 17:34:06: Connection to Zyxel NSA320S closed: read tcp —.–.—.---:22000: use of closed network connection”

Not a DNS issue, tried to insert direct ip address and port and nothing changed!

New update this morning! Reloaded Syncthing on Nas, one of the PC of the office seems succesfully connected (“in sync” green, correct IP and port, no version number of Syncthing), the other is disconnected (no way to connect to NAS). From NAS side all disconnected and no sync activity at all.

Understood! I think the issue is about disks! The root filesystem of a NAS is on the flash memory of the NAS, and it’s loaded on startup. Every shutdown every modification made to the root filesystem (as new directories in /home) are cleaned and at startup the standard firmware is loaded. So Syncthing must be installed on one disk of the NAS, and a little script makes the symbolic links to /home directory for config files. Making symbolic links to the folder to be syncronized in the /home/shares (the only user) does not work (no file is seen by Syncthing), and from outside the NAS other nodes can’t see the syncronization folder, that is in another disk (not on the root filesystem and on NTFS filesystem). Is there any way to detach Syncthing from /home directory and from the root filesystem?

You can give syncthing the correct path to the shares directly (i.e. <repository directory="...">) and skip the symlinks, and you can start syncthing with syncthing -home /some/persistent/dir to store the config and keys on some real disk.

Thank you! Did it. Still no connection! Messages are: "9:56:13: Zyxel NSA320S: remote has extra repository "Amministrazione" 9:56:13: Connection to Zyxel NSA320S closed: remote has extra repository "Amministrazione" 9:56:13: Connection to Zyxel NSA320S closed: read tcp —.–.—.-:22000: use of closed network connection" I’ll try to setup a PC to test the connection outside the NAS!

You have a mismatched setup in terms of how the repositories are configured. Make sure they have the same ID on both sides and that both nodes share the repository with the other.

Right, one of the folders was not in sync, now is! Thank you! I’ve tried to turn off NAS and connect 1 PC over internet… same problem no connection! I think there’s something with one router… weird, with BTSync all connections had no trouble (no trouble only with connections, BTSync damaged hundred of files of the syncing folder, files now unreadable). Log says: "mc: 17:13:55.708201 beacon.go:94: write udp4: network is unreachable" Status disconnected. I’ll try to check all parameters of the routers and will retry… Ah, on the same lan NAS and PC connect and sync with no trouble…

Nope, all ok in the router… UPNP activated, forwarded port 22000 TCP/UDP… no connection… Now no log, only : “INFO: No UPnP IGD device found, no port mapping created (read udp4 0.0.0.0:54667: i/o timeout)”, as every startup…

Ok, today NAS connected and syncing! :smiley: Think was something with port forwarding of office router! Don’t know what… I’ll try tomorrow to see if all goes well and then I’ll close thread as solved! Thank you for the support!

Mistery solved! When one of sync directory is not paired, Syncthing refuses to connect, even if other directories are correctly paired and configured! After some tries, I think the only trouble was this, nothing else. I think would be nice that Syncthing would tell in the log that one directory is not in sync, but connect anyway and sync other directories.

Yes.

https://github.com/calmh/syncthing/issues/223

Using Syncthing with the option that lets to move root directory on one on the disks in the NAS lets Syncthing work well until NAS puts in sleep mode drives. In this case Syncthing crashes and shuts down, and no more sync! The problem can be solved setting drives to be ever awake, but it’s not very good, for disks lifetime and for energy saving. It would be nice that Syncthing could work even if the drives containing the root directory (containing config files) are off, and its request could awake drives. Is it possibile?

Should not happen. Logs, crash trace?

I use telnet to start Syncthing, then disconnect! So have not Logs. I’ll try to let terminal connected and will see! Or there is some Syncthing option to redirect logs to one file and save them?