Beiträge von nineheadnaga

  • Syncthing container won't connect to relays

    A quick update: I've tried on the newly reinstalled system, iptables nft or legacy doesn't seem to make any difference, it connects to the remote relays without any problems. So the issue was something else, but at least we know it wasn't iptables.

    Giving Nextcloud a spin right now. Installed the container and got a nice 502 for now. :) We'll see.

  • Syncthing container won't connect to relays

    I don't know, maybe. But then I have to wonder why the hint says that Docker needs iptables-legacy, when apparently leaving it on the default iptables-nft is what allows it to work correctly (or the Syncthing container, at least).

    Unless the real issue was something else entirely, unrelated to iptables, and it has been solved by the reinstall… at this point, in the interest of knowledge and SCIENCE, I'll just go and try it out when I've made the backup image and before experimenting with Nextcloud. It's a question that actually needs further inquiry.

  • Syncthing container won't connect to relays

    I'm back; sorry for the delay, I was there hearing their advice, then trying things, then there was xmas too… anyway, they too tried to help me and made look up various things, but neither them could make head or tails or this issue. In the end, I decided to be drastic, re-burned a previous backup image of the microSD, and reinstalled Docker and the container from the beginning. And… now everything works! it sees and connects to the relays servers, it syncs even to remote clients, doesn't need network modes or UPNP or nothing.

    Only thing is, I have no idea what was wrong.

    MAYBE one thing I think I did differently this time is leave the iptables setting as it was in OMV Extras > Docker, instead of changing it as suggested by the hint: "Debian 10/OMV 5.x uses iptables-nft by default and Docker needs iptables-legacy. Use iptables menu to change." but I'm not so sure of that TBH (and sure as hell I'm not gonna experiment with it now that it works :P )

    I've not forgotten your advice though! As soon as I write a new backup image, I'm going to try the Nextcloud container.

  • Syncthing container won't connect to relays

    Really? Because at the moment it's using about half of that RAM (actually 470MB, since a part is reserved by the flash memory plugin, and it's only running OMV, Samba, and Docker with a Syncthing that's not scannig/syncing anything for now, but it's still remarkably light on resources).

    On that note, after we talked about Nextcloud on this thread I looked it up, and I have to say their requirements are lower than I imagined:

    "Nextcloud needs a minimum of 128MB RAM, and we recommend a minimum of 512MB."

    So maybe it'd be a tight fit, but I could probably run Nextcloud too on this hardware. I'm certainly not giving up on OMV after all the time I spent after it setting it up, but it's nice to know at least I have options other than "buy a real PC". :P

    Zitat von Zoki

    I am running out of ideas today. Try the netstat command please.

    Will be back tomorrow.

    I did try using netstat, but the output is huge so I didn't post it. It didn't have anything listening on port 22000, but if you want to see it to look for something else I can post it anyway.

  • Syncthing container won't connect to relays

    Zitat von chente

    Did you try what Zoki said?

    Yes, tried that last time and checked again to be sure, same result. Everyone can resolve the IP of relays.syncthing.net, except that second "try" of nslookup from the container.


    As for the other question, no there aren't other services listening on port 22000; as soon as I restart the container, the usual ports pop up:

  • Syncthing container won't connect to relays

    I tried it right now. Activated ethernet interface with omv-firstaid (that for some reason de-activated the wireless interface), rebuilt the container with the same .YML stack as before. Same result.

    On the router the usual ports are open. Should I try doing the same in the Network > Firewall settings for OMV?

  • Syncthing container won't connect to relays

    Sorry for the delay, the SBC decided it didn't want to use wi-fi or docker anymore so I had to rewrite a previous backup image. I used the chance to re-configure docker and syncthing according to the guides you linked, including the /data1 folder.

    Zitat von chente

    Looking back at the linuxserver documentation for this container, I see that the data folder is set to /data1 (and /data2 if you're going to use it too). I don't know where you copied the /var/syncthing folder name from?

    I think you should stick to the linuxserver instructions and rename that folder to /data1

    /var/syncthing comes from another tutorial I followed at the time to set up the Syncthing container. Looking back, it was outdated and unclear in some points.

    Anyway, I tried deleting that line and rebuilding the container. Obviously I get a warning for the now missing folder, but I also keep getting the same error message in the logs:

    Code
    2021-12-12 18:16:37 Relay listener (dynamic+https://relays.syncthing.net/endpoint) starting
2021-12-12 18:16:37 Relay listener (dynamic+https://relays.syncthing.net/endpoint) shutting down
2021-12-12 18:16:37 listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint: service dynamic+https://relays.syncthing.net/endpoint failed: Get "https://relays.syncthing.net/endpoint": dial tcp: lookup relays.syncthing.net on [::1]:53: dial udp [::1]:53: connect: cannot assign requested address

  • Syncthing container won't connect to relays

    Zitat von chente

    Please edit the registry output you have published and delete the keys. As soon as possible.


    Edit: I've taken the liberty of doing it myself...

    Sorry, I posted then got to bed. However, from their FAQ I don't think those Syncthing ID are security-sensitive data.


    As for the guide to use docker containers, I'm working through it re-checking everything I may have missed. So far I've found a couple things, so from "OMV > Access rights management > Shared folders" I've granted read/write permission for the user associated with Syncthing to the SMB shared folder and the /docker folder.


    Zitat von chente

    I don't like this line. Why right define / var / syncthing? According to the official documentation it should be / data1, why is this change?

    On the left you must define the folder where you want to synchronize the data. Is that the directory where you want to sync? If so, it would remove the spaces. They are usually troublesome. I would change it to SAMBA_SHARE_FOLDER. If it is a shared folder you may need to modify it as well.

    It's from the tutorial I used to help me configure some details when setting up the Syncthing container for the first time (at the time I didn't know of the How-to posted here). But I was under the impression that the folder name didn't matter much, as long as the container is told where to look.

    As for the share name it was a placeholder, it actually is "Office technical archive" and yes it has spaces. Since in windows networks it has undescores anyway I guess I can change it, I'll just have to see how to rename it without re-doing it from scratch.

    Zitat von Zoki

    [::1]:53: is IPv6 DNS.


    Can you log into the syncthing container and verifiy, you have a valid address resolution inside the container.

    nslookup relays.syncthing.net or ping relays.syncthing.net or whatever you have available in this container.

    This is interesting. I've tried

    Code
    #> docker exec -it syncthing ping relays.syncthing.net
PING relays.syncthing.net (82.196.13.137): 56 data bytes
64 bytes from 82.196.13.137: seq=0 ttl=52 time=68.078 ms
64 bytes from 82.196.13.137: seq=1 ttl=52 time=69.877 ms
64 bytes from 82.196.13.137: seq=2 ttl=52 time=84.765 ms

    and it works. Same for pinging from outside the container. But when I try nslookup:

    Code
    #> docker exec -it syncthing nslookup relays.syncthing.net
Server:         8.8.8.8
Address:        8.8.8.8:53

Non-authoritative answer:
Name:   relays.syncthing.net
Address: 82.196.13.137

Non-authoritative answer:
*** Can't find relays.syncthing.net: No answer

    it gives this weird double answer. Simple lookup from outside gives a more normal answer:

    Code
    #> nslookup relays.syncthing.net
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   relays.syncthing.net
Address: 82.196.13.137

    (but writing 8.8.8.8#53 instead of 8.8.8.8:53 for some reason). At the beginning I had googled that [::1]:53 and apparently it's an empty address that couldn't be filled because of DNS issues; makes sense, if it's looking for an IPv6 address and IPv6 isn't active on the router.

    I've looked in Syncthing options, and the only thing that seems to mention IPv6 is in the Advanced Settings Local Announce MAC Addr: [ff12::8384]:21027 otherwise, as chente said, it doesn't even give the choice between v6 and v4. Could be it's automatically managed, but then why does it look so dead set on using v6 when v6 isn't there?

  • Syncthing container won't connect to relays

    The YML file is more or less the same, earlier I added the network_mode: bridge line.


    Actually, the error message is in syncthing's log, Listener Failures window, and Discovery Failures window.


    syncthing log from start:

    and from there it just repeats;


    Screenshots of Listener and Discovery status windows:



    (Don't look at those IPv6 messages, IPv6 is disabled on my router 'cause for me it was useless on a LAN).


    And no, there are no rules set now, the firewall GUI interface is empty.

    I didn't touch iptables at all, CLI or otherwise.

  • Syncthing container won't connect to relays

    I tried setting the mode to bridge, but no change. Still "cannot assign requested address", whatever that means. The docs say bridge 's the default mode, so I'd say it's understandable.

    And no, I didn't edit iptables, I don't know how to and what exactly that affects.

    I did try some time ago to set in the firewall interface of OMV the same ports I had in the router, but neither that changed anything so I deleted them.

  • Syncthing container won't connect to relays

    OK, first observation: on my home network, the IPs from my modem GUI and whatismyip are the same, so I guess that means no CGNAT for my ADSL; but still, no relays. (I even checked if the right user is in the "docker" group, it is)


    I've tried using the settings in the .YML config file from the guide, but it just goes back to the error message it was giving before trying network_mode: host :

    Code
    global@https://discovery-v4.syncthing.net/v2/: Post "https://discovery-v4.syncthing.net/v2/": dial tcp: lookup discovery-v4.syncthing.net on [::1]:53: dial udp [::1]:53: connect: cannot assign requested address

    "cannot assign requested address" instead of "connection refused".

    Another constant, that [::1]:53 that I've read somewhere should mean it didn't pick up an address because of DNS problems and it's defaulting to local.


    Anyway, I did the experiment: home ADSL router, the NAS with syncthing container still won't see the relays; desktop PC with normal syncthing application sees them just fine; laptop with same normal syncthing and connected through a smartphone's wifi hotspot, sees the relays and syncs files with the desktop at around 100kB/s.

    More or less it's the result I expected, but what does it mean? What's keeping the container on the NAS from working like the other two applications, what else can I check?

  • Syncthing container won't connect to relays

    What about the Syncthing applications on my home desktop and on my laptop? Those two were displaying (or at least claiming?) to have a connection to the relay servers. I didn't think to test a remote sync between the two like you did with your smartphone, only with the NAS. That's one thing I want to test out now, it would mean that at least under certain conditions, it is possible with my providers too.

    I don't doubt a Raspberry PI 4 can handle that, I hear it's nice machine; the Nanopi with H5 processor and 512 megs RAM I bought with just a bit of Samba sharing in mind, I'm not so sure…

  • Syncthing container won't connect to relays

    I just checked and yes, it's possible that at least the office connection (4G LTE modem) is under CGNAT, since the address whatismyaddress.com returns is not the same the router lists for the WAN interface. Don't know about my home ADSL one, I will check.

    But then the problem would have to be something that somehow interferes with containerized Syncthings only, and that sounds kinda… very specific. (To clarify: as a test, I installed the syncthing container on the NAS, and the normal syncthing program on my laptop. Internet connection at home with ADSL modem/router: laptop connects to relays, NAS doesn't. Internet connection at work office with 4G modem/router: same results).

    I'll test the configuration from the guide this evening when I get back home, I'll let you know.

    Zitat von chente

    Off topic and just out of curiosity. In the case of a file server for work in an office and for several clients. Wouldn't it be more productive to use Nextcloud?

    I had taken a look at that too, and it had an impressive feature set, but it seemed kinda overkill for what we needed. Ours is a small office with at most 3-4 PCs and a network printer; plus the project had started as just a NAS to have work files all in a central location, so I had bought that small SBC with 512MB RAM. While I was setting that up another computer was acquired, so to avoid file management becoming too unwieldy I started looking into syncronization programs and stumbled on Syncthing, that luckily could still fit into that amount of RAM… to use Nextcloud I'd have to re-start from scratch with more powerful hardware, for features I don't even know we'd need. I'm definitely keeping it in mind if the need and activity grow in the future, but right now this remote relay syncing is the only thing left to start using this NAS, so I wanted to fix that.